One document matched: draft-ohira-assign-select-e2e-multihome-01.txt
Differences from draft-ohira-assign-select-e2e-multihome-00.txt
Internet Engeneering Task Force K. Ohira
INTERNET-DRAFT K. Ogata
June 30, 2003 A. Matsumoto
K. Fujikawa
Y. Okabe
Kyoto University
IPv6 Address Assingment and Route Selection
for End-to-End Multihoming
<draft-ohira-assign-select-e2e-multihome-01.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/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Abstract
We assume that IPv6 network is hierarchical. Though the present IP
network topology is not hierarchical at the point of multihoming.
In this document, we clarify that
a) how to assign address blocks to ISPs and sites in order to
achieve multihome environment without destroying hierarchical
structure of IPv6,
b) requirements for end hosts in order to select an adequete route
from multiple routes when multihoming.
with the way which is based on so-called 'end to end multihoming' or
'host centric multihome'.
Ohira Expires on December 30, 2003 [Page 1]
draft-ohira-assign-select-e2e-multihome-01.txt June 30, 2003
1. Introduction
Multihome is the way to make load balancing or to improve
reachability. Today, the Internet becomes popular and then someone
will want to get multihomed environment even if whose network is
small as a home network. Still more, there are a lot of requirements
for multihoming pointed out in [REQ].
It is difficult to respond to such request with present way of
multihome. Further more, IPv6 address space is far wider than that
of IPv4, so we have to aggregate addresses thoroughly or IPv6 fails
earlier than IPv4.
In this document, we explain the network topology model which we
should follow and addressing policy the in that network.
2. Network topology and Hierarchical Address assignment
In a current multihoming envirionment, a site needs an AS number or
needs a so-called "punching hole" method in order to select a route
from candidate routes. This causes explosion of routing information.
We show that a site can select a preferable route even when IP
addresses are hierarcically assinged. Hierarchical IP address
assignment suppresses the explosion of routing information.
We will construct our multihoming model based on the "end to end
multihoming" ([E2E]). Note that end to end multihoming and host
centric multihoming is the same in terms of address assignment.
As described in [M6H], source address based routing allows for a
large diversity between the site exits. It also allows for host
based policy decision, since a host can influend the routing of a
packet by choosing the appropriate source address.
So, we use source address based routing for this purpose.
In [M6H], an example of two level hierarchical structure that a site
obtain prefixes from the ISPs whom the site subscribes to is shown.
This time, we should assign hierarchical addreses to those networks
in order to aggregate addresses and in order to express that what
ISP a certain site belongs to.
~~~~~~~
( ) BGP cloud
~~~~~~~
: : :
......: : :......
: : :
Ohira Expires on December 30, 2003 [Page 2]
draft-ohira-assign-select-e2e-multihome-01.txt June 30, 2003
+---+ +---+ +---+
| A | | B | | C | ISPs
+---+ +---+ +---+
/ \ / \ /
/ \ / \ /
/ \ / \ /
+---+ +---+ +---+
| a | | b | | c | Sites
+---+ +---+ +---+
[fig. 1 Considered network connection topology]
When the connection is as shown as fig. 1, site b gets address
prefixes from ISP A and B.
When a host in the site b claims that its address is A:b:HostID,
that host is regarded as belonging to the ISP A (as shown in
fig. 2(a)).
When a host in the site b claims that its address is B:b:HostID,
that host is regarded as belonging to the ISP B (as shown in
fig. 2(b)).
+---+ +---+
A:: | A | B:: | B |
+---+ +---+
/ \ / \
/ \ / \
/ \ / \
+---+ +---+ +---+ +---+
| a | | b | | b | | c |
+---+ +---+ +---+ +---+
A:a:: A:b:: B:b:: B:c::
[fig. 2(a)] [fig. 2(b)]
[fig. 2 [M6H] model network topology on IP layer]
Every host in the site b has addresses, one is assigned by ISP A
and the other is assigned by ISP B. Each host can take a stand on
that it belongs to domain of ISP A or that of B per packet.
Here, in this two level hierarchical structure model, addresses are
throughly aggregated. In other words, which ISPs each site
subscribes to has nothing to do with the exchange routing
information among the ISPs.
Now, we show this two level hierarchical relation is expandable to
three or more level hierarchical relation as shown in [ISP].
Here, the author of [ISP] thinks that all end nodes are able to have
Ohira Expires on December 30, 2003 [Page 3]
draft-ohira-assign-select-e2e-multihome-01.txt June 30, 2003
full route, but we think that some very simple appliances probably
never will have any information and that end nodes are able to
select routes in the upper layer because the end node does not have
full route.
We assume that the sites a, b, and c subscribe to the local ISPs A,
B and C and that the local ISPs A, B and C subscribe to the top
level ISPs as shown in fig. 3. In fig. 3, the site b has only
default route to A and B.
~~~~~~~
( ) BGP cloud
~~~~~~~
: : :
......: : :......
: : :
+---+ +---+ +---+
| X | | Y | | Z | Top Level ISPs
+---+ +---+ +---+
\ / \ / \
\ / \ / \
\ / \ / \
+---+ +---+ +---+
| A | | B | | C | Local ISPs
+---+ +---+ +---+
/ \\ // \ /
/ \\ // \ /
/ \\/ \ /
+---+ +---+ +---+
| a | | b | | c | Sites
+---+ +---+ +---+
[fig. 3 Proposed network topology on IP layer]
At this time, the top level ISP have to have the routes to the other
top level ISPs and do not have to have the other routes.
The hosts and routers in each site have to have the routes inside of
the site and default route to the site exit routers which have the
connectivity to the outside of the site. Only the site exit routes
have to have the full routes among the top level ISPs and routes in
the routes inside of the top level ISPs which the site belongs to.
Notes: It is difficult issue that what route should each local ISPs
have.
It is an idea that all routers in each local ISP have full
routes. If we use this solution, we have to estimate the size
of the routing table of full routes.
Ohira Expires on December 30, 2003 [Page 4]
draft-ohira-assign-select-e2e-multihome-01.txt June 30, 2003
By using this way, routers can reduce the routes which the routers
should have.
In fig. 3, the site b has four prefixes: X:A:b::, Y:A:b::,
Y:B:b:: and Z:B:b::.
3. Route Selection
If a host has full routing information, it can select an adequete
route by means of the ordinal destination based routing. However,
especially in a site, it can select an adequete route without full
routing information by means of source address based routing.
In such case, those nodes have a routing information that the
default routes are the ISPs whom the end site subscribes for.
In order to achieve the benefit of multihoming in such site, we
propose:
If a host have default routes, it maintain as many parallel
routing tables as there are valid source prefixes for the default
routes. Using these tables, the host can select proper route from
many routes. At this time, the host refer to not only destination
address but also source address.
Here, we do not use the tunneling method as shown in the
'host-centric' multihoming but use the source address based routing.
With our method, we have the disadvantage that hosts and routes in
each sites must be able to handle source address based routing, but
we get the advantage that we can select the prefer route and that we
do not have to warry about the single point of failure at the site
exit routers.
The biggest advantage to use end to end multihoming is that end
system can select a path or paths from various paths. In the scheme
of host centric multihoming, we can not select different path to the
same destination for different applications on the same host.
Our proposal requires the source address based routing for only
default routes. this causes little impact on hosts and routers.
Similarly, the impact on the present routing protocol.
In fig. 1, the site b is multihoming to the ISP A and B, then
a packet from a host named s in the site b has A:b:s or B:b:s as
its source address. Similarly, a packet to a host named t in the
site c has B:c:t or C:c:t as its destination address.
If the host select the route with the longest match between the
source address and destination address, the expected packet flow is
as shown in fig. 4.
~~~~~~~ ~~~~~~~
Ohira Expires on December 30, 2003 [Page 5]
draft-ohira-assign-select-e2e-multihome-01.txt June 30, 2003
( ) ( )
~~~~~~~ ~~~~~~~
#######: :#: : : :
#......: :#:...... ......: : :......
#: :# : : : :
+---+ +---+ +---+ +---+ +---+ +---+
| A | | B | | C | | A | | B | | C |
+---+ +---+ +---+ +---+ +---+ +---+
/ \# / \# / / \ #/ \# /
/ \# / \# / / \ #/ \# /
/ \#/ \#/ / \#/ \#/
+---+ +---+ +---+ +---+ +---+ +---+
| a | | b | | c | | a | | b | | c |
+---+ +---+ +---+ +---+ +---+ +---+
src. addr. = A:b:s src. addr. = B:b:s
dest. addr. = B:c:t dest. addr. = B:c:t
[fig. 4(a)] [fig. 4(b)]
~~~~~~~ ~~~~~~~
( ) ( )
~~~~~~~ ~~~~~~~
#######: : :####### : :#:#######
#......: : :......# ......: :#:......#
#: : :# : :# :#
+---+ +---+ +---+ +---+ +---+ +---+
| A | | B | | C | | A | | B | | C |
+---+ +---+ +---+ +---+ +---+ +---+
/ \# / \ #/ / \ #/ \ #/
/ \# / \ #/ / \ #/ \ #/
/ \#/ \#/ / \#/ \#/
+---+ +---+ +---+ +---+ +---+ +---+
| a | | b | | c | | a | | b | | c |
+---+ +---+ +---+ +---+ +---+ +---+
src. addr. = A:b:s src. addr. = B:b:s
dest. addr. = C:c:t dest. addr. = C:c:t
[fig. 4(c)] [fig. 4(d)]
[fig. 4 expected path of packets]
4. Issues in upper layer
When a site is in the proposed multihoming environment, in other
words, when the site subscribes for multiple upstream ISPs and hold
Ohira Expires on December 30, 2003 [Page 6]
draft-ohira-assign-select-e2e-multihome-01.txt June 30, 2003
different prefixes, how to achieve the benefit of multihoming easily?
In order to make it, we have to solve the following issues at least:
a) How to know which addresses does the host to which I will connect
have?
b) How to know which pair of source address and destination address
is the most suitable in some sense?
-- The host can select route with DNS based address, negotiation
in upper layer and so on. Anyway, the selection method is out
of scope of this document.
c) How to keep a connection even if the address of connection member
changes (transport layer survivability) ?
-- By using [L6A], each node is identified by lower 64 bits of IP
address. While this identifier is same, the connections
continue even if the addresses of both ends are changed.
-- If protocols in upper layer (SCTP and so on) can deal with, we
can get the multihoming environment without host ID (LIN6 and
so on).
5. Conclusions
The proposed way of multihome does not destroy the hierarchical
structure of address space nor increase routing information
explosively because the addresses which are assigned to multihome
site are always subsets of address space of upstream ISPs.
All routers in a network do not have to concern about the route of
outside the network.
This way of multihome can deal with ingress filtering (indicated in
[M6H]) because the source address is always included in the address
range of the upstream ISP.
6. Impacts
All routers and hosts in the domain in which this proposal is in
operation need to be able to deal with source address based routing
but the cost to enable this option is not too high because we allow
source address based routing for only default route.
7. Security Considerations
The authors believe this document does not have any direct impact on
security of Internet infrastructure.
Ohira Expires on December 30, 2003 [Page 7]
draft-ohira-assign-select-e2e-multihome-01.txt June 30, 2003
8. References
[E2E] M. Ohta, "The Architecture of End to End Multihoming." Work in
progress.
[M6H] C. Huitema, et. al., "Host-Centric IPv6 Multihoming." Work in
progress.
[REQ] J. Abley, et. al., "Goals for IPv6 Site-Multihoming
Architectures." Work in progress.
[L6A] A. Matsumoto, et. al., "Basic Socket API Extensions for LIN6
End-to-End Multihoming." Work in progress.
[ISP] M. Ohta, "Multihomed ISPs and Policy Control." Work in
progress.
9. Acknowledgement
The authors would like to thank everyone involved.
10. Authors' Addresses
Kenji Ohira
Graduate School of Informatics
Kyoto University
Yoshida-Honmachi, Sakyo-ku, Kyoto 606-8501 JAPAN
Tel: +81 75-753-7468
Fax: +81 75-753-7472
Email: ohira@net.ist.i.kyoto-u.ac.jp
Katsuya Ogata
Graduate School of Informatics
Kyoto University
Yoshida-Honmachi, Sakyo-ku, Kyoto 606-8501 JAPAN
Tel: +81 75-753-7468
Fax: +81 75-753-7472
Email: ogata@net.ist.i.kyoto-u.ac.jp
Arifumi Matsumoto
Graduate School of Informatics
Kyoto University
Yoshida-Honmachi, Sakyo-ku, Kyoto 606-8501 JAPAN
Tel: +81 75-753-7468
Fax: +81 75-753-7472
Email: arifumi@net.ist.i.kyoto-u.ac.jp
Ohira Expires on December 30, 2003 [Page 8]
draft-ohira-assign-select-e2e-multihome-01.txt June 30, 2003
Kenji Fujikawa
Graduate School of Informatics
Kyoto University
Yoshida-Honmachi, Sakyo-ku, Kyoto 606-8501 JAPAN
Tel: +81 75-753-5387
Fax: +81 75-753-4961
Email: fujikawa@real-internet.org
Yasuo Okabe
Academic Center for Computing and Media Studies
Kyoto University
Yoshida-Honmachi, Sakyo-ku, Kyoto 606-8501 JAPAN
Tel: +81 75-753-7458
Fax: +81 75-751-0482
Email: okabe@i.kyoto-u.ac.jp
Ohira Expires on December 30, 2003 [Page 9]
| PAFTECH AB 2003-2026 | 2026-04-22 03:36:59 |