Routeability procedure is needed to extend the binding lifetime. It
should be noted that the Return Routeability procedure is vulnerable
to "man-in-the-middle" attacks, since an attacker located along the
path between the CN and the MN can forge the periodic Return
Routeability packet exchange.
The possible application of the MIPv6 protocol to the multi-homing
problem would be to use BU messages to convey information in advance
about alternative addresses that could be used following an outage in
the path associated with the currently used address.
In this scenario, the multi-homed host adopts the MN role and the
host outside the multi-homed site adopts the CN role. When a
communication is established between the multi-homed host and the
external host, the address used for initiating the communication is
used as an HoA. The communication continues using this address as
long as no outage occurs. If an outage occurs and the HoA becomes
unreachable, an alternative address of the multi-homed node is used
as a CoA. In this case, the multi-homed node sends a BU message to
the external host, informing it about the new CoA to be used for the
HoA, so that the established communication can be preserved using the
alternative address. However, such a BU message has to be validated
using authorisation information obtained through the Return
Routeability procedure, which implies that the binding lifetime will
be limited to a fixed period of no more than 7 minutes. The result
is that the binding between the HoA and the new CoA will expire after
this interval has elapsed, and then the HoA will be used for the
communication. Since the HoA is unreachable because of the outage,
the communication will be interrupted. It should be noted that it is
not possible to acquire new authorisation information by performing a
new Return Routeability procedure, because it requires communication
through the HoA, which is no longer reachable. Consequently, a
mechanism based on the MIPv6 BU messages to convey information about
alternative addresses will preserve communications only for 7
minutes.
The aspect of MIPv6 that appears to present issues in the context of
multi-homing is the Return Routeability procedure. In MIPv6,
identity validity is periodically tested by return routeability of
the identity address. This regular use of a distinguished locator as
the identity token cannot support return reachability in the
multi-homing context, in the event of extended failure of the path
that is associated with the identity locator.
5.3. Multi-homing: Identity Considerations
The intent of multi-homing in the IPv6 domain is to achieve an
outcome that is comparable to that of multi-homed IPv4 sites using
routing to support multi-homing, without an associated additional
load being imposed on the IPv6 routing system. The overall intent of
IPv6 is to provide a scalable protocol framework to support the
deployment of communications services for an extended period of time,
and this implies that the scaling properties of the deployment
environment remain tractable within projections of size of deployment
and underlying technology capabilities. Within the inter-domain
routing space, the basic approach used in IPv4 and IPv6 is to attempt
to align address deployment with network topology, so that address
aggregation can be used to create a structured hierarchy of the
routing space.
Within this constraint of topological-based address deployment and
provider-aggregateable addressing architectures, the local site that
is connected to multiple providers is delegated addresses from each
of these providers’ address blocks. In the example network in
Figure 1, the local multi-homed host will conceivably be addressed in
two ways: one using transit provider A’s address prefix and the other
using transit provider B’s address prefix.
If remote host R is to initiate a communication with the local
multi-homed host, it would normally query the DNS for an address for
the local host. In this context, the DNS would return two addresses.
one using the A prefix and the other using the B prefix. The remote
host would select one of these addresses and send a packet to this
destination address. This would direct the packet to the local host
along a path through A or B, depending on the selected address. If
the path between the local site and the transit provider fails, then
the address prefix announced by the transit provider to the
inter-domain routing system will continue to be the provider’s
address prefix. The remote host will not see any change in routing,
yet packets sent to the local host will now fail to be delivered.
The question posed by the multi-homing problem is: "If the remote
host is aware of multi-homing, how could it switch over to using the
equivalent address for the local multi-homed host that transits the
other provider?"
If the local multi-homed host wishes to initiate a session with
remote host R, it needs to send a packet to R with a valid source and
destination address. While the destination address is that of R,
what source address should the local host use? There are two
implications for this choice. Firstly, the remote host will, by
default use this source address as the destination address in its
response, and hence this choice of source address will direct the
reverse path from R to the local host. Secondly, ISPs A and B may be
using some form of reverse unicast address filtering on source
addresses of packets passed to the ISP, as a means of preventing
source address spoofing. This implies that if the multi-homed
address selects a source address from address prefix A, and the local
routing to R selects a best path via ISP B, then ISP B’s ingress
filters will discard the packet.
Within this addressing structure there is no form of routing-based
repair of certain network failures. If the link between the local
site and ISP A fails, there is no change in the route advertisements
made by ISP A to its external routing peers. Even though the
multi-homed site continues to be reachable via ISP B, packets
directed to the site using ISP A’s prefix will be discarded by ISP A,
as the destination is unreachable. The implication here is that, if
the local host wishes to maintain a session across such events, it
needs to communicate to remote host R that it is possible to switch
to a destination address for the multi-homed host that is based on
ISP B’s address prefix. In the event that the local host wishes to
initiate a session at this point, then it may need to use an initial
source locator that reflects the situation that the only viable
destination address to use is the one that is based on ISP B’s
address prefix. It may be the case that the local host is not aware
of this return routeability constraint, or it may not be able to
communicate this information directly to R, in which case R needs to
discover or be passed this information in other ways.
In an aggregated routing environment, multiple transit paths to a
host imply multiple address prefixes for the host, where each
possible transit path is identified by an address for the host. The
implication of this constraint on multi-homing is that paths being
passed to the local multi-homed site via transit provider ISP A must
use a forwarding-level destination IP address drawn from ISP A’s
advertised address prefix set that maps to the multi-homed host.
Equally, packets being passed via the transit of ISP B must use a
destination address drawn from ISP B’s address prefix set. The
further implication here is that path selection (ISP A vs. ISP B
transit for incoming packets) is an outcome of the process of
selecting an address for the destination host.
The architectural consideration here is that, in the conventional IP
protocol architecture, the assumption is made that the
transport-layer endpoint identity is the same identity used by the
internet forwarding layer, namely the IP address.
If multiple forwarding paths are to be supported for a single
transport session and if path selection is to be decoupled from the
functions of transport session initiation and maintenance, then the
corollary in architectural terms appears to be that some changes are
required in the protocol architecture to decouple the concepts of
identification of the endpoint and identification of the location and
associated path selection for the endpoint. This is a fundamental
change in the semantics of an IP address in the context of the role
of the endpoint address within the end-to-end architectural model
[e2e]. This change in the protocol architecture would permit a
transport session to use an invariant endpoint identity value to
initiate and maintain a session, while allowing the forwarding layer
to dynamically change paths and associated endpoint locator
identities without impacting on the operation of the session. Such a
decoupling of the concepts of identities and locators would not add
any incremental load to the inter-domain routing system.
Some generic approaches to this form of separation of endpoint
identity and locator value are described in the following sections.
5.4. Multi-homing: Identity Protocol Element
One approach to this objective is to add a new element into the model
of the protocol stack.
The presentation to the upper-level protocol stack element (ULP)
would be endpoint identifiers to uniquely identify both the local
stack and the remote stack. This will provide the ULP with stable
identifiers for the duration of the ULP session.
The presentation to the lower-level protocol stack element (LLP)
would be of the form of a locator. This implies that the protocol
stack element would need to maintain a mapping of endpoint identifier
values to locator values. In a multi-homing context, one of the
essential characteristics of this mapping is that it needs to be
dynamic, in that environmental triggers should be able to trigger a
change in mappings. This in turn would correspond to a change in the
paths (forward and/or reverse) used by the endpoints to traverse the
network. In this way, the ULP session is defined by a peering of
endpoint identifiers that remain constant throughout the lifetime of
the ULP session, while the locators may change to maintain end-to-end
reachability for the session.
The operation of the new protocol stack element (termed here the
"endpoint identity protocol stack element", or EIP) will establish a
synchronised state with its remote counterpart. This will allow the
stack elements to exchange a set of locators that may be used within
the context of the session. A change in the local binding between
the current endpoint identity value and a locator will change the
source locator value used in the forwarding-level packet header. The
actions of the remote EIP upon receipt of this packet with the new
locator is to recognise this locator as part of an existing session
and, upon some trigger condition, to change its session view of the
mapping of the remote endpoint identity to the corresponding locator
and use this locator as the destination locator in subsequent packets
passed to the LLP.
From the perspective of the IP protocol architecture, there are two
possible locations to insert the EIP into the protocol stack.
One possible location is at the upper level of the transport
protocol. Here the application program interface (API) of the
application-level protocols would interface to the EIP element, and
use endpoint identifiers to refer to the remote entity. The EIP
would pass locators to the API of the transport layer.
The second approach is to insert the EIP between the transport and
internet protocol stack elements, so that the transport layer would
function using endpoint identifiers and maintain a transport session
using these endpoint identifiers. The IP or internetwork layer would
function using locators, and the mapping from endpoint identifier to
locator is undertaken within the EIP stack element.
5.5. Multi-homing: Modified Protocol Element
As an alternative to insertion of a new protocol stack element into
the protocol architecture, an existing protocol stack element could
be modified to include the functionality performed by the EIP
element. This modification could be undertaken within the transport
protocol stack element or within the internet protocol stack element.
The functional outcome from these modifications would be to create a
mechanism to support the use of multiple locators within the context
of single-endpoint-to-single-endpoint communication.
Within the transport layer, this functionality could be achieved, for
example, by binding a set of locators to a single session and then
communicating this locator set to the remote transport entity. This
would allow the local transport entity to switch the mapping to a
different locator for either the local endpoint or the remote
endpoint, while maintaining the integrity of the ULP session.
Within the IP level, this functionality could be supported by a form
of dynamic rewriting of the packet header as it is processed by the
protocol element. Incoming packets with the source and destination
locators in the packet header are mapped to packets with the
equivalent endpoint identifiers in both fields, and the reverse
mapping is performed to outgoing packets passed from the transport
layer. Mechanisms that support direct rewriting of the packet header
are potential candidates in this approach. Other potential
candidates are various forms of packet header transformations using
encapsulation, where the original endpoint identifier packet header
is preserved in the packet and an outer-level locator packet header
is wrapped around the packet as it is passed through the internet
protocol stack element.
There are common issues in all these scenarios: what state is kept,
which part of the protocol stack keeps this state, how state is
maintained with additions and removals of locator bindings, and
whether only one piece of code is aware of the endpoint/locator split
or do multiple protocol elements have to be modified? For example,
if the functionality is added at the internetworking (IP) layer,
there is no context of an active transport session, so that removal
of identity/locator state information for terminated sessions needs
to be triggered by some additional mechanism from the transport layer
to the internetworking layer.
5.6. Modified Site-Exit and Host Behaviors
The above approaches all assume that the hosts are explicitly aware
of the multi-homed environment and use modified protocol behaviour to
support multi-homing functionality. A further approach to this
objective is to split this functionality across a number of network
elements and potentially perform packet header rewriting from a
persistent endpoint identity value to a locator value at a remote
point.
One possible approach uses site-exit routers to perform some form of
packet header manipulation as packets are passed from the local
multi-homed site to a particular transit provider. The local site
routing system will select the best path to a destination host based
on the remote host’s locator value. The local host will write its
endpoint identity as the source address of the packet. When the
packet reaches a site-exit router, the site-exit router will rewrite
the source field of the packet to a corresponding locator that
selects a reverse path through the same transit ISP when the locator
is used as a destination locator by the remote host. In order to
preserve session integrity, a corresponding reverse transformation
must be undertaken on incoming packets: the destination locator has
to be mapped back to the host’s endpoint identifier. There are a
number of considerations whether this is best performed at the
site-exit router when the packet is passed into the site, or by the
local host.
Packet header rewriting by remote network elements has a large number
of associated security considerations. Any packet rewriting
mechanism has to provide proper protection against the attacks
described in [threats], in particular against redirection attacks.
An alternative for packet header rewriting at the site-exit point is
for the host to undertake the endpoint-to-locator mapping, using one
of the approaches outlined above. The consideration here is that
there is a significant deployment of unicast reverse-path filtering
in Internet environments as a counter-measure to source address
spoofing. Using the example in Figure 1, if a host selects a locator
drawn from the ISP B address prefix and local routing directs that
packet to site-exit router A, then a packet passed to ISP A would be
discarded by such filters. Various approaches have been proposed to
modify the behaviour of the site forwarding environment, all with the
end effect that packets using a source locator drawn from the ISP B
address prefix are passed to site-exit router B. These approaches
include forms of source address routing and site-exit router
hand-over mechanisms, as well as augmentation of the routing
information between site-exit routers and local multi-homed hosts, so
that the choice of locator by the local host for the remote host is
consistent with the current local routing state for the local site to
reach the remote host.
6. Approaches to Endpoint Identity
Both the approach of the addition of an identity protocol element and
the approach of modification of an existing protocol element assume
some form of exchange of information that allows both parties to the
communication to be aware of the other party’s endpoint identity and
the associated mapping to locators. There are a number of possible
approaches for implementing this information exchange.
The first such possible approach, termed here a "conventional"
approach, encapsulates the protocol data unit (PDU) passed from the
ULP with additional data elements that specifically refer to the
function of the EIP. The compound data element is passed to the LLP
as its PDU. The corresponding actions on receipt of a PDU from a LLP
is to extract the fields of the data unit that correspond to the EIP
function, and pass the remainder of the PDU to the ULP. The EIP
operates in an "in-band" mode, communicating with its remote peer
entity through additional information wrapped around the ULP PDU.
This is equivalent to generic tunnelling approaches where the outer
encapsulation of the transmitted packet contains location address
information, while the next-level packet header contains information
that is to be exposed and used at the location endpoints and, in this
case, is identity information.
Another approach is to allow the EIP to communicate using a separate
communications channel, where an EIP generates dedicated messages
that are directed to its peer EIP, and it passes these PDUs to the
LLP independently of the PDUs that are passed to the EIP from the
ULP. This allows an EIP to exchange information and synchronise
state with the remote EIP semi-independently of the ULP protocol
exchange. As one part of the EIP function is to transform the ULP
PDU to include locator information, there is an associated
requirement to ensure that the EIP peering state remains synchronised
to the exchange of ULP PDUs, so that the remote EIP can correctly
recognise the locator-to-endpoint mapping for each active session.
Another potential approach here is to allow the endpoint-to-locator
mappings to be held by a third party. This model is already used for
supporting the name-to-IP address mappings performed by the Domain
Name System (DNS), where the mapping is obtained by reference to a
third party, namely, a DNS resolver. A similar form of third-party
mapping between endpoints and a locator set could be supported
through the use of the DNS or a similar third party referential
mechanism. Rather than have each party exchange endpoint-to-locator
mappings, this approach would obtain this mapping as a result of a
lookup for a DNS Endpoint-to-Locator set map contained as DNS
Resource Records, for example.
6.1. Endpoint Identity Structure
The previous section has used the term "endpoint identity" without
examining what form this identity may take. A number of salient
considerations regarding the structure and form of this identity
should be enumerated within an architectural overview of this space.
One possible form of an identity is the use of identity tokens lifted
from the underlying protocol’s "address space". In other words an
endpoint identity is a special case instance of an IPv6 protocol
address. There are a number of advantages in using this form of
endpoint identity, since the suite of IP protocols and associated
applications already manipulates IP addresses. The essential
difference in a domain that distinguishes between endpoint identity
and locator is that the endpoint identity parts of the protocol would
operate on those addresses that assume the role of endpoint
identities, and the endpoint identity/locator mapping function would
undertake a mapping from an endpoint "address" to a set of potential
locator "addresses". It would also undertake a reverse mapping from
a locator "address" to the distinguished endpoint identifier
"address". The IP address space is hierarchically structured,
permitting a suitably efficient mapping to be performed in both
directions. The underlying semantics of addresses in the context of
public networking includes the necessary considerations of global
uniqueness of endpoint identity token values.
It is possible to take this approach further and allow the endpoint
identifier to also be a valid locator. This would imply the
existence of a "distinguished" or "home" locator, and other locators
could be dynamically mapped to this initial locator peering as
required. The drawback of this approach is that the endpoint
identifier is now based on one of the transit provider’s address
prefixes, and a change of transit provider would necessarily require
a change of endpoint identifier values within the multi-homed site.
An alternative approach for address-formatted identifiers is to use
distinguished identity address values that are not part of the global
unicast locator space, allowing applications and protocol elements to
distinguish between endpoint identity values and locators based on
address prefix value.
It is also possible to allow the endpoint identity and locator spaces
to overlap, and to distinguish between the two realms by the context
of usage rather than by a prefix comparison. However, this reuse of
the locator token space for identity tokens has the potential to
create the anomalous situation where a particular locator value is
used as an identity value by a different endpoint. It is not clear
that the identity and locator contexts can be clearly disambiguated
in every case, which is a major drawback to this particular approach.
If identity values are to be drawn from the protocol’s address space,
it would appear that the basic choice is to either draw these
identity values from a different part of the address space or to use
a distinguished or home address as both a locator and an identity.
This latter option, that of using a locator as the basis of an
endpoint identity on a locator, when coupled with a provider-
aggregated address distribution architecture, leads to a multi-homed
site using a provider-based address prefix as a common identity
prefix. As with locator addresses in the context of a single-homed
network, a change of provider connectivity implies a consequent
renumbering of identity across the multi-homed site. If avoiding
such forced renumbering is a goal here, there would be a preference
in drawing identity tokens from a pool that is not aligned with
network topology. This may point to a preference from this sector
for using identity token values that are not drawn from the locator
address space.
It is also feasible to use the fully qualified domain name (FQDN) as
an endpoint identity, undertaking a similar mapping as described
above, using the FQDN as the lookup "key". The implication is that
there is no default "address" associated with the endpoint
identifier, as the FQDN can be used in the context of session
establishment and a DNS query can be used to establish a set of
initial locators. Of course, it is also the case that there may not
necessarily be a unique endpoint associated with a FQDN, and in such
cases, if there were multiple locator addresses associated with the