at least one initial locator associated with an endpoint identifier
in order to establish an initial connection between the two hosts.
This locator could be loaded into the DNS in a conventional fashion,
or, if the endpoint identifier is a distinguished address value, the
initial communication could be established using the endpoint
identifier in the role of a locator (i.e., using this as a
conventional address).
The initial actions in establishing a session would be similar. If
the session is based on specification of a FQDN, the FQDN is first
mapped to an endpoint identity value, and this endpoint identity
value could then be mapped to a locator set. The locators in this
set are then candidate locators for use in establishing an initial
synchronised state between the two hosts. Once the state is
established, it is possible to update the initial locator set with
the current set of useable locators. This update could be part of
the initial synchronisation actions, or deferred until required.
This leads to the concept of a "distinguished" locator that acts as
the endpoint identifier, and a pool of alternative locators that are
associated with this "home" locator. This association may be
statically defined, using referential pointers in a third-party
referral structure (such as the DNS), or dynamically added to the
session through the actions of the EIP, or both.
If opportunistic identities are used where the identity is not a
fixed discoverable value but one that is generated in the context of
a session, then additional actions must be performed at session
startup. In this case, there is still the need for defined locators
that are used to establish a session, but then an additional step is
required to generate session keys and exchange these values in order
to support the identity equivalence of multiple locators within the
ensuing session. This may take the form of a capability exchange and
an additional handshake and associated token value exchange within
the transport protocol if an in-band approach is being used, or it
may take the form of a distinct protocol exchange at the level of the
identity protocol element, performed out-of-band from the transport
session.
Some approaches are capable of a further distinction, namely, that of
initial session establishment and that of establishment of additional
shared state within the session to allow multiple locators to be
treated as being bound to a common endpoint identity. It is not
strictly necessary that such additional actions be performed at
session startup, but it appears that such actions need to be
performed prior to any loss of end-to-end connectivity on the
selected initial locator, so that any delay in this additional state
exchange does increase the risk of session disruption due to
connectivity changes.
This raises a further question of whether the identity/locator split
is a capability negotiation performed per session or per remote end,
or whether the use of a distinguished identity value by the upper
level application to identify the remote end triggers the
identity/locator mapping functionality further down in the protocol
stack at the transport level, without any further capability
negotiation within the session.
Within the steps related to session startup, there is also the
consideration that the passive end of the connection follows a
process where it may need to verify the proposed new address
contained in the source address of incoming packets before using it
as a destination address for outgoing packets. It is not necessarily
the case that the sender’s choice of source address reflects a valid
path from the receiver back to the source. While using this offered
address appears to offer a low-overhead response to connection
attempts, if this response fails the receiver may need to discover
the full locator set of the remote end through some locator discovery
mechanism, to establish whether there is a viable locator that can
use a forwarding path that reaches the remote end.
Alternatively, the passive end would use the initially offered
locator and, if this is successful, leave it to the identity modules
in each stack to exchange information to establish the current
complete locator set for each end. This approach implies that the
active end of a communication needs to cycle through all of its
associated locators as source addresses until it receives a response
or exhausts its locator set. If the other end is also multi-homed
(and therefore has multiple locators), then the active end may need
to cycle through all possible destination locators for each source
locator. While this may extend the time to confirm that no path
exists to the remote end, it has the potential to improve the
characteristics of the initial exchange against denial-of-service
attacks that could force the remote end to engage in a high volume of
spurious locator lookups.
6.3.5. Dynamic Capability Negotiation
The common aspect of these approaches is that they all involve
changes to the end-to-end interaction, as both ends of the
communication need to be aware of this separation. The implication
is that this form of support for multi-homing is relatively sweeping
in its scope, as the necessary changes to support multi-homing extend
beyond changes to the hosts and/or routers within the multi-homed
site and encompass changes to the IPv6 protocol itself. It would be
prudent when considering these changes to evaluate associated
mechanisms that allow the communicating endpoints to discover each
other’s capabilities and only enable this form of split
identity/locator functionality when it is established that both ends
can support it.
It is a corollary of this form of negotiated capability that it is
not strictly necessary that only one form of functionality can be
negotiated in this way. If the adoption of a particular endpoint
identity/locator mapping scheme is the outcome of a negotiation
between the endpoints, then it would be possible to negotiate to use
one of a number of possible approaches. There is some interaction
between the approach used and the form of endpoint identity, and some
care needs to be taken that any form of acceptable outcome of the
endpoint identity capability negotiation is one that allows the
upper-level application to continue to operate.
6.3.6. Identity Uniqueness and Stability
When considering the properties of long-lived identities, it is
reasonable to assume that the identity assignation is not necessarily
one that is permanent and unchangeable. In the case of structured
identity spaces, the identity value reflects a distribution
hierarchy. There are a number of circumstances where a change of
identity value is appropriate. For example, if an endpoint device is
moved across administrative realms of this distribution hierarchy it
is likely that the endpoint’s identity value will be reassigned to
reflect the new realm. It is also reasonable to assume that an
endpoint may have more than one identity at any point in time. RFC
3014 [RFC3041] provides a rationale for such a use of multiple
identities.
If an endpoint’s identity can change over time and if an endpoint can
be identified by more than one identity at any single point in time,
then some further characteristics of endpoint identifiers should be
defined. These relate to the constancy of an endpoint identity
within an application, and the question of whether a transport
session relies on a single endpoint identity value, and, if so,
whether an endpoint identity can be changed within a transport
session, and under what conditions the old identity can continue to
be used following any such change. If the endpoint identity is a
long-lived reference to a remote endpoint, and if multiple identities
can exist for a single unique endpoint, then the question arises as
to whether applications can compare identities for equivalence, and
whether it is necessary for applications to recognise the condition
where different identities refer to the same endpoint. These
identities may be used within applications on a single host, or they
may be identifies within applications on different hosts.
7. Functional Decomposition of Multi-Homing Approaches
The following sections provide a framework for the characterisation
of multi-homing approaches through a decomposition of the functions
associated with session establishment, maintenance, and completion in
the context of a multi-homed environment.
7.1. Establishing Session State
What form of token is passed to the transport layer from the
upper-level protocol element as an identification of the local
protocol stack?
What form of token is passed to the transport layer from the
upper-level protocol element as an identification of the remote
session target?
What form of token is used by the upper-level protocol element as a
self-identification mechanism for use within the application payload?
Does the identity protocol element need to create a mapping from the
upper-level protocol’s local and remote identity tokens into an
identity token that identifies the session? If so, then is this
translation performed before or after the initial session packet
exchange handshake?
How does the session initiator establish that the remote end of the
session can support the multi-homing capabilities in its protocol
stack? If the remote end cannot, does the multi-homing capable
protocol element report a session establishment failure to the
upper-level protocol or silently fall back to a non-multi-homed
protocol operation?
How do the endpoints discover the locator set available for each
other endpoint (locator discovery)?
What mechanisms are used to perform locator selection at each end,
for the local selection of source and destination locators?
What form of mechanism is used to ensure that the selected site exit
path matches the selected packet source locator?
7.2. Re-homing Triggers
What are common denominator goals of re-homing triggers? What are
the objectives that triggers conservatively should meet across all
types of sessions?
Are there transport session-specific triggers? If so, then what
state changes within the network path should be triggers for all
transport sessions, and what state changes are triggers only for
selected transport sessions?
What triggers are used to identify that a switch of locators is
desirable?
Are the triggers based on the end-to-end transport session and/or on
notification of state changes within the network path from the
network?
What triggers can be used to indicate the direction of the failed
path in order to trigger the appropriate locator repair function?
7.3. Re-homing Locator Pair Selection
What parameters are used to determine the selection of a locator to
use to reference the local endpoint?
If the remote endpoint is multi-homed, what parameters are used to
determine the selection of a locator to use to reference the remote
endpoint?
Must a change of an egress site-exit router be accompanied by a
change in source and/or destination locators?
How can new locators be added to the locator pool of an existing
session?
7.4. Locator Change
What are the preconditions that are necessary for a locator change?
How can the locator change be confirmed by both ends?
What interactions are necessary for synchronisation of locator change
and transport session behaviour?
7.5. Removal of Session State
How is identity/locator binding state removal synchronised with
session closure?
What binding information is cached for possible future use?
8. Security Considerations
There are a significant number of security considerations that result
from the action of distinguishing within the protocol suite endpoint
identity and locator identity.
It is not proposed to enumerate these considerations in detail within
this document, but to reference a distinct document that describes
the security considerations of this domain [threats].
9. Acknowledgements
The author acknowledges the assistance from the following reviewers:
Brian Carpenter, Kurtis Lundqvist, Erik Nordmark, Iljitsch van
Beijnum, Marcelo Bagnulo, John Loughney, Thierry Ernst, Joe Touch,
Michael Patton, Ted Hardie, and Allison Mankin.
10. Informative References
[RFC3041] Narten, T. and R. Draves, "Privacy Extensions for
Stateless Address Autoconfiguration in IPv6", RFC 3041,
January 2001.
[RFC3484] Draves, R., "Default Address Selection for Internet
Protocol version 6 (IPv6)", RFC 3484, February 2003.
[RFC3582] Abley, J., Black, B., and V. Gill, "Goals for IPv6
Site-Multihoming Architectures", RFC 3582, August 2003.
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004.
[iab-link] Aboba, B., Ed., "Architectural Implications of Link Layer
Indications", Work in Progress, January 2005.
[e2e] Saltzer, J., Reed, D., and D. Clark, "End-to-End Arguments
in System Design", ACM TOCS Vol 2, Number 4, pp 277-288,
November 1984, <http://web.mit.edu/Saltzer/www/
publications/endtoend/endtoend.txt>.
[rosec] Nikander, P., Arkko, J., Aura, T., Montenegro, G., and E.
Nordmark, "Mobile IP version 6 Route Optimization Security
Design Background", Work in Progress, October 2004.
[thinks] Lear, E., "Things MULTI6 Developers should think about",
Work in Progress, January 2005.
[threats] Nordmark, E. and T. Li, "Threats relating to IPv6
multi-homing solutions", Work in Progress, January 2005.
Author’s Address
Geoff Huston
APNIC
EMail: gih@apnic.net
Full Copyright Statement
Copyright (C) The Internet Society (2005).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.