[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



          Dynamic Reassignment of IP Addresses for TCP and UDP

                 <draft-bound-ipv6-ip-addr-00.txt>


Status of this Memo

   This document is a submission to the IPng Working Group of the
   Internet Engineering Task Force (IETF).  Comments should be submitted
   to the ipng@sunroof.eng.sun.com mailing list.  This document is not
   at this time a product of the IPng Working Group, but a proposal to
   become a product of the IPng Working Group.

   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).

   Distribution of this document is unlimited.

Abstract

   This document is a proposal to extend the communications model for IP
   version 6 (IPv6) to support changing the transport address
   dynamically between two communicating end systems using a new IPv6
   Destination Option.  The proposal supports this dynamic address
   change for both TCP and UDP.  The proposal has applicability in IPv6
   for Dynamic Renumbering, Anycast Addresses, Multihoming, and
   Mobility. The proposal requires no changes to the existing TCP or UDP
   protocols, and is optional for IPv6 implementations.














Bound/Roque      Expires September 1996                         [Page 1]


INTERNET-DRAFT    draft-bound-ipv6-ip-addr-00.txt     Februrary 1996


Table of Contents:

1. Introduction.................................................3
2. Terminology and Definitions..................................3
3. Model........................................................6
3.1. Design Goals...............................................6
3.2. Concepts...................................................6
3.3 Communicating Address-Set Information.......................7
3.4 Effect on Communication End Points..........................8
4. Address-Set Reassign Option.................................10
5. Identification Option.......................................12
6. Protocol Operation..........................................12
6.1 Address Lifetimes..........................................12
6.2 Destination Address Selection..............................13
6.3 Source Address Selection...................................14
6.4 Update Acknowledgement.....................................14
6.5 Peer-destination-cache management..........................15
7. Applicability...............................................16
7.1 Dynamic Renumbering of Addresses...........................16
7.2 Mobility...................................................16
7.3 Multihoming................................................16
7.4 Anycast addresses..........................................16
7.5 Multi-homed Routing Domains................................17
8. Issues for Further Consideration............................18
Acknowledgements...............................................19
References.....................................................19
Authors' Address...............................................20

































Bound/Roque      Expires September 1996                         [Page 2]


INTERNET-DRAFT    draft-bound-ipv6-ip-addr-00.txt     Februrary 1996


1. Introduction

   Our intention for submitting this draft to the IPng Working Group is
   to begin the necessary work to support the dynamic reassignment of IP
   addresses between two communicating end systems using a new IPv6
   Destination Option.  The Authors believe this work should be done in
   the IPng Working Group under the Internet Area of the IETF.  Our
   proposal is an option and not required by any implementation of IPv6.
   It also requires no changes to TCP [RFC-793] or UDP [RFC-768]
   transport protocols.

   IPv6 has specifically designed into the architecture support for
   multiple addresses per interface.  But, it would also be of benefit
   to the IP Internet Model if IP addresses being used for TCP and UDP
   transport connections were able to migrate the existing IP addresses
   being used to new IP address in some instances.  This is a new
   requirement for the Internet and Intranets (private sites with no
   direct connections to the Internet) for technology like Mobility for
   IPv6, Dynamic Renumbering of IPv6 Addresses, Use of IPv6 Anycast
   Addresses, and IPv6 Multihomed Nodes.

   We first define the terminology using the existing terminology from
   IPv6 and then add the necessary terms needed for this document.  We
   discuss the "Model" we use to accomplish the dynamic reassignment IP
   addresses for transport connections listing our Design Goals,
   Concepts, Address-Set Information, and the Effect on Communication
   End-Points.  We then define the specific Destination Options formats
   and then discuss the Protocol Operation.  We conclude at this point
   with the open issues, which we believe will define the extensive work
   that needs to be done to complete this specification in the IETF.



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.

   node         - A device that implements IPv6.

   router       - A node that forwards IPv6 packets not explicitly
                  addressed to itself.

   host         - Any node that is not a router.

   upper-layer  - A protocol layer immediately above IP. Examples are
                  transport protocols such as TCP and UDP, control
                  protocols such as ICMP, routing protocols such as
                  OSPF, and internet or lower-layer protocols being
                  "tunneled" over (e.g. encapsulated in) IP such as
                  IPX, Appletalk, or IP itself.

   interface    - A node's attachment to the link.

   address      - An IP layer identifier for an interface or a set
                  of interfaces.



