Request for Comments: 4177 APNIC
Category: Informational September 2005
Architectural Approaches to Multi-homing for IPv6
Status of this Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This memo provides an analysis of the architectural aspects of
multi-homing support for the IPv6 protocol suite. The purpose of
this analysis is to provide a taxonomy for classification of various
proposed approaches to multi-homing. It is also an objective of this
exercise to identify common aspects of this domain of study, and also
to provide a framework that can allow exploration of some of the
further implications of various architectural extensions that are
intended to support multi-homing.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. The Multi-Homing Space . . . . . . . . . . . . . . . . . . . . 5
4. Functional Goals and Considerations . . . . . . . . . . . . . 7
5. Approaches to Multi-Homing . . . . . . . . . . . . . . . . . . 7
5.1. Multi-Homing: Routing . . . . . . . . . . . . . . . . . 8
5.2. Multi-Homing: Mobility . . . . . . . . . . . . . . . . . 9
5.3. Multi-homing: Identity Considerations . . . . . . . . . 12
5.4. Multi-homing: Identity Protocol Element . . . . . . . . 14
5.5. Multi-homing: Modified Protocol Element . . . . . . . . 15
5.6. Modified Site-Exit and Host Behaviors . . . . . . . . . 16
6. Approaches to Endpoint Identity . . . . . . . . . . . . . . . 17
6.1. Endpoint Identity Structure . . . . . . . . . . . . . . 18
6.2. Persistent, Opportunistic, and Ephemeral Identities . . 20
6.3. Common Issues for Multi-Homing Approaches . . . . . . . 23
6.3.1. Triggering Locator Switches . . . . . . . . . . 23
6.3.2. Locator Selection . . . . . . . . . . . . . . . 26
6.3.3. Layering Identity . . . . . . . . . . . . . . . 27
6.3.4. Session Startup and Maintenance . . . . . . . . 29
6.3.5. Dynamic Capability Negotiation . . . . . . . . . 31
6.3.6. Identity Uniqueness and Stability . . . . . . . 31
7. Functional Decomposition of Multi-Homing Approaches . . . . . 32
7.1. Establishing Session State . . . . . . . . . . . . . . . 32
7.2. Re-homing Triggers . . . . . . . . . . . . . . . . . . . 33
7.3. Re-homing Locator Pair Selection . . . . . . . . . . . . 33
7.4. Locator Change . . . . . . . . . . . . . . . . . . . . . 34
7.5. Removal of Session State . . . . . . . . . . . . . . . . 34
8. Security Considerations . . . . . . . . . . . . . . . . . . . 34
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 34
10. Informative References . . . . . . . . . . . . . . . . . . . . 34
1. Introduction
The objective of this analysis is to allow various technical
proposals relating to the support of multi-homing environment in IPv6
to be placed within an architectural taxonomy. This is intended to
allow these proposals to be classified and compared in a structured
fashion. It is also an objective of this exercise to identify common
aspects across all proposals within this domain of study, and also to
provide a framework that can allow exploration of some of the further
implications of various architectural extensions that are intended to
support multi-homing. The scope of this study is limited to the IPv6
protocol suite architecture, although reference is made to IPv4
approaches as required.
2. Terminology
Care-of Address (CoA)
A unicast routeable address associated with a mobile node while
visiting a foreign link; the subnet prefix of this IP address is a
foreign subnet prefix. Among the multiple care-of addresses that
a mobile node may have at any given time (e.g., with different
subnet prefixes), the one registered with the mobile node’s home
agent for a given home address is called its "primary" care-of
address.
Correspondent Node (CN)
A peer node with which a mobile node is communicating. The
correspondent node may be either mobile or stationary.
Endpoint
A term for the identity for a network host. This is normally
assumed to be a constant or long-lived association.
Endpoint Identity Protocol Stack Element (EIP)
An added element in a protocol stack model that explicitly manages
the association of locators to endpoints.
Home Address (HoA)
A unicast routeable address assigned to a mobile node, used as the
permanent address of the mobile node. This address is within the
mobile node’s home link. Standard IP routing mechanisms will
deliver packets destined for a mobile node’s home address to its
home link. Mobile nodes can have multiple home addresses, for
instance, when there are multiple home prefixes on the home link.
Lower Layer Protocol (LLP)
The lower-level protocol in the protocol stack model relative to
the protocol layer being considered. In the Internet
architecture, the LLP of the transport protocol is the Internet
Protocol, and the LLP of the application protocol is the transport
protocol.
Locator
The term "locator" is used as the location token for a network
host. This is a network-level address that can be used as a
destination field for IP packets.
Mobile Node
A node that can change its point of attachment from one link to
another, while still being reachable via its home address.
Multi-Homed Site
A site with more than one transit provider. "Site multi-homing"
is the practice of arranging a site to be multi-homed such that
the site may use any of its transit providers for connectivity
services.
Re-homing
The transition of a site between two states of connectedness, due
to a change in the connectivity between the site and its transit
providers.
Site
An entity autonomously operating a network using IP.
Site-Exit Router
A boundary router of the site that provides the site’s interface
to one or more transit providers.
Transit Provider
A provider that operates a site that directly provides
connectivity to the Internet to one or more external sites. The
connectivity provided extends beyond the transit provider’s own
site. A transit provider’s site is directly connected to the
sites for which it provides transit.
Upper Layer Protocol (ULP)
The upper-level protocol in the protocol stack model relative to
the protocol layer being considered. In the Internet
architecture, the ULP of the Internet Protocol is the transport
protocol, and the ULP of the transport protocol is the application
protocol.
3. The Multi-Homing Space
A simple formulation of the site multi-homing environment is
indicated in Figure 1.
+------+
|remote|
| host |
| R |
+------+
|
+ - - - - - - - - - - - +
| Internet Connectivity |
+ - - - - - - - - - - - +
/ \
+---------+ +---------+
| ISP A | | ISP B |
+---------+ +---------+
| Path A | Path B
+ - - - - - - - - - - - - - - - - - - - - +
| multi- | | |
homed +------+ +------+
| site | site-| | site-| |
| exit | | exit |
| |router| |router| |
| A | | B |
| +------+ +------+ |
| |
| local site connectivity |
|
| +-----------+ |
|multi-homed|
| | host | |
+-----------+
+ - - - - - - - - - - - - - - - - - - - - +
Figure 1: The Multi-Homed Domain
The environment of multi-homing is intended to provide sufficient
support to local hosts so as to allow local hosts to exchange IP
packets with remote hosts, such that this exchange of packets is
transparently supported across dynamic changes in connectivity.
Session resilience implies that if a local multi-homed-aware host
establishes an application session with the remote host using "Path
A", and this path fails, the application session should be mapped
across to "Path B" without requiring any application-visible
re-establishment of the session. In other words, the application
session should not be required to be explicitly aware of underlying
path changes at the level of packet forwarding paths chosen by the
network. Established sessions should survive dynamic changes in
network-level reachability.
There are also considerations of providing mechanisms to support
sustained site visibility to support session establishment.
Sustained site visibility implies that external attempts to initiate
a communication with hosts within the site will succeed as long as
there is at least one viable path between the external host and the
multi-homed site. This also implies that local attempts to initiate
a communication with remote hosts should take into account the
current connectivity state in undertaking locator selection and
setting up initial locator sets.
In addition, there is the potential consideration of being able to
distribute the total traffic load across a number of network paths
according to some predetermined policy objective. This may be to
achieve a form of traffic engineering, support for particular
quality-of-service requirements, or localized load balancing across
multiple viable links.
This simple multi-homing scenario also includes "site-exit" routers,
where the local site interfaces to the upstream Internet transit
providers. The interactions between the external routing system and
the site-exit routers, the interactions between the site-exit routers
and the local multi-homed host, and the interactions between local
connectivity forwarding and the local host and site exit routers are
not defined a priori in this scenario, as they form part of the
framework of interaction between the various multi-homing components.
The major characteristic of this simple site multi-homing scenario is
that the address space used by, and advertised as reachable by, ISP A
is distinct from the address space used by ISP B.
This simple scenario is intended to illustrate the basic multi-homing
environment. Variations may include additional external providers of
transit connectivity to the local site; complex site requirements and
constraints, where the site may not interface uniformly to all
external transit providers; sequential rather than simultaneous
external transit reachability; communication with remote multi-homed
hosts; multiway communications; use of host addresses in a
referential context (third-party referrals); and the imposition of
policy constraints on path selection. However, the basic simple site
multi-homing scenario is sufficient to illustrate the major
architectural aspects of support for multi-homing, so this simple
scenario will be used as the reference model for this analysis.
4. Functional Goals and Considerations
RFC 3582 [RFC3582] documents some goals that a multi-homing approach
should attempt to address. These goals include:
* redundancy
* load sharing
* traffic engineering
* policy constraints
* simplicity of approach
* transport-layer survivability
* DNS compatibility
* packet filtering capability
* scaleability
* legacy compatibility
The reader is referred to [RFC3582] for a complete description of
each of these goals.
In addition, [thinks] documents further considerations for IPv6
multi-homing. Again, the reader is referred to this document for the
detailed enumeration of these considerations. The general topic
areas considered in this study include:
* interaction with routing systems,
* aspects of a split between endpoint-identifier and forwarding
locator,
* changes to packets on the wire, and
* the interaction between names, endpoints, and the DNS.
In evaluating various approaches, further considerations also
include:
* the role of helpers and agents in the approach,
* modifications to host behaviours,
* the required trust model to support the interactions, and
* the nature of potential vulnerabilities in the approach.
5. Approaches to Multi-Homing
There appear to be five generic forms of architectural approaches to
this problem, namely:
Routing
Use the IPv4 multi-homing approach
Mobility
Use the IPv6 Mobility approach
New Protocol Element
Insert a new element in the protocol stack that manages a
persistent identity for the session
Modify a Protocol Element
Modify the transport or IP protocol stack element in the host
in order to support dynamic changes to the forwarding locator
Modified Site-Exit Router/Local Host interaction
Modify the site-exit router and local forwarding system to
allow various behaviours including source-based forwarding,
site-exit hand-offs, and address rewriting by site-exit routers
These approaches will be described in detail in the following
sections.
5.1. Multi-Homing: Routing
The approach used in IPv4 for multi-homing support is to preserve the
semantics of the IPv4 address as both an endpoint identifier and a
forwarding locator. For this to work in a multi-homing context, it
is necessary for the transit ISPs to announce the local site’s
address prefix as a distinct routing entry in the inter-domain
routing system. This approach could be used in an IPv6 context, and,
as with IPv4, no modifications to the IPv6 architecture are required
to support this approach.
The local site’s address prefix may be a more specific address prefix
drawn from the address space advertised by one of the transit
providers, or from some third-party provider not currently connected
directly to the local site. Alternatively, the address space may be
a distinct address block obtained by direct assignment from a
Regional Internet Registry as Provider Independent space. Each host
within the local site is uniquely addressed from the site’s address
prefix.
All transit providers for the site accept a prefix advertisement from
the multi-homed site and advertise this prefix globally in the
inter-domain routing table. When connectivity between the local site
and an individual transit provider is lost, normal operation of the
routing protocol will ensure that the routing advertisement
corresponding to this particular path will be withdrawn from the
routing system; those remote domains that had selected this path as
the best available will select another candidate path as the best
path. Upon restoration of the path, the path is re-advertised in the
inter-domain routing system. Remote domains will undertake a further
selection of the best path based on this re-advertised reachability
information. Neither the local nor the remote host need to have
multiple addresses or to undertake any form of address selection.
The path chosen for forward and reverse direction path flows is a
decision made by the routing system.
This approach generally meets all the goals for multi-homing
approaches with one notable exception: scaleability. Each site that
multi-homes in this fashion adds a further entry in the global
inter-domain routing table. Within the constraints of current
routing and forwarding technologies, it is not clearly evident that
this approach can scale to encompass a population of multi-homed
sites of the order of, for example, 10**7 such sites. The
implication here is that this would add a similar number of unique
prefixes into the inter-domain routing environment, which in turn
would add to the storage and computational load imposed on
inter-domain routing elements within the network. This scale of
additional load is not supportable within the current capabilities of
the IPv4 global Internet, nor is it clear at present that the routing
capabilities of the entire network could be expanded to manage this
load in a cost-effective fashion, within the bounds of the current
inter-domain routing protocol architecture.
One other goal, transport-layer surviveability, is potentially at
risk in this approach. Dynamic changes within the network trigger
the routing system to converge to a new stable distributed forwarding
state. This process of convergence within the distributed routing
system may include the network generating unstable transient
forwarding paths, as well as taking an indeterminate time to
complete. This in term may trigger upper-level protocol timeouts and
possible session resets.
5.2. Multi-Homing: Mobility
Preserving established communications through movement is similar to
preserving established communications through outages in multi-homed
sites as both scenarios require the capability of dynamically
changing the locators used during the communication while
maintaining, unchanged, the endpoint identifier used by Upper Layer
Protocol (ULP). Since MIPv6 protocol [RFC3775] already provides the
required support to preserve established communications through
movement, it seems worthwhile to explore whether it could also be
used to provide session survivability in multi-homed environments.
MIPv6 uses a preferred IP address, the Home Address (HoA), as a
stable identifier for the mobile node (MN). This identifier is then
dynamically mapped to a valid locator (Care-of Address, or CoA) that
corresponds to the current attachment point within the network
topology. When the MN is at the Home Network, the HoA is used both
as locator and as identifier. When the MN is not at the Home
Network, the HoA is used as an identifier, and the CoA is used as
locator. A relaying agent (Home Agent) placed in the Home Network is
used to forward packets addressed to the HoA to the current location,
specified by the CoA. After each movement, the MN must inform its
Home Agent of the new CoA and optionally inform those entities with
which it has established communications (Correspondent Nodes, or
CNs). The mapping between the HoA and the current CoA is conveyed
using Binding Update (BU) messages.
When the BU message is exchanged between the MN and the Home Agent,
it is possible to assume the existence of a pre-established Security
Association that can be used to protect the binding information.
However, when the BU message is exchanged between the MN and the CN,
it is not possible to assume the existence of such a Security
Association. In this case, it is necessary to adopt an alternative
mechanism to protect the binding information contained in the
message. The selected mechanism is called the Return Routeability
procedure, and the background for its design is detailed in [rosec].
The goal of the mechanism is to allow the CN to verify that the MN
that is claiming that an HoA is currently located at a CoA is
entitled to make such claim; this essentially means that the HoA was
assigned to the MN, and that the MN is currently located at the CoA.
In order to verify these updates, the CN sends two different secrets,
one to the claimed HoA and another one to the claimed CoA. If the MN
receives both secrets, this means that the Home Agent located at the
Home Network has a trust relationship with the MN, that it has
forwarded the secret sent to the HoA, and that the MN is receiving
packets sent to the CoA. By including authorisation information
derived from both secrets within the BU message, the MN will be able
to prove to the CN that the claimed binding between the HoA and the
CoA is valid.
The lifetime of the binding that is created in the CN using
authorisation information obtained through the Return Routeability
procedure is limited to 7 minutes, in order to prevent time-shifted
attacks [rosec]. In a time-shifted attack, an attacker located along
the path between the CN and the MN forges the Return Routeability
packet exchange. The result of such an attack is that the CN will
forward all the traffic addressed to the HoA to the CoA selected by
the attacker. The attacker can then leave the position along the
path, but the effects of the attack will remain until the binding is
deleted, shifting in time the effect of the attack. By limiting the
lifetime of the binding in the CN, the effect of this attack is
reduced to 7 minutes, because after that period a new Return