Network Working Group M. Bagnulo
Internet-Draft A. Garcia-Martinez
Expires: August 26, 2003 I. Soto
UC3M
February 25, 2003
Application of the MIPv6 protocol to the multi-homing problem
draft-bagnulo-multi6-mnm-00
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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."
The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 26, 2003.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract
This note attempts to describe how to apply the MIPv6 protocol to
provide fault tolerance to transport layer connections established
between a multi-homed host and other hosts in the Internet.
Specifically, this note addresses the usage of MIPv6 signaling
messages to convey information about alternative address to be used
when an outage occurs. Additionally, possible mechanisms to detect
failures affecting the currently used path are explored.
Bagnulo, et al. Expires August 26, 2003 [Page 1]
Internet-Draft Application of MIPv6 to multi-homing February 2003
1. Introduction
Several times it has been claimed that the MIPv6 [1] protocol could
be a useful tool to deal with the multi-homing problem. A few years
ago, the application of MIPv6 protocol to the multi-homing problem
was proposed by F. Dupont in [2]. Since that time, the MIPv6 protocol
has been greatly improved and substantial modifications have been
introduced, particularly in the security aspects of the protocol.
Recently, C. Huitema suggested in [3] that mobility extensions could
be used to convey alternative address information of multi-homed
hosts. This note attempts to complement previous work by providing a
complete proposal of how to apply the MIPv6 protocol to provide fault
tolerance to transport layer connections established between a
multi-homed host and hosts in the Internet. Specifically, this note
addresses the usage of MIPv6 signaling messages to convey information
about alternative address to be used when an outage occurs.
Additionally, possible mechanisms to detect failures affecting the
currently used path are explored.
Bagnulo, et al. Expires August 26, 2003 [Page 2]
Internet-Draft Application of MIPv6 to multi-homing February 2003
2. Acronyms
MHH: Multi-Homed Host
CN: Correspondent Node
BU: Binding Update
BA: Binding Acknowledgment
HoA: Home Address
CoA: Care-of Address
HoTI: Home Test Init
HoT: Home Test
CoTI: Care-of Test Init
CoT: Care-of Test
PA: Provider Aggregatable
SEAA: Site Exit Anycast Address
SEAAA: Site Exit Anycast Address corresponding to ISPA
SEAAB: Site Exit Anycast Address corresponding to ISPB
Bagnulo, et al. Expires August 26, 2003 [Page 3]
Internet-Draft Application of MIPv6 to multi-homing February 2003
3. Application Scenario
+-----+
|Host1|
| CN |
+-----+
|
...
|
_______|_______________________________________
| |
| |
| |
|______________________________________________|
| |
| |
| link2
link1 |
| |
+---------------+ +---------------+
| ISPA | | ISPB |
| PA::/nA | | PB::/nB |
+---------------+ +---------------+
| |
| |
| |
link3 link4
__|____________________________|___
| RA RB |
| +-----+ |
|Multi-homed end-site |Host2| |
|PA:Site::/48 | MHH | |
|PB:Site::/48 +-----+ |
|___________________________________|
The application scenario consists of a multi-homed end-site that
obtains global connectivity through two (or more) ISPs i.e. ISPA and
ISPB. Since the end-site is multi-homed and provider aggregatable
addresses are being used, the site has obtained two address ranges:
one delegated from ISPA address range i.e. PA:Site::/48 and the
other one from ISPB address space i.e. PB:Site::/48. Furthermore, in
order to benefit from multi-homing, hosts within the site have to be
Bagnulo, et al. Expires August 26, 2003 [Page 4]
Internet-Draft Application of MIPv6 to multi-homing February 2003
reachable through both ISPs. This implies that hosts have to
configure one address from each ISP address range that the site has
obtained. For instance, in the case of Host2, two addresses are
configured i.e. PA:Site:Host2 and PB:Site:Host2. So, this
configuration provides some Fault Tolerance capabilities since Host1
can reach Host2 through ISPA, using as destination address
PA:Site:Host2 and it can also reach it through ISPB using as
destination address PB:Site:Host2. This means that if there is an
outage in one of the ISPs, ISPA for instance, Host1 can still reach
Host2 using the alternative address i.e. PB:Site:Host2. However, this
configuration does not allow the preservation of established
connections through an outage event. This is the result of following
constraints:
- Most connections established at the transport level and above
identify the endpoints involved in the communication by their IP
addresses, imposing that they must remain unchanged during the
lifetime of the connection.
- In order to preserve aggregation benefits, Provider Aggregatable
addresses delegated to the end-site by an ISP are to be routed toward
the site through this ISP, so that it routes them toward the final
destination. In the application scenario considered, addresses
containing the prefix PA::/nA are routed to ISPA, who then routes
them to the end-site considered.
These constraints imply that if a connection between Host1 and Host2
is established using PA:Site:Host2 as address for Host2, packets
flowing to Host2 will be routed through ISPA and only through ISPA.
Then, if during the lifetime of this connection an outage occurs in
ISPA, the connection will be dropped, even if a path between Host1
and Host2 is available. This is so because packets whose final
destination address contains the PA::/nA prefix have no available
route to Host2, since they can not be routed through ISPB and packets
addressed to the alternative destination of Host2 (PB:Site:Host2) are
not recognized by transport and uppers layers as belonging to the
connection established using PA:Site:Host2. This note presents a
mechanism for preserving established communications during an outage
based in the MIPv6 protocol.
Bagnulo, et al. Expires August 26, 2003 [Page 5]
Internet-Draft Application of MIPv6 to multi-homing February 2003
4. Application of the MIPv6 protocol to the multi-homing problem
4.1 Required capabilities
In order to preserve established connections throughout an outage,
the following capabilities are required:
1- A path failure detection mechanism, that enables end-hosts to
detect outages in the path that is currently being used. When a
failure is detected a recovery mechanism, such as routing packets
through an alternative path, is triggered.
2- A protocol to inform the other end of the communication about the
alternative path that is to be used. Since Provider Aggregatable
address are used, alternative paths (alternative ISPs) are
represented by alternative destination addresses. So the protocol is
used for conveying alternative destination address.
3- A mechanism that allows packets carrying the alternative address
as destination address to be recognized as belonging to the
established connection. In order to be transparent to transport layer
and above, such mechanism must restore the original destination
address when the final destination is reached.
4- Tools to ensure compatibility with ingress filtering mechanisms.
Since an alternative ISP will be used when a outage occurs, packets
carrying the original source address would be incompatible with
ingress filtering mechanisms.
4.2 Overview
MIPv6 protocol provides the tools needed to satisfy all the above
requirements, as it will presented next.
In order to apply the MIPv6 protocol to the considered scenario, the
first step is to map the multi-homing scenario to a mobility
scenario. Since the multi-homed host (MHH) has the need to use
multiple alternative addresses in a given connection, it will have
the role of mobile node, and the node that it is communicating with
will have the role of Correspondent Node (CN). It is assumed that
Correspondent Nodes have support for route optimization. Home Agent
capabilities are not required.
4.2.1 Required capability #2
The most natural application of the MIPv6 protocol seems to be the
usage of Binding Update (BU) messages to inform the Correspondent
node that an alternative address is to be used for the established
Bagnulo, et al. Expires August 26, 2003 [Page 6]
Internet-Draft Application of MIPv6 to multi-homing February 2003
communication, fulfilling requirement #2. So, when the MHH detects
that the currently used path becomes unavailable, it would send a
Binding Update message to the Correspondent Node, informing that an
alternative address is to be used. In MIPv6 terminology, the original
address would be the Home Address (HoA) and the new alternative
address would be the Care-of Address (CoA). However, MIPv6 security
requirements impose the return routability procedure to enable the
required BU message authorization. Such procedure implies the
exchange of Home Test Init (HoTI) and Home Test (HoT) messages using
the HoA and the exchange of Care-of Test Init (CoTI) and Care-of Test
(CoT) messages using the CoA. Such exchanges are designed to verify
that the host reachable through both the CoA and the HoA is the same.
This means that the MHH needs to be reachable through both paths when
these exchanges are performed, implying that these exchanges can not
be performed successfully once an outage has occurred. So, the return
routability procedure should be performed when a connection with a
new CN is established allowing that this connection is protected
during its complete lifetime.
However, nonces used for the generation of the home keygen token and
the care-of keygen token have a limited lifetime, imposing periodical
return routability checks, in order to ensure that valid BU
authorization information is available when an outage occurs. The
time constraints imposed by MIPv6 are:
1- It is recommended by MIPv6 specification that nonces remain valid
for at least MAX_TOKEN_LIFE seconds i.e. 210 seconds after it has
been used to construct a return routability message.
2- MIPv6 also specifies that the CN must not accept nonces beyond
MAX_NONCE_LIFE seconds i.e. 240 seconds after their first use.
These constraints impose the performance of the the return
routability procedure every MAX_TOKEN_LIFE minus the time required to
perform the procedure, which would include the Round Trip Time (RTT)
and the processing time. If the typical value used for TCP connection
establishment timeout (75 seconds) is accepted as a reasonable upper
bound to the RTT, and the processing time is considered to be
negligible compared to the RTT considered, the return routability
procedure needs to be performed every 135 seconds.
4.2.2 Required capability #3
Once that the availability of the information needed to authorize BU
messages is guaranteed, the MHH is prepared to re-route its
connections through an alternative address when an outage occurs. So,
when the outage is detected, the MHH will send a BU message to the
CN, informing that a new address (CoA) is to be used. Then, the CN
Bagnulo, et al. Expires August 26, 2003 [Page 7]
Internet-Draft Application of MIPv6 to multi-homing February 2003
will address packets to the new CoA. However, packets addressed to
CoA have to be recognized as belonging to the established connection.
This can be achieved by using the Type 2 Routing Header specified in
MIPv6, in the same way that it is used for supporting mobility. That
is, after receiving a valid BU, the CN addresses packets to the MHH
to the new CoA, and it also includes a Type 2 Routing Header carrying
the HoA. The resulting behavior is that when these packets reach the
MHH through the CoA, the Routing Header is processed and the HoA is
restored and packets are presented to the transport and above layers
as being addressed to the HoA, preserving established connections.
4.2.3 Required capability #1
Additionally, a failure detection mechanism that triggers the
generation of BU messages is required to provide a complete solution.
A possible approach for this is to rely on transport and/or
application layer capabilities. Some transport protocols such as TCP
provide a reliable service, implementing time-out and retransmission
of packets. When unreliable transport protocols are used, some
applications provide recovery mechanisms that imply retransmission of
lost packets. These retransmission events can be used as a failure
indication to trigger the usage of an alternative address. However,
this approach requires that the transport layer and/or applications
inform the IP layer about retransmission events, imposing
modifications to current implementations. Besides, some applications,
such as interactive voice applications, do not employ packet recovery
mechanisms. In these cases, an additional failure detection mechanism
has to be provided, so that these applications can benefit from
multi-homing.
It is then deemed necessary to provide a failure detection mechanism.
Such mechanism should be provided at the IP layer so that it is
available for all applications and transport layers.
An simple end-host path failure detection mechanism can be based on
the exchange of keep-alive messages. Since this is a network layer
mechanism, a possibility is the exchange of ICMP messages. For
instance, ICMP echo request/reply can be used, profiting that most IP
stacks already include ICMP functionality. This would imply that only
MHH stacks need to be modified in order to provide the failure
detection mechanism.
Another possibility is the usage of HoTI/HoT messages. As it was
mentioned above, return routability procedure needs to be performed
periodically, implying message exchange between the MHH and the CN.
However, in order to provide a failure detection mechanism, the
message exchange frequency has to be increased not only because its
period of 135 seconds may be deemed as unacceptable for certain
Bagnulo, et al. Expires August 26, 2003 [Page 8]
Internet-Draft Application of MIPv6 to multi-homing February 2003
applications, but because valid authorization information is required
for sending the BU message. Since a failure is indicated by at least
one keep-alive message lost, it is necessary that after such event
valid BU authorization information is still available, which implies
that the information acquired during the previous message exchange is
still valid. Then, assuming that a failure is indicated by the lost
of two consecutive keep-alive packets, HoTI messages have to be
generated by the MHH every MAX_TOKEN_LIFE/3 seconds i.e. 70 seconds.
Then if two HoTI messages are lost, that is, no reply is received 140
seconds after a HoTI was sent, a BU message is generated and an
alternative route is used. Note that HoT replies are linked to HoTI
requests by the home init cookie parameter. The simple mechanism
presented provides the minimum required functionality while
respecting the timing imposed by the return routability procedure
parameters. Failure response time can be improved by increasing the
message exchange frequency. Moreover, adaptive mechanism, such as the
TCP time-out calculation mechanism can also be contemplated, as long
as they respect the timing constraints imposed by MIPv6. However, it
should be noted that these changes only need to be performed at the
MHH, since the CN role is limited to reply messages generated by the
MHH. This allows that multiple failure detection policies can be
implemented without affecting interoperability. It should also be
noted that only HoTI/HoT message exchange frequency need to be
increased, since only the currently used path need to be tested. In
the case where more than two paths are available, testing all the
available paths may provide some valuable information at the time an
outage occurs, since it would enable a more educated path selection.
In this case, CoTI/CoT messages can be used to test alternative paths
and compare them. However, in the case of dual homed sites, where
only one alternative paths is available, this testing does not seem
to provide relevant information.
4.2.4 Required capability #4
When a MHH has multiple PA addresses configured in its interface,
source address selection implies the selection of the ISP to be used
in the return path. Moreover, because of ISP ingress filtering
mechanism, source address selection also imposes the ISP to be used
in the forward path, requiring additional functionalities at the
multi-homed site to guarantee the appropriate ISP selection as
discussed in [3]. Besides, when host based path failure detection
mechanisms are used, the only party that has the information needed
for selecting the path to be used is the host itself. So, in order to
guarantee the compatibility with ingress filtering mechanisms, the
MHH can select the exit ISP by means of a Routing Header. In order to
simplify ISP selection, the Site Exit Anycast Address defined in [3]
can be used. Then, after performing source address selection, the MHH
addresses packets to the Site Exit Router Anycast Address
Bagnulo, et al. Expires August 26, 2003 [Page 9]
Internet-Draft Application of MIPv6 to multi-homing February 2003
corresponding to the ISP that has assigned the address used as
source address and it includes the final destination address in a
Routing Header. It should be noted that the Site Exit Anycast Address
is automatically deduced from the source address, so no additional
configuration is required.
Additional complexity results when an outage occurs. In this case, an
alternative ISP is to be used for coursing packets. Source address
filtering mechanisms of the alternative ISP precludes the flow of
packets carrying the address originally used i.e. the HoA. However,
the CN only recognizes packets as belonging to the established
connection if they carry the original HoA. In order to overcome this
issue, the Home Address Destination Option is to be used, so that the
source address corresponding to the alternative ISP (i.e. the CoA) is
carried in the Source Address field of the IPv6 header and the
original address (i.e. the HoA) is carried within the Home Address
Option. When the packet is received by the CN, it processes the Home
Address Option and restores the HoA as the Source Address. Note that
when including the Routing Header to perform exit ISP selection,
Site Exit Anycast Address have to be selected according to the source
address actually carried in the Source Address field of the IPv6
packet and has no relation with the HoA carried in a Home Address
Option.
4.3 Resulting Behavior
In this section, the complete operation of the solution in the
application scenario is described.
First of all, a communication is established between the MHH and the
CN. This communication can be initiated by any of the parties.
If the communication is initiated by the CN, it will first obtain at
least one of the MHH's addresses, for instance using the DNS. If all
the MHH's addresses are listed in the DNS, the CN will pick one and
try to initiate the communication using this address. If a failure
has occurred along the path, the attempt to initiate the
communication will fail and the CN will try again with another
address. Eventually, a packet from CN will reach MHH.
In the application scenario, Host1 obtains PA:Site:Host1 and
PB:Site:Host1 from the DNS. Then it will try to initiate the
communication using PA:Site:Host1 and if this fails it will try using
PB:Site:Host1 (this is an arbitrary choice).
If the communication is initiated by the MHH, it will obtain CN's
address, using for instance the DNS. Then, it will apply the source
address selection algorithm which outcome will be the address to be
Bagnulo, et al. Expires August 26, 2003 [Page 10]
Internet-Draft Application of MIPv6 to multi-homing February 2003
used as source address when sending packets to the CN. The MHH
attempts to communicate with the CN using the selected source
address. In order to avoid that the ISP ingress filtering mechanism
discarded this packet, MHH addresses the packet to the Site Exit
Anycast Address of the ISP that assigned the source address selected
and includes the CN address within a Routing Header.If a failure
along the path has occurred, the communication will fail and MHH will
try with another source address, so that the packet is coursed
through an alternative ISP.
In the application scenario, according to [3],
Site Exit Anycast Addresses for ISPA is
PA:Site:FFFF:FFFF:FFFF:FFFF:FFFF (Hereafter SEAAA)
Site Exit Anycast Addresses for ISPB is
PB:Site:FFFF:FFFF:FFFF:FFFF:FFFF (Hereafter SEAAB)
Then, MHH will try first to send a first packet with:
IPv6 Header
Destination address: SEAAA
Source address: PA:Site:Host2
Routing Header
Type: 1
Address#1: Host1
If this packet fails, it will try with:
IPv6 Header
Destination address: SEAAB
Source address: PB:Site:Host2
Routing Header
Type: 1
Address#1: Host1
When the packet arrives to the corresponding site exit router, the
Routing Header will be processed and the Destination Address will be
set to Host1.
Once that MHH starts sending packets to CN, different address roles
Bagnulo, et al. Expires August 26, 2003 [Page 11]
Internet-Draft Application of MIPv6 to multi-homing February 2003
have been set i.e. the address used as Source Address in the first
packet flowing from MHH to CN will be the HoA and the other available
addresses of MHH will be CoAs. It should be noted that these roles
are assigned when the communication is established and they are not
preassigned. This means that any address can be HoA or CoA. Moreover,
a given address could be used as HoA in a communication with a given
host and used as CoA in a communication with another one.
In the application scenario, we suppose that the first packet flowing
from MHH to CN has PA:Site:Host2 as source address, so that:
PA:Site:Host2 is HoA and PB:Site:Host2 is CoA
Once that the first packet is carried from MHH to CN, the MHH has to
perform the return routability procedure in order to obtain valid
authorization data. This data is to be used if an outage occurs to
course packets using an alternative address. The return routability
procedure consists in exchanging HoTI/HoT messages using the HoA and
CoTI/CoT messages using CoA. These messages also have to include a
Routing Header to select appropriate exit ISP.
In the application scenario the following messages are exchanged:
First MHH sends HoTI and CoTI messages:
HoTI message
IPv6 Header
Destination Address: SEAAA
Source Address: PA:Site:Host2
Routing Header
Type: 1
Address#1: Host1
Mobility Header
Type: HoTI
Home Init Cookie: HCookie
Bagnulo, et al. Expires August 26, 2003 [Page 12]
Internet-Draft Application of MIPv6 to multi-homing February 2003
CoTI message
IPv6 Header
Destination Address: SEAAB
Source Address: PB:Site:Host2
Routing Header
Type: 1
Address #1: Host1
Mobility Header
Type: CoTI
Care-of Init Cookie: CCookie
The CN replies sending HoT and CoT messages as follows:
HoT message
IPv6 Header
Destination Address: PA:Site:Host2
Source Address: Host1
Mobility Header
Type: HoT
Home Init Cookie: HCookie (from HoTI message)
Home Nonce Index: HNI
Home Keygen Token: HKT
CoT message
IPv6 Header
Destination Address: PB:Site:Host2
Source Address: Host1
Mobility Header
Type: CoT
Care-of Init Cookie: CCookie (from CoTI message)
Care-of Nonce Index: CNI
Care-of Keygen Token: CKT
The goal of the CoTI/CoT message exchange is to maintain valid
authorization data in case an outage occurs, so it is performed every
135 seconds.
HoTI/HoT message exchange has two goals: first it provides valid
Bagnulo, et al. Expires August 26, 2003 [Page 13]
Internet-Draft Application of MIPv6 to multi-homing February 2003
authorization information in case an outage occurs and second it is
used as a path failure detection mechanism. This second goal imposes
that the HoTI/HoT exchange has to be performed every 70 seconds. Note
that HoTI-HoT message correlation is detected using the Home Init
cookie value.
If no outage occurs, the communication continues as it is, and HoTI/
HoT and CoTI/CoT messages exchanges continue until the communication
is finished.
The only difference with packets flowing from a single-homed site is
that they carry a Routing Header to perform exit ISP selection.
Then, all packets flowing from the MHH to the CN carry the
appropriate Routing Header to perform exit ISP selection according to
the Source Address. In this case, packets carry PA:Site:Host2 as
Source address so they carry SEAAA as Destination Address and they
include Host1 in the Routing Header.
If an outage occurs, it will be detected by the failure detection
mechanism and an alternative path will be used. If two consecutive
packets HoTI are not replied within 140 seconds after the first
message was sent, a failure will be assumed. This sets a timeout of
140 seconds for the first CoTI packet and a timeout of 70 secs for
the second message. IF this is the case, a BU message is sent,
informing the CN that the CoA will be used to exchange packets. This
BU message will carry authorization information obtained through the
last successful HoTI/HoT and CoTI/CoT message exchanges. Timing is
such, that this information is still valid when the BU reaches CN. In
order to confirm that the BU was successfully processed, a Binding
Acknowledgment (BA) is requested. According to MIPv6 specification,
if no BA is received within INITIAL_BINDACK_TIMEOUT (i.e. 1 second),
MHH retransmits the BU message increasing the sequence number until a
response is received. The retransmission uses an exponential back-off
process, doubling the timeout every time the BU is retransmitted
until a BA is received or the timeout period reaches
MAX_BINDACK_TIMEOUT (i.e. 32 seconds). Retransmission of BU using
this timeout can continue indefinitely according to the
specification. However, in this particular case, the authorization
information has a limited lifetime, so it is useless to continue with
the retransmissions once the information is no longer valid, which
occurs MAX_NONCE_LIFE (240 seconds) after the nonce was used for
creating the home keygen token.
In the application scenario, suppose that two consecutive HoTI
messages are not replied. In this case MHH send a BU message
containing:
Bagnulo, et al. Expires August 26, 2003 [Page 14]
Internet-Draft Application of MIPv6 to multi-homing February 2003
BU message
IPv6 Header
Destination Address: SEAAB
Source Address: PB:Site:Host2
Routing Header
Type: 1
Address #1: Host1
Destination Option Extension Header
Home Address Option
Home Address: PA:Site:Host2
Mobility Header
Type: Binding Update
Acknowledge: set
Home Registration: reset
Link-Local Compatibility:
Key Management Mobility Capability: ignored by CN
Sequence #: S
Lifetime: 0xffff
Mobility Options
Binding Authorization Data Option
Authenticator: First (96, HMAC_SHA1(Kbm, Mobility Data))
Being:
Mobility Data = PB:Site:Host2 | Host1 | Mobility Header Data
Kbm = SHA1 (HKT | CKT) (from HoT and CoT messages respectively)
Nonces Index Option
Home Nonce Index: HNI (from HoT message)
Care-of Nonce Index: CNI (from CoT message)
CN replies sending a BA as follows
Bagnulo, et al. Expires August 26, 2003 [Page 15]
Internet-Draft Application of MIPv6 to multi-homing February 2003
BA message
IPv6 Header
Destination Address: PB:Site:Host2
Source Address: Host1
Routing Header
Type: 2
Home Address: PA:Site:Host2
Mobility Header
Type: Binding Acknowledgment
Status: 0 (Binding Update Accepted)
Key Management Mobility Capability: 0
Lifetime: granted by CN
Sequence #: S (from BU)
Mobility Options
Binding Authorization Data Option
Authenticator: First (96, HMAC_SHA1(Kbm, Mobility Data))
Being:
Mobility Data = PB:Site:Host2 | Host1 | Mobility Header Data
Once that the BU and BA messages have been exchanged, alternative ISP
will be used to course packets between the MHH and the CN.
Packets from the CN to the MHH will contain a Type 2 Routing Header
in order to be routed through the alternative ISP:
Packets from CN to MHH
IPv6 Header
Destination Address: PB:Site:Host2
Source Address: Host1
Routing Header
Type: 2
Home Address: PA:Site:Host2
Packets from the MHH to the CN will carry the Home Address
Destination Option and a Routing Header to select exit ISP:
Packets from MHH to CN
Bagnulo, et al. Expires August 26, 2003 [Page 16]
Internet-Draft Application of MIPv6 to multi-homing February 2003
IPv6 Header
Destination Address: SEAAB
Source Address: PB:Site:Host2
Routing Header
Type: 1
Address #1: Host1
Destination Option Header
Home Address Option: PA:Site:Host2
The communication can continue using this route while the binding
established at the CN remains valid. MIPv6 specification states that
a binding established with CN using keys created using the return
routability procedure must not exceed MAX_RR_BINDING_LIFE (i.e. 420
seconds). This is a major limitation for this application, since the
binding can not be refreshed until the original route is restored and
outages can last longer than 420 seconds. The possibility of
increasing this value should be explored in order to adapt the
protocol for this application.
Anyway, since the usage of the alternative route imposes additional
overhead because of the Home Address Option and the Type 2 Routing
Header, the original route is to be used as soon as it is restored.
So the original route has to be probed in order to detect when it is
restored. This can be done sending HoTI messages, so that when a HoT
message is received, the original path can be restored.
Besides, it should be noted that no other alternative route can be
used because no valid authorization data is available, since it can
only be obtained through the exchange of HoTI/HoT messages through
the original route. Because of this, using the failure detection
mechanism to probe the alternative route does not seems to be
relevant. Moreover, CoTI/CoT message exchange can be suspended until
the original route is restored.
If a HoT message is finally received, a BU message is sent in order
to restore the original route.
In the application scenario, MHH sends HoTI messages as follows
Bagnulo, et al. Expires August 26, 2003 [Page 17]
Internet-Draft Application of MIPv6 to multi-homing February 2003
HoTI message
IPv6 Header
Destination Address: SEAAA
Source Address: PA:Site:Host2
Routing Header
Type: 1
Address#1: Host1
Mobility Header
Type: HoTI
Home Init Cookie: HCookie'
Until a HoT message is received from CN
HoT message
IPv6 Header
Destination Address: PA:Site:Host2
Source Address: Host1
Mobility Header
Type: HoT
Home Init Cookie: HCookie' (from HoTI message)
Home Nonce Index: HNI'
Home Keygen Token: HKT'
Then the MHH can send a BU message to restore the original route
through ISPA.
Bagnulo, et al. Expires August 26, 2003 [Page 18]
Internet-Draft Application of MIPv6 to multi-homing February 2003
BU message
IPv6 Header
Destination Address: SEAAA
Source Address: PA:Site:Host2
Routing Header
Type: 1
Address #1: Host1
Mobility Header
Type: Binding Update
Acknowledge: reset
Home Registration: reset
Link-Local Compatibility:
Key Management Mobility Capability:
Sequence #: S'
Lifetime: 0 (indicates deleting a binding)
Mobility Options
Binding Authorization Data Option
Authenticator: First (96, HMAC_SHA1(Kbm, Mobility Data))
Being:
Mobility Data = PA:Site:Host2 | Host1 | Mobility Header Data
Kbm = SHA1 (HKT') (from HoT message)
Nonces Index Option
Home Nonce Index: HNI' (from HoT message)
Care-of Nonce Index: 0
After receiving this message, the communication through the original
route will be restored.
Bagnulo, et al. Expires August 26, 2003 [Page 19]
Internet-Draft Application of MIPv6 to multi-homing February 2003
5. Evaluation of the solution
5.1 Limitations
The major limitation detected is that the lifetime of bindings
established with the CN using keys created using the return
routability procedure is limited to 420 seconds by the MIPv6
specification. This implies that the established connection is
preserved for 7 minutes after the outage occurred. Since outages
usually last longer than 7 minutes, this limitation drastically
reduces the benefits provided by the solution. The possibility of
extending the binding lifetime is to be explored if this solution is
to be pursued. However, extending the binding lifetime may pose
security problems, so this possibility has to be studied in great
detail.
Another detected limitation is that once that a path has failed and
another one is being used, it is not possible to switch the
communication to a third path. This is so because no valid
authorization information is available, since the return routability
procedure requires exchange of information using the HoA, which is in
this case unavailable.
Finally, a general limitation of the solutions based on hosts having
multiple address is that it is difficult to implement policing. This
is because hosts perform address selection and doing so they also
select providers.
The two last limitations are mostly relevant for large/medium sites.
So, they reduce the scope of the solution to small sites.
5.2 Benefits
The main benefit of the solution is its compatibility with the
existent technology. For instance, changes needed are limited to
hosts within the multi-homed site. Hosts in the outside of the site
do not need to change almost anything in their implementation in
order to communicate with a multi-homed site and benefit from
multi-homing capabilities. The only change, if accepted, is the
extension of maximum binding lifetime.
Besides, this solution is compatible with PA scheme granting the
scalability of the routing system.
Finally, this solution does not requires that multi-homed sites to
run BGP in contrast with many alternative solutions. This reduces the
complexity of the solution and preserves the AS number space.
Bagnulo, et al. Expires August 26, 2003 [Page 20]
Internet-Draft Application of MIPv6 to multi-homing February 2003
5.3 Possible optimizations
Multiple additional optimizations can be done to enhance the
solution. Some are described next.
MIPv6 specification includes the possibility of piggybacking binding
related messages in data packets as a future extension of the
protocol. This would reduce the overhead imposed by the solution.
Other possible optimization that can be performed is related to the
failure detection mechanism. The proposed mechanism provides minimum
facilities. Improved algorithms can be proposed so that faster
detection is provided. For instance adaptive mechanisms such as the
ones used by TCP can be adopted. This document describes the
constraints imposed by the MIPv6 specification. Any mechanism that
honors these constraints is acceptable. Moreover, multiple mechanisms
can be implemented in different hosts without compromising seamless
interaction.
Bagnulo, et al. Expires August 26, 2003 [Page 21]
Internet-Draft Application of MIPv6 to multi-homing February 2003
6. Security Considerations
The presented solution is based on the usage of the MIPv6 protocol,
benefiting from MIPv6 security features. It should be assured by
MIPv6 security experts that all the underlying assumptions of the
mobility scenario remain valid.
Additionally, the possibility of extending the lifetime of bindings
established with the CN using keys created using the return
routability procedure may introduce security hazards that need to be
carefully considered.
Bagnulo, et al. Expires August 26, 2003 [Page 22]
Internet-Draft Application of MIPv6 to multi-homing February 2003
References
[1] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in
IPv6", Internet Draft, Work in progress, May 2002.
[2] Dupont, F., "Multihomed routing domain issues for IPv6
aggregatable scheme", Internet Draft, Work in progress(Expired),
March 2000.
[3] Huitema, C. and R. Draves, "Host-Centric IPv6 Multihoming",
Internet Draft, Work in progress, June 2002.
Authors' Addresses
Marcelo Bagnulo
Universidad Carlos III de Madrid
Av. Universidad 30
Leganes, Madrid 28911
SPAIN
Phone: 34 91 6249500
EMail: marcelo@it.uc3m.es
URI: http://www.it.uc3m.es/marcelo
Alberto Garcia-Martinez
Universidad Carlos III de Madrid
Av. Universidad 30
Leganes, Madrid 28911
SPAIN
Phone: 34 91 6249500
EMail: alberto@it.uc3m.es
URI: http://www.it.uc3m.es/alberto
Ignacio Soto
Universidad Carlos III de Madrid
Av. Universidad 30
Leganes, Madrid 28911
SPAIN
Phone: 34 91 6249500
EMail: isoto@it.uc3m.es
URI: http://www.it.uc3m.es/isoto
Bagnulo, et al. Expires August 26, 2003 [Page 23]
Internet-Draft Application of MIPv6 to multi-homing February 2003
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property 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; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication 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 implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
Bagnulo, et al. Expires August 26, 2003 [Page 24]
Internet-Draft Application of MIPv6 to multi-homing February 2003
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Bagnulo, et al. Expires August 26, 2003 [Page 25]