Bound/Roque      Expires September 1996                         [Page 3]


INTERNET-DRAFT    draft-bound-ipv6-ip-addr-00.txt     Februrary 1996


   packet       - An IP header plus payload.

   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.

   preferred address
                - An address assigned to an interface whose use by
                  upper layer protocols is unrestricted.  Preferred
                  addresses may be used as the source or destination
                  address of packets sent from or to the interface.

   deprecated address
                - An address assigned to an interface whose use is
                  discouraged, but not forbidden.  A deprecated
                  address should no longer be used as a source address
                  in new communications. but packets sent to a
                  deprecated address are delivered as expected.
                  A deprecated address may continue to be used as a
                  source address for the duration of existing
                  communications.

   valid address
                - A preferred or deprecated address.  A valid address
                  may appear as the source or destination address of a
                  packet, and the internet routing system is expected to
                  be able to deliver packets sent to a valid address.

   invalid address
                - An address that is not assigned to any interface. A
                  valid address becomes invalid when its valid
                  lifetime expires.  Invalid addresses should not appear
                  as the source or destination of a packet.

   preferred lifetime
                - The length of time that a valid address is preferred.
                  When the preferred lifetime expires, the address
                  becomes deprecated.

   valid lifetime
                - The length of time the address remains in the valid
                  state. The valid lifetime MUST be greater than or
                  equal to the preferred lifetime.  When the valid
                  lifetime expires, the address becomes invalid.

   Transit Routing Domain (TRD)
                - Routing Domain that carries traffic other than the
                  traffic originated or addressed to itself.

   transport connection
                - Communications between to hosts using TCP (connection
                  oriented) or UDP (connectionless oriented).

   peer host
                - This is the host in this specification that a host


Bound/Roque      Expires September 1996                         [Page 4]


INTERNET-DRAFT    draft-bound-ipv6-ip-addr-00.txt     Februrary 1996


                  is communicating with through a transport connection.

   address-set
                - The set of valid site or global addresses a host
                  may use to establish a transport connection with
                  a peer host [RFC-1884].

   address-set-view
                - The address-set of a node as viewed from a host to
                  communicate with a peer host.  A host is not required
                  to make all of its valid addresses known to a peer
                  host. An address-set-view may be be a subset of the
                  nodes address-set.















































Bound/Roque      Expires September 1996                         [Page 5]


INTERNET-DRAFT    draft-bound-ipv6-ip-addr-00.txt     Februrary 1996


3. Model



3.1. Design Goals

   The core objective of this specification is to define a mechanism
   that permits the dynamic reassignment of IP addresses for transport
   connections:

      No assumptions are made as to the reasons a host may have for
      reassigning an IP address for a transport connection. But, for the
      sake of discussion, we present a list of possible uses of this
      mechanism later in this specification.

      There are no modifications required to the TCP or UDP transport
      protocols specifications.

      The use of multiple IP addresses in communication should not imply
      any changes to the basic IP Datagram Delivery Model, Neighbor
      Discovery [ND] Model, or Address Autoconfiguration Model
      [ADDRCONF].

      To foster an initial discussion to provide the capability to
      dynamically reassign an IP address for a transport connection,
      through the use of an IPv6 Destination Option.


3.2. Concepts

   An IP node can be viewed as an entity possessing one or more IP
   addresses for an interface. We call "address-set" the set of valid
   addresses that can be used by a host to communicate with a peer host.

   The address-set of a node is dynamic per definition since IPv6 is
   designed to allow the addition and deletion of addresses due to
   configuration of network interfaces or changes of the announced
   network prefixes on a link.

   IP addresses have two important roles in the IP architecture. They
   serve the functions of node locator and node identifier. Any valid
   address present on an address-set is an identifier of the same end-
   system, although different addresses are likely to specify different
   locations.

   There are two additional properties of IP addresses that play an
   important role in the Model here presented:

      IPv6 addresses may have finite lifetimes. Although deprecated
      addresses may be used in communications it is important to
      guarantee that non-valid addresses are not used as a destination
      address of datagrams, nor as an identifier for an end system.

      In terms of a communicating with a peer host, not all of the peer
      host addresses are guaranteed to have the same degree of
      preference. In fact, since different addresses of a node can
      represent different locations in terms of network topology,
      efficient utilization of network resources is likely to depend on


