Internet Engineering Task Force P. Savola
Internet Draft CSC/FUNET
Expiration Date: October 2003
April 2003
IPv6 Site Multihoming: Now What?
draft-savola-multi6-nowwhat-00.txt
Status of this Memo
This document is an Internet-Draft and is subject to 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.
To view the list Internet-Draft Shadow Directories, see
http://www.ietf.org/shadow.html.
Abstract
ROUTING ARCHITECT'S WARNING: flagrant IPv4 site multihoming practices
cause a significant increase the routing table size, change rates and
instability, the tragedy of the commons by encouraging selfish
routing practices, the exhaustion of the 16-bit AS number space, and
may collapse the Internet interdomain routing architecture.
As there has been a desire to avoid similar problems as seen with
IPv4, the use of similar techniques to achieve site multihoming has
been prevented operationally in IPv6. However, the long effort to
proceed with other IPv6 multihoming mechanisms has produced lots of
heat but little light. This memo tries to list available techniques,
split the organizations to different types to separately examine
their multihoming needs, to look at the immediate and short-term
solutions for these organization types, and to list a few immediate
action items on how to proceed with IPv6 site multihoming.
Savola [Expires October 2003] [Page 1]
Internet Draft draft-savola-multi6-nowwhat-00.txt April 2003
Table of Contents
1. Introduction ............................................... 2
2. Site Multihoming Mechanisms ................................ 3
3. Classification of Sites and Motivations .................... 4
3.1. Classification ......................................... 4
3.1.1. Minimal ............................................ 5
3.1.2. Small .............................................. 5
3.1.3. Large .............................................. 6
3.1.4. International ...................................... 6
4. Choosing a Multihoming Mechanism ........................... 7
4.1. Viable Multihoming Mechanisms .......................... 7
4.1.1. Immediate Approaches ............................... 7
4.1.2. Short-term Approaches .............................. 7
4.1.3. Long Term Approaches ............................... 8
4.1.4. Conclusion on Approaches ........................... 8
4.2. Applicable Mechanisms for Site Types ................... 8
4.2.1. Minimal ............................................ 9
4.2.2. Small .............................................. 9
4.2.3. Large .............................................. 9
4.2.4. International ...................................... 10
5. Issues to Be Addressed ..................................... 10
6. Acknowledgements ........................................... 11
7. Security Considerations .................................... 11
8. References ................................................. 11
8.1. Normative .............................................. 11
8.2. Informative ............................................ 11
Author's Address ............................................... 13
A. Independence as a Multihoming Reason ....................... 13
B. Multi-connecting ........................................... 13
Intellectual Property Statement ................................ 14
Full Copyright Statement ....................................... 15
1. Introduction
Currently in IPv4, there seem to be three-four main mechanisms which
are used to achieve at least some of the multihoming benefits:
obtaining their own address space and AS number and advertising
those, advertising more specific routes with a different path, using
multi-connecting and leveraging NAT.
In IPv6, the first two of IPv4 mechanisms which are considered
architecturally unscalable have been operationally prevented for now
and the fourth does not exist.
Savola [Expires October 2003] [Page 2]
Internet Draft draft-savola-multi6-nowwhat-00.txt April 2003
IPv6 site multihoming effort has been in progress for many years
already, with little light but lots of heat. This memo tries to
increase the light, and show a few possible ways how to proceed with
site multihoming in a relatively qualitative fashion.
First, the multihoming mechanisms which have been proposed and
briefly considered are listed for reference; a more detailed
description and analysis is omitted [SMULTI].
Then, a classification of sites and their multihoming motivations is
presented. This is done to break the "site" and "multihoming"
concepts to smaller, digestible pieces.
After that, the multihoming mechanisms are classified to immediate,
short-term, and long-term approaches; long-term approaches are
ignored when describing which techniques might fit for each
organization type.
Last, some short term issues to be addressed and things to be done,
are listed.
[V4MULTI] describes IPv4 multihoming properties. The motivations
section seems to be missing an important factor, the explicit desire
for operator-independence. This is described in Appendix A.
Similarly, multi-connecting -- which has typically been considered
out of scope -- is briefly described in Appendix B.
2. Site Multihoming Mechanisms
In [SMULTI], quite a few different site multihoming mechanisms have
been briefly described and analyzed:
o Transport solutions, including TCP modifications [TCP+] and SCTP
[SCTP],
o Locator/Identifier separation solutions, including HIP [HIP],
LIN6 [LIN6] and Mobile IPv6 [MIPv6]),
o Host-centric Multihoming [HC],
o Multihoming at Site Exit Routers [SITEEXIT],
o Geographic Address Allocation [GEO],
o Provider Independent Addressing Derived from AS Numbers [ASNPI],
Savola [Expires October 2003] [Page 3]
Internet Draft draft-savola-multi6-nowwhat-00.txt April 2003
o Multi-connecting (see Appendix B for introduction), and
o Other methods, including: Advertising more specific routes
[SPECIFIC], Multihoming with route aggregation [RAGGR], End-to-
end multihoming [END2END], Traffic steering using routing header,
Router renumbering [RR], and MHAP [MHAP].
A degree of familiarity with at least the most important techiques is
assumed. The description and further analysis is out of scope.
3. Classification of Sites and Motivations
The different types of organizations are separated, and their
possible motivations explored separately. In this way, it's possible
to try to break the big "site" and "multihoming" concepts into
smaller pieces.
First, a rough classification is presented, and then each of the four
types are described at more length.
Analysis on which methods could suit each type best are described in
the next section.
3.1. Classification
A table of multihoming motivations and types of sites is created; it
is shown in the table below.
.--------------.------------.--------------.
| Independence | Redundancy | Load sharing |
.--------------+--------------+------------+--------------+
|Minimal | no | no | no |
|Small | maybe | maybe | no |
|Large | maybe/yes | yes | maybe |
|International | yes | yes | yes |
'--------------'--------------'------------'--------------'
Note that the motivations "Performance" and "Policy" [V4MULTI] are
not included above: in practice, they do not seem to be prime
motivators, and it is difficult to gauge how desirable features they
are.
The term "IP-users" is used in the classifications below. This is
used to loosely refer to those people who have an operational need
for Internet access to get their work done.
The organizations are classified roughly in four categories:
Savola [Expires October 2003] [Page 4]
Internet Draft draft-savola-multi6-nowwhat-00.txt April 2003
1. Minimal: a very small or restricted end-site, for example a
typical home network, or a small office of less than 10 IP-
users,
2. Small: a small-to-mid-size enterprise, for example with less
than 50-150 IP-users,
3. Large: a large enterprise, for example a regional or national
enterprise of typically less than 1000 IP-users, and
4. International: a large or very large enterprise, with a
significant amount of international activity.
The distinction between the last two comes from the assumption that
an international organization is assumed to have major activity in
multiple countries or regions: in practice, one with a separate
significant Internet connectivity with different ISPs in many areas.
Naturally, even smaller organizations are likely to have some
relatively minor international activity, but these are not likely
counted as International.
Now, the reasons and motivations specific to each organization class
are described. These give a bit more elaboration on why the
categories were written down as they were.
3.1.1. Minimal
Very minimal end-sites, such as typical home networks or very small
enterprises, are quite small and typically do not include mission-
critical activities.
Naturally, anyone would be willing to achieve multihoming benefits,
but usually the associated costs, e.g. caused by obtaining physical
connectivity to two ISPs, do not justify it.
In the very rare case that some multihoming is required, it can be
done using the "Small" model.
3.1.2. Small
Small end-sites are typically small-to-mid-size enterprises, which
operate mainly in one geographical location; branch offices are also
possible, but these are typically handled using Virtual Private
Networks (VPNs) or similar.
Small end-sites typically use the Internet in such a manner that they
might find redundancy and independence important, depending on the
Savola [Expires October 2003] [Page 5]
Internet Draft draft-savola-multi6-nowwhat-00.txt April 2003
costs and complexity. However, typically an outage of some minutes
or rarely even hours is not yet critical, and due to the size,
operator-independence is not vital.
3.1.3. Large
Large end-sites are typically largish enterprises which operate in
one or typically more geographical locations, however, mostly inside
a region or a country. Relatively minor international branch offices
are possible, but there are no major internal, private interconnects
-- physical or link-layer connectivity that does not go through the
Internet -- to the offices in other countries. Typically, if there
are multiple locations inside a region, there are internal, private
interconnects between the locations.
Redundancy is very important due to increased size: longer outages
are unacceptable for productivity. Also, as the number of the nodes
in the site is quite high, the effort of renumbering is also high,
and some level of operator independence valuable but not always
strictly necessary if significant enough ISPs operate in the area.
Only in some relatively rare cases the network capacities or other
parameters are exceeded so that some form of load-sharing is
required.
3.1.4. International
International end-sites are typically large or very large enterprises
which have significant employment internationally, connect to the
Internet with high-speed links in each of these significant locations
and may often have internal, private interconnects in place.
Typically, ISPs are not global enough to supply connectivity to all
the locations, and being locked to scenic routing paths caused by
only a few regional ISPs is not considered a serious option.
As the international enterprise typically exceeds the geographic and
topological scope of any single ISP, and the network is so large,
operator independence is considered extremely important. Redundancy
is also critical. The required capacities and usage patterns may
vary a lot, but often also some form of load sharing is necessary:
all the traffic to the end-site cannot go through a single location,
and it might not be reasonable either, due to geography.
Savola [Expires October 2003] [Page 6]
Internet Draft draft-savola-multi6-nowwhat-00.txt April 2003
4. Choosing a Multihoming Mechanism
In the previous section organizations were split into four main
classifications; now it's possible to summarize the mechanisms and
see if particular mechanisms could be made to meet the organizations'
needs.
The first thing to realize is that the scope and breadth of
multihoming motivations and requirements vary a lot. It is highly
unlikely that an "one size fits all" solution could be found: indeed,
it seems fruitless to even try to look for one except possibly in
purely research terms. Further, generic solutions are not probable to
be found without larger architectural changes.
Therefore, by applying some rough classification one can hope to
break the problem space into pieces and try to evaluate whether
applicable solutions can be found for those pieces.
4.1. Viable Multihoming Mechanisms
First, it is important to take a look at and analyze different
solutions to see which mechanisms could be viable and how they could
be positioned.
A detailed analysis is omitted from this memo.
These are grouped to three categories: immediate, short-, and long-
term. The definitions of the latter two are intentionally left
vague, but short term solutions should not take more than 1-3 years
to implement and deploy, at most.
4.1.1. Immediate Approaches
Multi-connecting seems to be the only obvious way to work around
multihoming problems right now.
Host-centric multihoming and multihoming at site exit routers would
also be applicable -- to an extent -- immediately, if no ISP would
implement ingress filtering.
4.1.2. Short-term Approaches
Host-centric IPv6 multihoming and multihoming at site-exit routers,
fully fleshed out, are both short-term solutions; both still need
some work.
Provider independent addressing based on AS numbers is a short-term
solution; the same applies to advertising more specific routes, if
Savola [Expires October 2003] [Page 7]
Internet Draft draft-savola-multi6-nowwhat-00.txt April 2003
done from specific allocations to make them distinguishable.
Parts of multihoming with route aggregation, traffic steering using
routing header and router renumbering could be used in the short
term, but the mechanisms themselves are not usable.
4.1.3. Long Term Approaches
All transport solutions are only generally applicable in the long
term, if at all.
Identifier and locator separation solutions are long-term solutions;
HIP the most credible of them all. LIN6 has fundamental issues which
does not make it globally deployable. Mobile IPv6, if the address
ownership and key management issue could be worked around, could be a
short-term solution, a "hack". Architecturally, it seems a bit ill-
fit as a long-term solution.
Geographic address allocation is a long-term solution if it's
considered viable.
End-to-end multihoming is a long-term solution; it requires some
major changes in thinking, and may be difficult to accept.
MHAP is a long-term solution; it moves into an area where most do not
want to go architecturally, and it's likely it could not be made to
work in practice.
4.1.4. Conclusion on Approaches
In the following analysis, none of the long-term approaches are
seriously considered; they all need much more work to be adoptable.
Of the long-term solutions, it seems likely that at least identifier
and locator solutions will prevail in some form or another. However,
they do not solve the whole multihoming problem themselves.
4.2. Applicable Mechanisms for Site Types
Now, the mechanisms outlined in the multihoming analysis and
considered viable, above, are applied to the rough end-site
organization categories above.
Savola [Expires October 2003] [Page 8]
Internet Draft draft-savola-multi6-nowwhat-00.txt April 2003
4.2.1. Minimal
Minimal end-sites do not seem to require a multihoming mechanism. Of
course, some would still find one preferable.
If they would, one building on "host-centric multihoming" approach
would seem sufficient; this might not even be all too expensive using
e.g. multiple xDSL connections.
4.2.2. Small
Small end-sites might find a multihoming mechanism desirable for
redundancy and independence reasons.
The possible approaches are three-fold:
o multi-connecting to one ISP, if redundancy is important,
o host-centric multihoming, if independence is important, or
o multihoming at site exit routers, if both are important.
Multi-connecting or multihoming at site exit routers provide a very
extensive amount of redundancy and convergence; independence is
obtained by connecting to multiple ISPs and deploying IP addresses
from those, which would make the renumbering much less of a problem
if it had to be done.
Solving the multihoming problem of small end-sites with an approach
like "ASN-PI" or more specific routes is unscalable.
4.2.3. Large
Large end-sites typically require redundancy and possibly
independence, sometimes desiring load sharing as well.
Often, the same mechanisms applied to small end-sites will also
provide the sufficient level of redundancy and independence for also
large end-sites.
One might be able to handle the scalability issues associated with
approaches like "ASN-PI" with large end-sites, but such mechanisms
should be avoided.
Savola [Expires October 2003] [Page 9]
Internet Draft draft-savola-multi6-nowwhat-00.txt April 2003
4.2.4. International
International end-sites typically require redundancy, independence,
and load sharing.
As their geographical scope typically exceed ISPs', assigning
addresses from multiple ISPs, as with previous approaches, would lead
to suboptimal routing.
One approach would be to depend on a change of the IP addressing and
routing model: each significant international part of the
organization would obtain separate IP address assignments from the
local ISPs, and use an appropriate multihoming mechanism with that --
probably like with large end-sites above -- and interconnect the
offices using mechanisms like VPN's; not even trying to obtain a
homogeneous address space for all of the company.
This would be a "divide-and-conquer" approach to the problem: break
it to smaller pieces and solve them independently.
If this approach can't be adopted, it seems the only realistic model
would be to use something like "ASN-PI", more specific routes or
separate address allocations, or similar.
5. Issues to Be Addressed
Now, a few relatively short-term action items are presented which
should be done as soon as possible.
o Update and finish documenting IPv4 multihoming practices
[V4MULTI],
o Further than that, try to gain a better understanding why certain
multihoming mechanisms are used with IPv4,
o Finish documenting the IPv6 multihoming goals [GOALS],
o Realize that certain problems like connection survivability may
not be strict requirements in all cases of site multihoming, and
that such problems could be worked around.
o Create a roadmap on how to proceed with multihoming solutions,
o Work on short-term solutions, in particular, fix [SITEEXIT] and
[HC] in the case that ISPs use ingress filtering and consider the
case when uplink MTU is not higher than the one used within the
site when using [SITEEXIT],
Savola [Expires October 2003] [Page 10]
Internet Draft draft-savola-multi6-nowwhat-00.txt April 2003
o Work on procedures to ensure the separation -- who is
"privileged" for which solution -- between different site types
and multihoming methods, if different techniques are necessary,
and
o Start documenting how to do renumbering, and how to make
renumbering easier; the renumbering doesn't have to work
perfectly or even well, as long as it is satisfactory for some
uses.
6. Acknowledgements
Most of the ideas on how to proceed originated in 2002 and in the
beginning of 2003. The ideas on how to proceed were discussed prior
to IETF56 in March 2003 with Tim Chown and Kurt Erik Lindqvist.
7. Security Considerations
This memo summarizes issues in IPv6 site multihoming and gives ideas
on the way forward. Many multihoming techniques have security
considerations which are not to be forgotten; they should be dealt
with in the respective specifications and remembered when analyzing
their applicability. Security is also an integral issue to consider
when considering the overall site multihoming landscape. However, in
itself, this memo does not present any security considerations.
8. References
8.1. Normative
[V4MULTI] Abley, J., Black, B., and Gill, V., "IPv4 Multihoming
Motivation, Practices and Limitations",
draft-ietf-multi6-v4-multihoming-00, expired, Jun 2001.
[GOALS] Abley, J., Black, B., and Gill, V., "Goals for IPv6
Site-Multihoming Architectures", draft-ietf-multi6-
multihoming-requirements-05.txt, work-in-progress,
Apr 2003.
8.2. Informative
[SMULTI] Savola, P., "Examining Site Multihoming in Finnish
Networks", MSc Thesis, http://staff.csc.fi/psavola/di.ps,
Apr 2003.
[TCP+] Tattam, P., "Preserving Active TCP sessions on Multihomed
IPv6 Networks", http://jazz-1.trumpet.com.au/ipv6-draft/
preserve-tcp.txt, Aug 2001.
Savola [Expires October 2003] [Page 11]
Internet Draft draft-savola-multi6-nowwhat-00.txt April 2003
[SCTP] Coene, L. (ed.), "Multihoming issues in the Stream
Control Transmission Protocol", draft-coene-sctp-
multihome-03.txt, work-in-progress, Feb 2002.
[HIP] Moskowitz, R., "The Host Identity Payload Homepage",
http://homebase.htt-consult.com/HIP.html.
[LIN6] Tereoka, F., et al., "LIN6: A Solution to Mobility and
Multi-Homing in IPv6", draft-teraoka-ipng-lin6-01.txt,
expired, Aug 2001.
[MIPV6] Johnson, D., et al., "Mobility Support in IPv6",
work-in-progress, Feb 2003.
[HC] Huitema, C., Draves, R., "Host-Centric IPv6 Multihoming",
draft-huitema-multi6-hosts-01.txt, expired, Jun 2002.
[SITEEXIT] Hagino, J., Snyder, H., "IPv6 Multihoming Support at
Site Exit Routers", RFC3178, Oct 2001.
[GEO] Hain, T., "Application and Use of the IPv6 Provider
Independent Global Unicast Address Format", draft-hain-
ipv6-pi-addr-use-04.txt, work-in-progress, Apr 2003.
[ASNPI] Savola, P., "Multihoming Using IPv6 Addressing Derived
from AS Numbers", draft-savola-multi6-asn-pi-00.txt,
work-in-progress, Jan 2003.
[SPECIFIC] Lindqvist, K., "Multihoming in IPv6 by Multiple
Announcements of Longer Prefixes",
draft-kurtis-multihoming-longprefix-00.txt,
work-in-progress, Dec 2002.
[RAGGR] Yu, J., "IPv6 Multihoming with Route Aggregation",
draft-ietf-ipngwg-ipv6multihome-with-aggr-01.txt,
expired, Aug 2000.
[END2END] Ohta, M., "The Architecture of End to End
Multihoming", draft-ohta-e2e-multihoming-03.txt,
work-in-progress, Nov 2002.
[RR] Crawford, M., "Router Renumbering for IPv6", RFC2894,
Aug 2000.
[MHAP] Py, M., "Multi Homing Aliasing Protocol",
draft-py-mhap-01a.txt, expired, Apr 2002.
Savola [Expires October 2003] [Page 12]
Internet Draft draft-savola-multi6-nowwhat-00.txt April 2003
Author's Address
Pekka Savola
CSC/FUNET
Espoo, Finland
EMail: psavola@funet.fi
A. Independence as a Multihoming Reason
This is an excerpt from [SMULTI].
Technical reasons for independence are mostly covered under
redundancy; independence here focuses on economic, political and
administrative perspectives.
Multihoming, especially with your own addresses can bring the
organization some degree of provider independence. If the
organization can just change its ISP's with minimal effort, one
undoubtedly has a better standing in the service agreement
negotiations, e.g. being able to get a cheaper price and requested
service agreement duration. ISP's could also just disappear, but in
most cases services usually continue uninterrupted in the event of
bankruptcy, mergers, etc. Also, especially some larger organizations
consider it important to stand on their own, so that they can't be
seen to depend on others.
An important factor for many, especially bigger sites, is also that
the renumbering in the event of a network service provider change is
considered too difficult and time-consuming, and it is desirable to
find mechanisms which do not require that; such feature is provided
by independence.
B. Multi-connecting
This is an excerpt from [SMULTI].
Multi-connecting means connecting multiple times to a single ISP. By
some definition [V4MULTI], multi-connecting is not considered a
multihoming mechanism. However, it still deserves a brief
description.
Multi-connecting is typically achieved by having multiple site border
routers and connecting each of them to separate routers at the ISP,
usually in different locations.
Often, a routing protocol is run between the site and the ISP, to be
able to quickly detect errors in the connectivity and to switch to
alternative paths. Routing protocol used is often BGP with private
Savola [Expires October 2003] [Page 13]
Internet Draft draft-savola-multi6-nowwhat-00.txt April 2003
AS numbers.
Sometimes, typically when the ISP is also in charge of the management
of site border routers, some other protocols such as OSPF or IS-IS
are also possible -- this often requires strict filtering of
advertisements at the ISP end, to prevent compromising the ISP's core
routing system. In some cases, simply static routes may also be
possible; typically this requires a link-layer medium which provides
notifications if the end-to-end link-layer path becomes
nonoperational.
Multi-connection is a flexible mechanism and relatively easy to
accomplish: it requires no coordination between ISPs, no address
applications for provider independent address space, no AS number
applications for BGP AS numbers or the like. Yet it provides
protection from the most common set of problems.
If one link fails, the changes do not need to be propagated further
than the ISP; therefore, this is a very scalable approach when
considering the global routing table.
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.
Savola [Expires October 2003] [Page 14]
Internet Draft draft-savola-multi6-nowwhat-00.txt April 2003
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
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.
Savola [Expires October 2003] [Page 15]