One document matched: draft-kurtis-multi6-roadmap-00.txt
Levels", RFC 2119, March 1997.
IPv6 Multihoming Workingroup K. Lindqvist
Internet-Draft Netnod
Expires: August 24, 2003 February 23, 2003
A road-map for multihoming in IPv6
draft-kurtis-multi6-roadmap-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 24, 2003.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract
IPv6 was decided as the replacement to the widely deployed IPv4 in
1992. The new protocol was designed to meet a number of criteria
that at that time was seen as the failures of IPv4, such as security
and limited address space.
IPv6 meet these needs, but it fails to meet other needs of the
Internet of today such as scalable solutions for multihoming and
portable address space for end-sites. The effects of the lack of
scalable solutions to this is widely documented.
In order to solve the multihoming scalability problems, the multi6
working group was created in the IETF. This group have so far not
Lindqvist Expires August 24, 2003 [Page 1]
Internet-Draft Multihoming road-map for IPv6 February 2003
yet produced any documents as it has been hard to find consensus on
even the most basic documents such as requirements. Multi6 have also
suffered from problems reaching consensus on what type of solution
will be required moving forward, and the attempt of trying to come up
with a 'fit-all' solution from day one.
This document tries to outline steps that could be taken to better
understand the problem and what steps could be taken as we bit by bit
tries to address the problem.
Lindqvist Expires August 24, 2003 [Page 2]
Internet-Draft Multihoming road-map for IPv6 February 2003
1. Introduction
When one starts to look at the multihoming problem, one will find
that there are number of other issues that will start to have an
impact of the problem and of potential solutions.
These factors are for example portability of address space, route
convergence times, size of routing tables, growth of processing
power, utilization of address space etc. All these issues are linked
and will have an impact on what solutions can be used.
If the Internet is to scale far further than to where we are today,
and preserve the end-to-end principle, it is essential that the model
of the Internet at some stage addresses all these issues. So far
many of the attempts at solving the multihoming problem have tried to
address all of these at once, or have effectively stopped solutions
to other problems.
The idea behind this document, is to try and list the pieces and how
they are linked, at the same time as try to map potential solutions
models to each of the problems. Going forward, solutions can then be
benchmarked and ordered. It is important to realize that the most
effective way to move forward at the moment seem to be to agree on a
solution at a time and bit by bit get us to the complete solution to
the multihoming problem and the problems that are linked to it.
Lindqvist Expires August 24, 2003 [Page 3]
Internet-Draft Multihoming road-map for IPv6 February 2003
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [1].
"Site", "Transit provider" and "multihomed", are defined in draft-
ietf-multi6-multihoming-requirements-03 [2].
"Host multihoming" denotes a single host that have routing
information, and/or addresses from two or more transit providers.
Lindqvist Expires August 24, 2003 [Page 4]
Internet-Draft Multihoming road-map for IPv6 February 2003
3. Determining the nature, type and scale of the problem
3.1 Definition of the multihoming problem
Today many sites have the requirement of connections to multiple
providers. This can be for a number of reasons such as business
critical applications that require redundancy; Cost benefits of being
able to route different types of traffic to different providers; etc.
This in most cases creates an entry in the routing table per each
upstream provider. This creates a growth of the global routing table
that we with todays routing protocols can not handle. The size
becomes to large to keep in routers memory and the convergence time
in the case of a failure becomes to high.
A related problem leading to the same effects is the fact that many
enterprise users want stable IP addresses that do not change when
they change providers. Currently these addresses are routed as
independent blocks and therefor also contributing to the growth of
the global routing table.
3.2 IPv6 and multihoming
When the need for a new IP protocol was being discussed in the first
half of the 1990s, a number of problems that needed solutions was
listed in order to have them solved at the same time. The Internet
back then was much more hierarchial than the Internet of today. The
first plans of an address architecture reflects this with the
assignments being split up into different aggregator levels.
Since then multihoming have become widespread use among the
enterprises and the needs of addresses have changed dramatically.
This is also the explanation as to why multihoming never made it as a
requirement for IPv6.
Years later when multihoming was starting to become popular and the
growth of the global routing table was starting to become visible as
a problem, a number of suggestions on how to address it was made.
What these would look like have varied over time. Some of them have
suggested to make changes to the IPv6 address model itself, while
deployment is relatively limited, some have suggested changing the
way IPv6 addresses are allocated, some have suggested other methods.
Common though is the understanding that the migration to IPv6 gives
us the opportunity to change other characteristics of the IP
protocols.
Although IPv6 in itself does not give an answer to the multihoming
problem, the solution will undoubtely be closely linked with future
Lindqvist Expires August 24, 2003 [Page 5]
Internet-Draft Multihoming road-map for IPv6 February 2003
IPv6 deployment.
3.3 Scaling to a solution
There exists a number of proposals to a solution to the multihoming
problem. All or at least most of them will mostly work, but the
large question is if they will scale better than what we have today,
and to an increase in complexity that we can handle.
In order to judge this, we need to come to a common model of what
scaling properties the problem will have over a certain time.
3.3.1 Time
Determining the time and lifetime of the solution should not be that
hard. If we use previous experiences from changing the routing model
of the Internet we can look at the migration to BGP. If we leave out
the transition time as the Internet is much larger today, the
solution have lasted for roughly fifteen years.
If we assume a somewhat similar speed of growth of the Internet a
solution need to last for around fifteen years. To add to this we
need the time it takes from a agreed and published solution to make
general deployment. A common understanding of this time seems to be
around five years.
This means that a multihoming solution needs to scale to the growth
over fifteen years.
3.3.2 Scale
The hardest thing to determine in building a new multihoming model is
to what number it needs to scale.
Currently multihoming growth is limited by the number of Autonomous
System numbers that are available. Currently there are around 60,000
that are allocated by IANA to be handed out. Of these only 20,000
have been allocated and only around 12,000 are actually visible in
the global routing table. This indicates that the current need for
multihoming is somewhat limited. This is not to say that it will for
the future.
The current amount of AS numbers available are limited by the 32-bit
field of AS-number in the BGP specification. However, there is a
proposal in the IDR working group of the IETF to increase this field
to 64-bits. This would increase the amount of ASes available, and
therefor the potential amount of routes in the global routing table.
Lindqvist Expires August 24, 2003 [Page 6]
Internet-Draft Multihoming road-map for IPv6 February 2003
However, it is worth noting that the increase in multihmomed
networks, will most likely increase, partly because of the change in
nature of business done on the Internet, partly because of new
billing models, partly because an available multihoming solution will
attract more people to the solution.
One effect that will play a role in the scaling of the multihoming
solution will be what type of networks that will be multihoming.
There is a difference in requirements if these are multinational
enterprise networks with multiple exit points around the world, or if
these are multihomed home networks behind DSL lines, or multihomed
mobile clients.
With the current development of the Internet it is most likely that
we will see all of the above on a large scale. What will limit this
will mostly be economical factors, i.e. who are willing to pay for
these types of services. Still, the number of multihomed sites will
be very large in twenty years. It is most likely safe to make
calculations based on the fact that most western Europe, the middle
east, Asia and the Americas will have these needs. This includes
most of the worlds population. With the enterprise market this adds
up to several billion of entries.
What is worth keeping in mind though is that this will not happen
immediately. Rather it will grow slow at the start limited by the
above mentioned shortage of AS numbers and the cost of multiple
providers. This is important as a slow start will give us time and
valuable data on the adaption and usage of multihoming as a function
of the network. This is needed to make sure that the solution we
choose actually will last for the required twenty years to come. We
will also need to use the data to build growth curves, so that we can
be sure we at each stage have a workable solution.
No one knows the exact growth, and we have no data to build on, but
if we go on the known parts, that we 2003 still have 16-bit AS
numbers; it will take us at least 2-3 years from agreement on 32-bit
AS numbers to deployment and the same time for any modifications to
the routing model; it will give us tree data points
2003-2006: less than 60k routes
2006: more than 4.2M routes
2020: ~5B routes
This is a far from perfect model, but at least gives us some
indication on possible scenarios.
Lindqvist Expires August 24, 2003 [Page 7]
Internet-Draft Multihoming road-map for IPv6 February 2003
4. The nature of solutions
There are a number of already proposed solutions that can be
categorized in five groups, host, addressing, routing, protocol
modifications, and combinations. Below is a short overview of them
and their possible applications. This document does not make any
claim on judging the suitability of any of the solutions, for doing
that we would need more data on the actual scaling problem we are
trying to solve.
The solutions are grouped in a "implementable time line" of "short"
(less than a year from standard publication), "medium" (between one
and three years from standard publication), "long" (more than three
years from standard publication).
4.1 Hosts
One way of achieving multihoming that exists already today is to use
multiple addresses on the end hosts. The advantage from a
multihoming view is that the addresses are announced as part of the
aggregate routes of the upstream providers.
This solution to some extend also give stability for a service over a
switch of addresses, however it does not decrease the workload of a
network administrator.
In variations this will also require that certain higher level
applications will know which address it should talk to.
This solution could be targeted to the home end-user suppliers or
other large scale deployments done through automatic addressing.
The advantage is that this is a solution that could be deployed in
the short to medium term with no or little modification to other
structures.
4.2 Addressing
Some of the solutions suggest changing the methods used to allocate
IP addresses, and then based on this build either routing models or
modifications to the IP layer to handle the aggregation of routing
information.
These models build on allocating addresses after well known facts
such as geographic coordinates, population or other geo data.
Common to these solutions is that they need other supporting
mechanisms in order to work.
Lindqvist Expires August 24, 2003 [Page 8]
Internet-Draft Multihoming road-map for IPv6 February 2003
These are all medium term solutions as they require a change in the
allocation policy, coordination between all the Regional Internet
Registries, and work on behalf of the end-user network
administrators.
4.3 Routing
At the heart of the multihoming problem is the fact that the current
routing model does not scale in terms of size and convergence times.
The natural solution would be to address the routing model and try
and come up with a new routing protocol, or more effective path
finding algorithms. The problem is the scale.
A solution will have to involve a new routing model, but the scale
and the today known algorithms for finding paths means that we need
to exclude information for the algorithm to converge.
A routing solution also means that we need to modify the installed
base, which - besides time take to agree on and publish a standard -
will take years due to the number of sites and nodes involved.
A modification to the routing model alone will most likely not work
in the long run and it is therefor safe to assume that a solution
will have to be done in combination with another method.
Given the above a routing solution will fit in the long term solution
group.
4.4 The protocol
One way to move forward would be to simply modify the IP protocol
itself. Most of these proposals build on the notion that an address
actually consists of a "locator" and "identifier" part, therefor we
could also split an address into two parts.
These solutions require a modification to not only the IP layer, but
also to the way layers above use the addresses.
This is a highly intrusive modification, that besides the work needed
on protocol changes and new standards, also will take a long time to
implement. These solutions therefor are in the long term category.
4.5 Combinations
Many of the proposals made are combinations of the methods above.
This is simply because many of the solutions will not work on their
own alone. Especially routing solutions will need help by other
solutions to abstract data to an amount that can be handled.
Lindqvist Expires August 24, 2003 [Page 9]
Internet-Draft Multihoming road-map for IPv6 February 2003
Where the place these solutions in implementation time is hard, as
this will depend on which solutions that have been combined. These
solutions are however the most likely way forward as they will
provide various migration steps as well.
4.6 Others
The last category is solutions that do not fit above. These are
solutions that build on continuing the current model, simply to make
IPv6 more attractive for the enterprise. They do not have any medium
or long term validity, but instead function as a starting point that
will help give data and attract enterprises and end-users to use IPv6
for multihoming.
These solutions more based on doing multihoming exactly as done today
and/or modify the way allocations of either IP addresses or AS
numbers are made.
These solutions are all in the short term implementation category as
they do not modify anything else except policy.
Lindqvist Expires August 24, 2003 [Page 10]
Internet-Draft Multihoming road-map for IPv6 February 2003
5. The road ahead
All attempts at solving the multihoming problem so far have tried to
address the end solution, or at least large parts of it. In order to
move forward we need to accept that the road to the end solution will
consist of getting there bit by bit. We need to accept that
solutions we adopt in order to move forward will not be perfect, but
rather far from it. This should be ok as long as it help us to a
better understanding of the problem and to gain momentum.
In order to achieve the goals above, we will need to agree on a
certain set of requirements that meets at least a minimum set of
issues. These requirements can and should be updated as we move
along the way. Trying to identify all problems from the beginning
risk that we miss out on parts we don't know yet and will also make
it harder to get consensus for. If we instead go by this bit by bit,
by defining a small part of the problem and the agreeing on the
solution, we will both learn more and move faster.
All the solutions grouped earlier have merits for one part of the
problem. A end solution might consist of them all, each tailored to
meet a specific goal or part of the problem, with the legacy parts
still in use in parts of the address space. Migration between the
various solutions and steps will be slow, but should not be an issue
as long as we at the end of the time period are at a common base.
The next steps should include ordering the proposed solutions to each
category, agreeing on the implementation horizon, and most important
of all, start doing multihoming with IPv6 in order to gain experience
and get data to build on.
Lindqvist Expires August 24, 2003 [Page 11]
Internet-Draft Multihoming road-map for IPv6 February 2003
6. Security considerations
This document only provides an overview of various solutions and
proposes a benchmarking method for ordering solutions to the
multihoming problem, therefor no security issues should arise from
this document.
Lindqvist Expires August 24, 2003 [Page 12]
Internet-Draft Multihoming road-map for IPv6 February 2003
Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
| PAFTECH AB 2003-2026 | 2026-04-22 04:11:05 |