Bound/Roque      Expires September 1996                         [Page 6]


INTERNET-DRAFT    draft-bound-ipv6-ip-addr-00.txt     Februrary 1996


      the utilization of a particular address.

   As stated above, the availability of multiple addresses on an IP node
   will, in the general case, correspond to the availability of multiple
   paths for end-to-end communication. Both efficiency and reliability
   of communication depends on the ability to use those multiple
   available paths, and in fact they must be known to the sending host.

   Mobility requirements are a good example of the convenience of such
   functionality. A mobile host can be characterized by the use of a
   home address and a care-of address [Mobile]. The home address of an
   host is likely to remain constant for a relative long period while a
   care-of address tends to be short lived. Several references [Mobile]
   [Huitema95] point out the fact that efficient network utilization is
   likely to depend on the ability to use the care-of address directly
   in communication. However, since care-of addresses are likely to
   change quickly, reliability of communication would benefit from the
   ability to fall-back to the more stable home address. This proposal
   aims at meeting this requirements by providing a basic model that
   comtemplates the usage of asymetric preference addresses by end-
   systems that will scale to the usage of multiple care-of addresses by
   a fast moving host.

   The use of multiple addresses in end-to-end communication requires IP
   nodes to maintain information concerning the valid addresses of the
   peer hosts to which they are communicating. We call the address-set-
   view a node's view of the valid addresses of a peer host, and the
   respective lifetimes and preferences.

   An address-set-view is not required to contain all the addresses of
   the peer it refers to since, one or more addresses might be omitted,
   for example, as the result of policy constraints. An address-set-view
   is required to be a valid subset of the address-set of a peer host.
   This requirement is a result of the identification property of IP
   addresses as all addresses in an address-set-view must identify the
   same end system.

   Address lifetimes can be lowered by a Router Advertisement [ND]. This
   is likely to happen as result of a renumbering process, when existing
   link prefixes are deleted and new address prefixes are announced for
   a link. To account for transient communication failures address
   lifetimes present in address-sets should be a conservative estimate
   of the real address lifetime. This is required to prevent that during
   a network failure the address of a peer becomes invalid and is reused
   by a different end system.



3.3 Communicating Address-Set Information

   Address information must be maintained for peer hosts.  We propose
   the use of a conceptual "peer-destination-cache" used by a node,
   which contains an entry for each peer the node is currently
   communicating with, consisting of an address-set-view and additional
   state required to maintain it's correctness.

   As address-sets are dynamic and may change during the lifetime of a
   transport connection we propose a mechanism hosts should use for


Bound/Roque      Expires September 1996                         [Page 7]


INTERNET-DRAFT    draft-bound-ipv6-ip-addr-00.txt     Februrary 1996


   informing it's peer hosts of changes to their address-set.

   This document defines a new Destination Option called "Address-Set
   Reassign Option" that nodes should use to inform peer hosts of the
   address-set that should be used for communication.

   This option also conveys a mechanism for tolerating datagram losses
   to improve the reliability of Address-Set information updates. This
   mechanism is explained in detail in subsequent sections of this
   specification.

   As mentioned above, IP addresses are used as end system identifiers
   in the IP architecture. Situations may occur when a host must use as
   the source address of it's datagram an address not known by a peer
   host. An example of this scenario is the utilization of an anycast
   addresses to initiate a TCP connection or a UDP packet exchange. In
   such situations the responding host must use a unicast address as the
   source address of it's datagrams, which is unlikely to be known by
   the peer host.  Communication can still occur if there are [secure]
   means the peer host can use to identify itself correctly. To provide
   for this possibility we define an "Identification Option" to be
   carried in the Destination Options Extension Header of IP datagrams
   that allows a host to identify itself when using a source address not
   previously known to the peer host.



