One document matched: draft-ohira-assign-select-e2e-multihome-00.txt
Internet Engeneering Task Force K. Ohira
INTERNET-DRAFT K. Ogata
June 22, 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-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/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Abstract
IPv6 suppose that 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 in order for end hosts to select an adequete route
from multiple routes when multihoming.
1. Introduction
Ohira Expires on December 22, 2003 [Page 1]
draft-ohira-assign-select-e2e-multihome-00.txt 23 June 2003
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
little as a home network.
It is difficult for present way of multihome to respond such request.
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 Address assignment
We assume that the Internet is composed of world-wide ISPs, local
ISPs and sites, and then they are connected as fig. 1.
+---+ +---+ +---+
| X | | Y | | Z | Top Level ISPs
+---+ +---+ +---+
\ / \ / \
\ / \ / \
\ / \ / \
+---+ +---+ +---+
| A | | B | | C | Local 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)).
+---+ +---+ +---+ +---+
| X | | Y | | Y | | Z |
+---+ +---+ +---+ +---+
Ohira Expires on December 22, 2003 [Page 2]
draft-ohira-assign-select-e2e-multihome-00.txt 23 June 2003
\ / \ /
\ / \ /
\ / \ /
+---+ +---+
| A | | B |
+---+ +---+
/ \ / \
/ \ / \
/ \ / \
+---+ +---+ +---+ +---+
| a | | b | | b | | c |
+---+ +---+ +---+ +---+
[fig. 2(a)] [fig. 2(b)]
[fig. 2 Proposed 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.
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.
At each case, the expected packet flow is as shown in fig. 3.
......... .........
: : Virtual Aggregator : :
......... .........
: : : : : :
......: : :...... ......: : :......
: : : : : :
+---+ +---+ +---+ +---+ +---+ +---+
| X | | Y | | Z | | X | | Y | | Z |
+---+ +---+ +---+ +---+ +---+ +---+
\ #/ \# / \ \ / \ / \
\ #/ \# / \ \ / \ / \
\#/ \#/ \ \ / \ / \
+---+ +---+ +---+ +---+ +---+ +---+
| A | | B | | C | | A | | B | | C |
+---+ +---+ +---+ +---+ +---+ +---+
/ \# / \# / / \ #/ \# /
/ \# / \# / / \ #/ \# /
/ \#/ \#/ / \#/ \#/
+---+ +---+ +---+ +---+ +---+ +---+
| a | | b | | c | | a | | b | | c |
+---+ +---+ +---+ +---+ +---+ +---+
Ohira Expires on December 22, 2003 [Page 3]
draft-ohira-assign-select-e2e-multihome-00.txt 23 June 2003
src. addr. = ::A:b:s src. addr. = ::B:b:s
dest. addr. = ::B:c:t dest. addr. = ::B:c:t
[fig. 3(a)] [fig. 3(b)]
......... .........
: : Virtual Aggregator : :
......... .........
: :#:####### : : :
......: :#:......# ......: : :......
: :# :# : : :
+---+ +---+ +---+ +---+ +---+ +---+
| X | | Y | | Z | | X | | Y | | Z |
+---+ +---+ +---+ +---+ +---+ +---+
\ #/ \ /#\ \ / \ #/#\
\ #/ \ / #\ \ / \ #/ #\
\#/ \ / #\ \ / \#/ #\
+---+ +---+ +---+ +---+ +---+ +---+
| 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. 3(c)] [fig. 3(d)]
[fig. 3 expected path of packets]
3. Route Selection
We assume that every router has routing information already.
When a router accept a packet, if the destination address of that
packet matches explicit route, then the router forwards the packet
according to that route.
Otherwise, the router forwards the packet according to the default
route.
If a network has two or more upstreams, the network has two or more
default routes.
At such time, the router refers to the source address of the packet
Ohira Expires on December 22, 2003 [Page 4]
draft-ohira-assign-select-e2e-multihome-00.txt 23 June 2003
and then the router forwards the packet to the upstream whom the
source address belongs to.
4. Tasks of upper layer (out of scope of this document)
a) How to know what addresses does the host to which I will connect
have?
b) How to know what pair of source address and destination address
is the best suitable in some sense?
c) How to keep a connection even if the address of connection member
changes?
5. Conclusions
The proposed way of multihome does not destroy the hierarchical
structure of address space nor increase routing informations
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 of the network.
This way of multihome can deal with source address filtering.
6. Security Considerations
The author believes this document does not have any direct impact on
security of Internet infrastructure.
7. Acknowledgement
The authors would like to thank everyone involved.
8. 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
Ohira Expires on December 22, 2003 [Page 5]
draft-ohira-assign-select-e2e-multihome-00.txt 23 June 2003
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
Kenji Fujikawa
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: fujikawa@real-internet.org
Yasuo Okabe
Integrated information Network System
Kyoto University
Yoshida-Honmachi, Sakyo-ku, Kyoto 606-8501 JAPAN
Tel: +81 75-753-7468
Fax: +81 75-753-7472
Email: okabe@i.kyoto-u.ac.jp
Ohira Expires on December 22, 2003 [Page 6]
| PAFTECH AB 2003-2026 | 2026-04-22 03:56:42 |