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]