3.4 Effect on Communication End Points

   The main objective of this document is to propose a generic framework
   to provide for end-to-end communication over dynamic sets of IP
   addresses.

   Conceptually, we present a new communication model in which
   communication occurs between end-systems regardless of the underlying
   IP addresses that are used in communication. This is an evolutionary
   step from the traditional IP Model of address-to-address transport
   connections.

   As previously stated, we intend to achieve this goal without
   requiring changes to the transport protocol specifications. This
   proposal requires, however, a simple extension to the transport-
   network interface.

   End-system identification is done, in this model as in the
   traditional IP model, based on IP addresses. An end-system is not
   guaranteed (or required) to have a constant identifier during the
   full duration of a transport communication.

   Proponents of end-system communication models often introduce the use
   of globally unique constant End-system Identifiers (EIDs) by
   transport protocols. While EIDs provide a constant identifier not
   present in this model, it's use still requires a mechanism for
   mapping between EIDs and IP addresses. The authors believe that the
   address-set model is also well suited for this role.

   As applications exist that rely on the address-to-address
   communication model the use of the functionality here presented must


Bound/Roque      Expires September 1996                         [Page 8]


INTERNET-DRAFT    draft-bound-ipv6-ip-addr-00.txt     Februrary 1996


   be made optional although it's default should be set to true.

   We refer to the required extensions as:

   Source Address Update -
          Network layer to transport layer indication of a change in
          the source address that is currently being used in datagrams
          sent by the node.

   Destination Address Update -
           Network layer to transport layer indication of a change in
           the destination address that is currently being used in
           datagrams sent by the node.

   Pseudo Header Information -
           Information provided by the network layer for the purpose of
           checksum verification. Datagrams must always be sent with the
           source and destination addresses currently being used by the
           transport layer.

   Optionally, the transport network interface may be extended to
   include a "negative progress indication" from the transport layer.
   This primitive serves as an indication to the network layer that it
   should lower the preference of the destination address currently
   being used and use an alternative destination address if available.
   This mechanism is intended to allow the possibility to explore the
   use of multiple paths between communicating nodes, when available.

   The end-system to end-system communication model implies that, since
   all the address of a node define the same end-system, two
   applications cannot use the same (protocol, port) pair
   simultaneously. An aplication using this model implicitly binds to
   all of the nodes's address.  Implementations may however alow the
   same physical machine to behave as several end-systems.

   Also, the destination address selected by an application is not
   necessarily the destination address used in the datagram that
   initiates a transport connection. If a peer-destination-cache entry
   exists that contains the selected address, the network layer should
   notify the transport protocol of a destination address change if the
   selected address is not the highest preference address in the
   address-set-view.

   When a datagram is received for a valid address of a node, the node
   must present the datagram to the transport layer as sent to the
   source address currently being used. In a similar way, when a node
   receives a datagram containing an "identification" option it should
   present it to the upper-layer as originating from the address
   specified by this option.











Bound/Roque      Expires September 1996                         [Page 9]


INTERNET-DRAFT    draft-bound-ipv6-ip-addr-00.txt     Februrary 1996


4. Address-Set Reassign Option

   The Address-Set Reassign option provides a mechanism IP nodes should
   use to inform a peer host of the addresses that can be used in
   communication along with respective lifetimes and preference values.
   It also provides a way to confirm the reception of reassign messages.
   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   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Action     |Number of Addrs|       Sequence Number         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     |                           Address 1                           |
     |                                                               |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     |                              ...                              |
     |                                                               |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     |                           Address n                           |
     |                                                               |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                           Lifetime 1                          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                              ...                              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                           Lifetime n                          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Preference 1  |      ...      | Preference n  |    Padding    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   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.

   Action

      8-bit unsigned integer with one of the following values:

      01 - Replace



Bound/Roque      Expires September 1996                        [Page 10]


INTERNET-DRAFT    draft-bound-ipv6-ip-addr-00.txt     Februrary 1996


        Replace action consisting of one or more addresses along
        with respective lifetimes and preferences values that
        should be used by the peer host to construct the address-set-
        view for the originating node.

      02 - New set

        Instructs the peer to use the new set of addresses present in
        the option for the purpose of the existing communications. The
        semantics of this message is equivalent to the "Replace"
        operation whitout the removal of the previous address-set-view.
        This operation is not to be confirmed.

      03 - Acknowledge

        Acknowledge action indicates the acknowledgment by the
        originating host of a Replace action received with the
        sequence number contained in the Reassign option.

      04 - Acknowledge Reply

        Acknowledge Reply action indicates the reception of an
        acknowledgment action referring to a previously sent Reassign
        option carrying the referred sequence number.

   Number of Addresses

      8-bit unsigned integer. The number of addresses and respective
      information present from a Reassign option. Must be 0 in the case
      of an Acknowledge or Acknowledge Reply operation.

   Sequence Number

      16-bit unsigned integer. Incremental sequence number, used to
      distinguish related acknowledgments with the update message they
      refer to.
























