One document matched: draft-ohira-assign-select-e2e-multihome-02.txt
Differences from draft-ohira-assign-select-e2e-multihome-01.txt
INTERNET-DRAFT K. Ohira
October 27, 2003 K. Ogata
A. Matsumoto
K. Fujikawa
Y. Okabe
Kyoto University
Y. Koyama
Trans New Technology
IPv6 Address Assignment and Route Selection
for End-to-End Multihoming
<draft-ohira-assign-select-e2e-multihome-02.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
In this document, we propose a way of address assignment and route
selection suitable for "Host-Centric" or "End-to-End" multihoming,
where an end node plays the main role of multihoming.
The key techniques are a hierarchical address assignment and a source
address based routing (SABR) for only default route entry.
In our proposal, an IP address itself has some sense of routing
Ohira Expires on April 27, 2004 [Page 1]
draft-ohira-assign-select-e2e-multihome-02.txt October 27, 2003
information. We propose that an address assignment SHOULD be
hierarchical. Under the conditions that address assignment is
hierarchical, when someone delegates an address block, it means that
he also hands routing information to his downstream at the same time.
In this manner, a host which has several addresses can select which
upstream to go through with by selecting its source address.
1. Introduction
As described in RFC3582 [REQ], the main purpose of multihoming is
getting redundancy and sharing a load.
Usually, if someone wants a site to be multihomed, he has to get an
AS number and connect to upstream ISP with BGP peering. This method
is too difficult to configure and AS numbers are limited, so it is
actually unable for small sites to be multihomed.
In the BGP method, we MUST trust any routing information from outside
of a site and reconfigure routing information inside of the site, so
this method is problematic at reliability and its speed.
Furthermore, in IPv6, it is REQUIRED that we aggregate addresses more
thoroughly than in IPv4 because of its address length.
In this document, we show a scalable way to multihome with a very
little information from outside. It is based on so-called
"Host-Centric" [M6H] or "End-to-End" [E2E] multihome, where an end
node plays the main role.
2. Types of Multihoming Sites
2.1 Definition of Terms
Terms which are not referred here are used as the meaning in RFC3582
[REQ].
The term "site" means the small site and it is assumed as a home
network. In the section 5, we will deal with so-called "Large site".
2.2 Network Topology of a Site
A site can be classified into the following 3 cases:
1. single link, single exit router (fig. 1),
2. single link, multiple exit routers (fig. 2) and
Ohira Expires on April 27, 2004 [Page 2]
draft-ohira-assign-select-e2e-multihome-02.txt October 27, 2003
3. multiple link, multiple exit routers (fig. 3).
| | |
| | |
+-----+ +-----+ +-----+
| | | | | |
+-----+ +-----+ +-----+
| | |
----+-+------ ------+-----+------+------
| |
+-----+ +-----+
| | | |
+-----+ +-----+
[fig. 1] [fig. 2]
| |
| |
+-----+ +-----+
| | | |
+-----+ +-----+
| |
---+--+---- ----+--+---
| |
+-----+ +-----+
| | | |
+-----+ +-----+
| |
---+--------+---------+---
|
+-----+
| |
+-----+
[fig. 3]
At this time, we assume that a site is assigned PA (Provider
Aggregatable) address prefixes from each upstream (multi-addressing)
and each upstream carries out ingress filtering on an advice of
RFC2267 [NIF].
In the case of 1, if the exit router has a mechanism of forwarding a
packet to the proper upstream, the other nodes in the site do not
have to be modified at all.
Ohira Expires on April 27, 2004 [Page 3]
draft-ohira-assign-select-e2e-multihome-02.txt October 27, 2003
In the case of 2, if the exit routers have a mechanism of forwarding
a packet which should go through with another exit router to the
proper exit router, the other nodes in the site do not have to be
modified at all.
In the case of 3, a tunnel between exit routers makes exit routers
virtually on one link, so a method used in the case 2 is available.
This tunnel method has an advantage that it requires no modification
except on site exit routers. However, with this method, according
to the position of a host and exit routers, a packet may go through
with uselessly long path. Moreover, in this method, an exit router
has to know addresses of the other routers in advance and these
tunnels should be fully-meshed among all exit tunnels.
Furthermore, in the most of usual methods, routing information in
a site deeply depends on that from outside of the site. This is
problematic at the point of reliability and its speed.
In order to solve these issue, we propose the following method.
3. Proposed solution
3.1 Network topology and Hierarchical Address assignment
This method is categorized into multi-addresses model. In this
model, a site is delegated a prefix of PA address from each upstream.
At this time, in order to be easy for a site to construct dynamic
network:
o The length of the prefix which an ISP delegates to a site is equal
to or less than 48.
A site exit router advertises to the all nodes in the site:
o Delegated prefix(es) and
o Information that this exit router is proper one for packets with
such prefixed address as source address.
In order to advertise, RR (Router Renumbering) [RRN], DHCPv6 Prefix
Option [DHC] and/or RA (Router Advertisement) [NDC] may be useful.
The initial configurations are as below.
o Upper 48 bits: Some temporary "site-local" prefix such as Unique
Local IPv6 Unicast Address [UQL].
o Middle 16 bits: With manual configuration or auto configuration
Ohira Expires on April 27, 2004 [Page 4]
draft-ohira-assign-select-e2e-multihome-02.txt October 27, 2003
such as zeroconf [ZCF,SLA], REQUIRED to complete
configurations independently of the upper 48bit.
o Lower 64 bits: Node identifier.
3.2 Route Selection
With an usual method, routing information inside of a multihomed site
depends on that of outside, then there are some problems:
o A node in the site have to trust the unreliable information.
o When a connection between site exit router and upstream fails,
it spends a few minutes to recover (some connections may timeout).
In our proposing method,
o In a site, route information of only inside of the site is
advertised.
o Route information about outside of the site is only default route
in order to rely on the least information about outside.
In order to select the proper exit router, nodes SHOULD refer the
source address of a packet bound for the outside of the site. In
other words,
o Source Address Based Routing (SABR) SHOULD be done for default
route entries.
In our method, an external route is expressed as a connection to the
"next-hop" upstream. Therefore, this information is reliable as
information about inside of the site. Besides, because the whole
(or a part of) information about connections to upstream is
advertised to all nodes in the site and a node (or an application
running on the node) can select or change its source address, more
rapid change routes is expected.
4. Evaluation of our solution
In this section, we will evaluate how much our proposing method
meets the requirements pointed out in RFC3582 [REQ].
4.1 Capabilities of IPv4 Multihoming
4.1.1 Redundancy
Every external connection is treated completely separate.
Ohira Expires on April 27, 2004 [Page 5]
draft-ohira-assign-select-e2e-multihome-02.txt October 27, 2003
Therefore, our proposing method is able to continue a connection
unless all external connection fail.
4.1.2 Load Sharing
A site is able to distribute both inbound and outbound traffic
between multiple transit providers.
4.1.3 Performance
No information between upstream ISPs is REQUIRED.
If a corresponding node can divide a stream into several destination
addresses, we can accomplish to distribute inbound traffic.
4.1.4 Policy
Policies of a site will be expressed as ingress/egress filtering
rules. If a site does not want a host to use an external connection,
the site can neglect to re-delegate an address with the prefix
specific to the external connection.
4.1.5 Simplicity
Our proposing method is very simple. In the simplest case, we may
be able to configure with only one command or jumper switch.
4.1.6 Transport-Layer Survivability
With the method described in the section 3, we can select a route to
use from several candidates.
At a point of view of an application, we expect that all messages are
exchanged in just one connection. In order to meet this requirement,
we need some co-operation with L4 (for UDP, it may be L7).
There are two approaches as below:
o Define an intermediate layer between the transport layer and IP
layer. In this approach, the intermediate layer merges several
IP addresses into one transport layer address, so a transport
layer protocol thinks that an unchanged connection continues.
Ohira Expires on April 27, 2004 [Page 6]
draft-ohira-assign-select-e2e-multihome-02.txt October 27, 2003
o Transport layer protocol itself directly handles multiple IP
addresses.
As an intermediate layer, LIN6 [LIN,L6A], HIP [HIP], MAST [MAS],
SIM [SIM] and etc. are proposed.
In order to bind several IP address to a TCP connection, the TCP
extension to multihome [MHO] is proposed. SCTP [SCT] can handle
several IP addresses in an association.
A connection between a node and another node may have several paths
(i.e. several pairs of source/destination addresses). Decision of
priority of these pairs SHOULD be done in L4/L7 with following the
rules described in RFC3484 [DAS].
However, these methods are both disputable about how to hold binding
relation and its security issues.
4.1.7 Impact on DNS
Any change of external connections of a site cause change(s) of
prefixes which the site has. Therefore, in the worst case, we may
be required to change DNS information at every time.
4.1.8 Packet Filtering
Our proposing method is designed to co-operate with ingress/egress
filtering. If the source address of an IP packet is valid then the
packet is forwarded to the proper next hop, otherwise the packet will
be discarded.
4.2 Additional Requirements
4.2.1 Scalability
Only a Provider Aggregatable IP address block from upstream is
REQUIRED. This address is always aggregated at upstream, so even if
the number of multihoming site with our proposing method increase,
the number of routing information at DFZ (Default Free Zone). Still
more, no AS number is REQUIRED for a site to be multihomed.
In these points, our proposing method is very scalable.
4.2.2 Impact on Routers
Ohira Expires on April 27, 2004 [Page 7]
draft-ohira-assign-select-e2e-multihome-02.txt October 27, 2003
The SABR is REQUIRED for at least one router in a multihoming site.
If there are some routers which cannot handle SABR, according to the
position, routing loop may be occurred.
The authors think that this requirement is relatively little because
the SABR is required only for default route entry.
These modifications do not prevent normal single-homed operations.
In a single-homed site, modified routers and unmodified routers
can coexist.
4.2.3 Impact on Hosts
The SABR is REQUIRED for all end hosts who want to be fully
multihomed. However, a legacy (without SABR) host can be obtain some
functions of multihome.
If you want to bind several IP addresses to a single TCP connection,
TCP Extension for Multihoming may be useful.
4.2.4 Interaction between Hosts and the Routing System
No interactions are REQUIRED except for information about proper next
hop for each source address prefixes.
4.2.5 Operations and Management
Administrators of a site are completely capable to monitor the state
or to configure parameters of multihoming. At this time, the
administrators do not have to do any co-operative work with
administrators of upstream.
4.2.6 Cooperation between Transit Providers
Our proposing method does not require any co-operative work between
upstream providers at all.
4.2.7 Multiple Solutions
In a single network segment, our proposing method is RECOMMENDED to
be used solely. However, we can divide the site into two or more
segment in order to use those multiple solutions respectively.
Ohira Expires on April 27, 2004 [Page 8]
draft-ohira-assign-select-e2e-multihome-02.txt October 27, 2003
5. Applying for ``Large Site''
In the former sections, we assume that the network is 2-level:
a site and the outside of the site. However, this 2-level relation
is extensible to multi-level. This extension may be useful when we
apply our method to a so-called "Large Site". In such a case, the
hierarchical relationship is:
(upstream) ISP -- large site (cluster of small sites) -- small site.
At this time, a large site is delegated a prefix from an ISP and
delegate a sub-prefix to a small site.
6. Security Considerations
A protocol of verifying identification of L4/L7 may introduce some
security problems. Therefore, it is out of scope of this document.
7. IANA Considerations
There are no IANA considerations in this document.
8. References
[REQ] J. Abley, et. al., "Goals for IPv6 Site-Multihoming
Architectures", RFC3582, August 2003.
[RRN] M. Crawford, "Router Renumbering for IPv6", RFC2894, August
2000.
[MAS] D. Crocker, "Multiple Address Service for Transport (MAST):
An Extended Proposal", Internet Draft (work in progress),
draft-crocker-mast-proposal-01.txt, September 2003.
[DAS] R. Draves, "Default Address Selection for Internet Protocol
version 6 (IPv6)", RFC3484, February 2003.
[NIF] P. Ferguson, et. al., "Network Ingress Filtering: Defeating
Denial of Service Attacks which employ IP Source Address
Spoofing", RFC2267, January 1998.
[UQL] R. Hinden, et. al., "Unique Local IPv6 Unicast Address",
Internet Draft (work in progress), draft-hinden-ipv6-global-
local-addr-02.txt, June 2003.
[M6H] C. Huitema, et. al., "Host-Centric IPv6 Multihoming", Internet
Draft (work in progress, expired), draft-huitema-multi6-hosts-
Ohira Expires on April 27, 2004 [Page 9]
draft-ohira-assign-select-e2e-multihome-02.txt October 27, 2003
01.txt, June 2002.
[L6A] A. Matsumoto, et. al., "Basic Socket API Extensions for LIN6
End-to-End Multihoming", Internet Draft (work in progress),
draft-arifumi-lin6-multihome-api-00.txt, June 2003.
[MHO] A. Matsumoto, et. al., "TCP Multi-Home Options", Internet Draft
(work in progress), draft-arifumi-tcp-mh-00.txt, October 2003.
[HIP] R. Moskowitz, et. al., "Host Identity Protocol", Internet Draft
(work in progress), draft-moskowitz-hip-08.txt, October 2003.
[NDC] T. Narten, et. al., "Neighbor Discovery for IP Version 6
(IPv6)", RFC2461, December 1998.
[SIM] E. Nordmark, "Strong Identity Multihoming using 128 bit
Identifiers (SIM/CBID128)", Internet Draft (work in progress),
draft-nordmark-multi6-sim-00.txt, October 2003.
[E2E] M. Ohta, "The Architecture of End to End Multihoming", Internet
Draft (work in progress), draft-ohta-e2e-multihoming-05.txt,
June 2003.
[SCT] R. Stewart, et. al., "Stream Control Transmission Protocol",
RFC2960, October 2000.
[LIN] F. Teraoka, et. al., "LIN6: A Solution to Mobility and Multi-
Homing in IPv6", Internet Draft (work in progress, expired),
draft-teraoka-mobility-lin6-00.txt, December 2000.
[ZCF] S. Thomson, et. al., "IPv6 Stateless Address
Autoconfiguration", RFC2462, December 1998.
[DHC] O. Troan, et. al., "IPv6 Prefix Options for DHCPv6", Internet
Draft (work in progress), draft-ietf-dhc-dhcv6-opt-prefix-
delegation-05.txt, October 2003.
[SLA] T. Yoshihiro, et. al., "Stateless Autoconfiguration of IPv6
Site-Local Address." Communications and Computer Networks
pp.. 299--304, IASTED (2002)
9. Authors' Addresses
Kenji Ohira
Graduate School of Informatics
Kyoto University
Yoshida-Hommachi, Sakyo-ku, Kyoto 606-8501 JAPAN
Ohira Expires on April 27, 2004 [Page 10]
draft-ohira-assign-select-e2e-multihome-02.txt October 27, 2003
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-Hommachi, 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-Hommachi, 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-Hommachi, 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-Hommachi, Sakyo-ku, Kyoto 606-8501 JAPAN
Tel: +81-75-753-7458
Fax: +81-75-751-0482
Email: okabe@i.kyoto-u.ac.jp
Youichi Koyama
Trans New Technology, Inc.
Inohara BLDG. 2F, 72 Tanaka Monzencho, Sakyo,
Kyoto 606-8225 JAPAN
Tel: +81-75-706-9800
Fax: +81-75-706-9801
Email: koyama-y@trans-nt.com
Ohira Expires on April 27, 2004 [Page 11]
| PAFTECH AB 2003-2026 | 2026-04-22 03:44:49 |