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 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 [ND] T. Narten, E. Nordmark, and W. A. Simpson, "IPv6 Neighbor Discovery", Internet Draft, February 1996 [DHCPv6] J. Bound, C. Perkins, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", Internet Draft, February 1996 [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 [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]