Bound/Roque      Expires September 1996                        [Page 11]


INTERNET-DRAFT    draft-bound-ipv6-ip-addr-00.txt     Februrary 1996


5. Identification Option

   The Identification option provides a mechanism IP nodes may use to
   identify them selfs to a peer host when it is convenient or necessary
   to use as source address of a datagram an address not known to the
   peer.

   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

      IP address previously known to the peer as an identifier for the
      end-system.



6. Protocol Operation



6.1 Address Lifetimes

   The correctness of the address-set model here defined depends on
   asserting that every address present on an address-set-view
   identifies the same end system.

   This restriction is enforced in two ways:

      - by using a conservative estimate of address lifetimes in
        address-set-views.

      - by falling back to the traditional "one-address-per-host" IP
        communication Model when the communication peer does not


Bound/Roque      Expires September 1996                        [Page 12]


INTERNET-DRAFT    draft-bound-ipv6-ip-addr-00.txt     Februrary 1996


        implement the mechanisms here defined or transient network
        failures prevent address-set information to be updated.

   We define the constant MAX_ADDRSET_LIFETIME as the maximum value for
   an address lifetime that can be present in an address-set-view.  The
   value of this constant should be equal to the minimum period that
   must elapse before an address with a infinite lifetime value is
   deprecated and reused by a different end system.

   Additionally to support address-set-view information, entries in the
   peer-destination-cache shall contain two timestamp values:

     rcv_update_tstamp
       The timestamp of the last received address-set reassign.

     snt_update_tstamp
       The timestamp of the last sent address-set reassign.

   When current time - rcv_update_tstamp becomes equal to
   MAX_ADDRSET_LIFETIME a node must update the respective address-set-
   view so that it contains only the address that was currently being
   used for communication. The host can then update the lifetime of that
   address to the infinite value. This restriction enforces a fall-back
   to the default IP Model whenever the communication peer does not
   implement this proposal or a transient network failure has occurred
   that prevents communication.

   When an entry in the peer-destination-cache is created and additional
   information is absent, lifetime of the addresses on the respective
   address-set-view should be initialized to MAX_ADDRSET_LIFETIME and
   the rcv_update_tstamp should be initialized to the current time.

   Special care must be taken by hosts sending a Reassign option. Nodes
   must not announce lifetime values that may be greater than the
   minimum time interval that must elapse until the address can be
   reused.

   Nodes must keep track of lifetimes they announce in order to avoid
   addresses from expiring in the peer hosts address-set-view. When a
   node is announcing addresses with a lifetime of MAX_ADDRSET_LIFETIME
   it should send Reassign options to it's peers every
   MAX_ADDRSET_LIFETIME / 2 period, by using the Reassign option in a
   datagram that carries transport data, or by sending the Reassign
   option itself to a peer host.



6.2 Destination Address Selection

   The highest preference address present on an address-set view should
   be selected as the destination address of outgoing datagrams.
   Preferences are subtle to change by the receipt of Reassign options
   from a peer host or by response to a "negative progress indication"
   issued by the transport layer. When one of these events occur a host
   should recalculate the destination address.

   When a new peer-destination-cache entry is created for which there is
   no additional information on preference values provided by the peer


Bound/Roque      Expires September 1996                        [Page 13]


INTERNET-DRAFT    draft-bound-ipv6-ip-addr-00.txt     Februrary 1996


   host, the preference values on all addresses shall be set to 1. After
   initial selection of the destination address, a node shall refrain
   from changing the destination address until it detects that the peer
   implements this extension by the receipt of a Reassign option.



6.3 Source Address Selection

   The source address used when sending datagrams for a particular
   destination should be equal to the highest preference address
   announced to a particular destination when such announcement as been
   made.

   Note that since the source address of datagrams identifies the
   sending host that address must be already known to the peer. When it
   is not possible to meet this goal an Identification option must be
   used for the purposes of end system identification.

   When a node intends to change it's highest preference address for a
   particular destination, and consequently the source address used in
   communication, it should wait for a confirmation of the sent update
   before notifying the transport layer and subsequently changing the
   source address of datagrams.



6.4 Update Acknowledgement

   The Reassign option has been designed with a simple acknowledgment
   mechanism to tolerate packet losses.

   We define two additional fields for the peer-destination-cache for
   the purposes of Reassign operation acknowledgment:

     rcv_update_state
       State information concerning received update operations.

     snt_update_state
       State information concerning sent update operations.

   Where an update state has one of the following values:

      NULL
        no Reassign option received/sent

      UPDATE RECEIVED
        host must send a Reassign option Ack Reply in subsequent packets
        until it receives a Reassign option with a superior sequence
        number or a Reassign option Ack Reply.

      UPDATE SENT
        host will repeat the Reassign option until it receives an Ack.

      UPDATE ACK RECEIVED
        host will send a Reassign option Ack or a Replace with a
        superior sequence number in subsequent packets.



Bound/Roque      Expires September 1996                        [Page 14]


INTERNET-DRAFT    draft-bound-ipv6-ip-addr-00.txt     Februrary 1996


6.5 Peer-destination-cache management

   Peer-destination-cache entries should be maintained as long as there
   is a transport connection to the destination end-system.
   Implementations may choose to include a usage field in each entry
   that maintains an up-to-date count of the number of PCBs using the
   cache entry. When such usage count reaches 0 the respective entry
   should be removed from the peer-destination-cache.

   On memory exhaustion situations a node may remove from the peer-
   destination-cache entries for which an address exists that has been
   announced by the peer with a MAX_ADDRSET_LIFETIME lifetime. This
   represents a fall back to the default IP model since such a address
   is considered to have a valid lifetime with infinite value.














































Bound/Roque      Expires September 1996                        [Page 15]


INTERNET-DRAFT    draft-bound-ipv6-ip-addr-00.txt     Februrary 1996


7. Applicability



7.1 Dynamic Renumbering of Addresses

   This proposal supports dynamic renumbering of addresses, allowing for
   transport connections to survive over a renumbering period.  A
   transport connection where either peer must use a new address can
   send this proposed Address-set Reassign option to migrate the
   transport connection to a new address. In addition the mechanisms
   specified in the Address-Set Model permit two peers communicating
   end-to-end to be aware of each others address state as addresses are
   depreated or invalidated per IPv6 stateless [ADDRCONF] or stateful
   [DHCPv6] address autoconfiguration mechanism.



7.2 Mobility

   The dynamic address reassignment facility here presented can be used
   to allow the use of both care-of addresses and home addresses when
   communicating to IPv6 mobile hosts.

   Address preferences enable mobile nodes to specify which address
   should be used as destination address of datagrams addressed to it at
   a particular moment while still allowing for datagrams to be
   delivered via the Home Agent.

   Address lifetimes in address-set-views make this mechanism specially
   well suited to situations where addresses have very short lifetimes
   as it is likely to occur when communicating to mobile hosts. The
   expiration of an address in the peer's address-set-view automatically
   reverts communication to use the more stable home address.

   As address-set-views are not restricted to one or two address per
   host, this model can provide an extra support for moving hosts during
   care-of address change periods.



7.3 Multihoming

   This proposal provides a mechanism for implementations of IPv6
   multihomed nodes to migrate a transport connection to a new IP
   address when that is required.  This can be used when multiple
   interfaces are on the same link or on different links.



7.4 Anycast addresses

   Anycast addresses represent a group of interfaces. Datagrams sent to
   an anycast address should be delivered to one and preferably only one
   of the group members. Acording to [RFC-1546], the main motivation to
   anycast addresses is to provide a mechanism of datagram delivery to a
   group of hosts that support a particular service.



Bound/Roque      Expires September 1996                        [Page 16]


INTERNET-DRAFT    draft-bound-ipv6-ip-addr-00.txt     Februrary 1996


   Conceptually, such a group can be viewed as a particular type of
   end-system for which transport connections must migrate to new
   addresses after the receipt of the first datagram by one of the group
   members.

   On an anycast initiated transport connection, the replying node must
   answer using one of it's valid interface adddresses as source address
   of the datagram. As this address is not likely to be known to it's
   peer as an identifier for the end-system, the reply datagram must
   include an identification option using the anycast address as an
   identifier. The same datagram should include a Reassign option
   containing the node's interface addresses to be used in
   communication.

   Anycast addresses impose, however, a particular restriction not
   present in the unicast case. Since two subsequent datagrams are not
   guranteed to be delivered to the same node a Reassign option sent by
   the responding node must not delete the old peer-destination-cache
   entry when multiple connection initiations are in progress.  This
   implies that a node replying to a connection initiation sent to a
   anycast address must use the ``New set'' operation in the Reassign
   option contained in the reply.



7.5 Multi-homed Routing Domains

   IPv6 architecture for unicast address allocation [RFC-1887] discusses
   several solutions to address assignment for multi-homed routing
   domains. According to this document, the address assignment policy
   that "scales better to extremely large internets containing very
   large numbers of multi-homed organizations" "would be for multi-homed
   organizations to be assigned a separate IPv6 address space for each
   connection to a TRD".

   The authors believe the this proposal can be the basis to solve the
   major drawbacks to this approach. The ability to migrate the IP
   addresses used in a transport connection can provide for fail
   recovery when such a multi-homed domain looses connectivity to a TRD
   without imposing additional load on inter-domain routing.

   Also, if additional external mechanisms are defined, it could be
   possible for a node to choose the source address for a particular
   peer in such a way that minimizes the load imposed in TRDs and
   maximizes the utilization of the internal network.















Bound/Roque      Expires September 1996                        [Page 17]


INTERNET-DRAFT    draft-bound-ipv6-ip-addr-00.txt     Februrary 1996


8. Issues for Further Consideration

A change in the communication path used in a TCP connection is not
likely to disturb TCP's congestion control and avoidance algorithm since
it's likely to occur on the opening of a better path or because of a
failure on the path previously being used. However the authors believe
the issue should be studied in further detail, especially in terms of
when should TCP issue a "negative progress indication" to the network
layer.

Define if preferences should be lowered on the receipt of an ICMP
Unreachable message.

Security mechanisms.

Define a mechanism to notify applications of address changes.

Choice of destination address when multiple "higher preference" address
are present on an address-set-view.

Analysis of security implications especially in terms of packet
filtering.






































Bound/Roque      Expires September 1996                        [Page 18]


INTERNET-DRAFT    draft-bound-ipv6-ip-addr-00.txt     Februrary 1996


Acknowledgements

   Thanks to Carlos Picoto for early comments on the base ideas of the
   draft.



References

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

   [RFC-1884]
       R. Hinden, S. Deering, Editors, "IP Version 6 Addressing
       Architecture" Proposed Standard, December 1995

   [RFC-1887]
       Y. Rekhter, T. Li, Editors, "An Architecture for IPv6 Unicast
       Address Allocation", Informational Request for Comments,
       December 1995.

   [ADDRCONF]
       S. Thomson, T. Narten, "IPv6 Stateless Address Autoconfiguration"
       Internet Draft, November 1995
       <draft-ietf-addrconf-ipv6-auto-07.txt>

   [ND]
       T. Narten, E. Nordmark, and W. A. Simpson, "IPv6 Neighbor
       Discovery", Internet Draft, February 1996
       <draft-ietf-ipngwg-discovery-04.txt>

   [DHCPv6]
       J. Bound, C. Perkins, "Dynamic Host Configuration Protocol for
       IPv6 (DHCPv6)", Internet Draft, February 1996
       <draft-ietf-dhc-dhcpv6-04.txt>

   [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.

   [Mobile]
       C. Perkins and D. Johnson, "Mobility Support in IPv6",
       Internet Draft, January 1996
       <draft-ietf-mobileip-ipv6-00.txt>

   [Huitema95]
       Christian Huitema, "Routing in the Internet",
       Prentice Hall, 1995.



Bound/Roque      Expires September 1996                        [Page 19]


INTERNET-DRAFT    draft-bound-ipv6-ip-addr-00.txt     Februrary 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













































Bound/Roque      Expires September 1996                        [Page 20]