[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Revised e2e multihoming ID
Ran;
> >> If router vendors had a knob that enabled separation of
> >> location/identity
> >
> > Separation of locatioin/identity itself does not require any
> > modification on routers.
>
> Please point us towards your online I-D that describes the
> above approach.
As I revised my ID just before the deadline, it is attached.
The revision is on source address selection as follows:
Note that policy based selection of a source address is incompatible
to the end to end principle, because it must be selected as the
destination address by the policy of the other end of the
communication using information local to the other end of the
communication. With so much asymmetric routing of the Internet
today, proper destination address to reply can not be guessed by the
querier.
Thus, DNS query should be modified to carry all the addresses of
clients and servers should try from the most favorable to the least
ones, based on locally available information such as metric in intra
domain full routing table.
Any source address may be selected.
However, to enable source address filtering to discard packets with
source addresses not belonging to an ISP, it is useful to enable a
host, not some intelligent intermediate router, select a source
address compatible with an outgoing ISP. For that purpose, intra
domain routing protocols should maintain routing table entries with
not only preference values of an external routes, but also proper
prefixes to be selected for source addresses, if the entries are
chosen by a host.
Masataka Ohta
--
INTERNET DRAFT M. Ohta
draft-ohta-e2e-multihoming-03.txt Tokyo Institute of Technology
November 2002
The Architecture of End to End Multihoming
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
This memo describes the architecture of end to end multihoming. End
to end multihoming does not burden routing system for multihoming.
That is, even extensive use of end to end multihoming does not
increase the number of entries in a global routing table.
Traditionally with IPv4, multihoming capability is offered by an
intelligent routing system, which, as is always the case with
violating the end to end principle, lacks scalability on a global
routing table size and robustness against link failures.
On the other hand, with end to end multihoming, multihoming is
supported by transport (TCP) or application layer (UDP etc.) of end
systems and does not introduce any problem in the network and works
as long as there is some connectivity between the end systems.
Because end to end multihoming is performed in end systems, the
architecture needs no routing protocol changes Instead, APIs and
applications must be modified to some extent.
M. Ohta Expires on May 1, 2003 [Page 1]
INTERNET DRAFT End to End Multihoming November 2002
1. Introduction
Multihoming is a way for hosts have robust connectivity to the
Internet. Traditionally with IPv4, multihoming has been offered
through intelligence of routing system, that is, the end to end
principle has been ignored.
However, as discussed in section 2, with the explosive deployment of
the Internet, as is always the case with intelligent networking, IPv4
style multihoming was revealed its lack of scalability and
robustness.
Instead, multihoming can be supported based on the end to end
principle by assigning multiple addresses to an interface of a host
and let end systems choose an appropriate address at the transport or
the application layer.
To support the end to end multihoming, no change is necessary on
routing protocols. Instead, APIs and applications must be modified to
detect and react against the loss of connection. In case of TCP
where there is a network wide agreement on the semantics of the loss
of connectivity, most of the work can be done by the kernel code at
the transport layer, though some timing may be adjusted for some
application. However, in general, the condition of "loss of
connectivity" varies application by application that the multihoming
must directly be controlled by application programs.
With IPV6, there is a partial effort of end to end multihoming that
it is of course that an interface has multiple addresses.
However, because the principle of the end to end multihoming is
recognized merely subconsciously and because the current routing
architecture violates the end to end principle in various ways as a
result of partial attempt to avoid the lack of scalability of routing
table size, there are a lot of attempts:
to keep the APIs and application programs as is
to modify routing system intelligent to let it automatically offer
end to end multihoming
which makes IPv6 multihoming as bad as that of IPv4.
This memo describes why multihoming by intelligent routing system is
harmful, how the current routing architecture is damaged and how the
APIs and the applications should be modified to implement the end to
end multihoming.
M. Ohta Expires on May 1, 2003 [Page 2]
INTERNET DRAFT End to End Multihoming November 2002
2. Multihoming by Intelligent Routing System is Harmful
2.1 Routing Table Size
See IAB Network Layer Workshop.
2.2 Lack of Robustness
With route aggregation, routing information can be carried only for
an aggregated area that a loss of connectivity for a part of the area
can not be detected.
For example, if a multihomed site with multiple subnets has a single
global routing table entry, and if a site is partitioned, only a part
of the partitioned can be reached with the global routing table
entry.
A solution is to let all the subnets of the site (or, ultimately,
hosts) individually have global routing table entry, scalability of
which is so absurd that no one bothers to try.
3. The Problems of Current Routing Architecture
End systems (hosts) are end systems. To make the end to end principle
effectively work, the end systems must have all the available
knowledge to make decisions by the end systems themselves.
With regard to multihoming, when an end system want to communicate
with a multihomed end system, the end system must be able to select
most appropriate (based on the local information) destination address
of the multihomed end system.
However, some think it of course to separate routers and nodes and
let hosts not have routing information (which means the current IPv6
architecture is broken) and, worse, let most routers use default
routes.
With detailed route information, end systems can use the information
as a hint to select the best destination address. However, with
default route, end systems have no idea on what is the best address
and must blindly try all the possibilities at random.
It was partly because full routing table was large and was not be
able to be held in a chip on end systems and partly because hosts
should not be affected by routing protocol changes.
In the past, IPv4 address was not assigned with hierarchy and scale
of integration was small.
M. Ohta Expires on May 1, 2003 [Page 3]
INTERNET DRAFT End to End Multihoming November 2002
But, with smaller full routing table and larger scale of integration,
there is no reason not to have full routing table on every end
system.
As there are a lot of routers used in LAN or even in home, it is not
so meaningful that we don't have to upgrade software on hosts, if we
have to upgrade software on routers.
The situation is worse with multicasting. For example, IGMP, which
separates routers and nodes, is a total nonsense as IGMP has been
revised several times upon multicast routing protocol changes.
Moreover, all the legacy multicast routing protocols use intelligent
routing system to deliver group specific information and does not
scale. Multicast architecture must be redone with the end to end
principle in mind. SM (Static Multicast) proposed by the Authors is
such a proposal but latter proposals (such as "simple multicast" or
"AS based static allocation") modified it without understanding the
underlying end to end principle and are useless.
Once a full routing table is available on all the end systems, it is
easy for the end systems try all the destination addresses, from the
most and to the least favorable ones, based on the routing metric.
Note that end to end multihoming works with the separation between
inter domain BGP and intra domain routing protocols, if BGP routers,
based on domain policy, assign external routes preference values
(metric) of intra domain routing protocols.
One may still be allowed, though discouraged, to have local
configuration with dumb end systems and an intelligent proxy. But,
such configuration should be implemented with a protocol for purely
local use without damaging the global protocol.
4. Modifications on APIs and Applications
With TCP, applications must be able to pass multiple addresses to
transport layer (e.g. BSD socket). All the other processing can be
performed by transport layer (typically in kernel) using default or
application specific timing of TCP.
TCP itself must be modified that all the possible addresses of a host
is transmitted to its peer through a TCP option. TCP connections are
identified with all the addresses constitute an identical connection.
Without TCP, applications must be able to detect loss of connectivity
in application dependent way and try other addresses by themselves or
tell transport layer to do so. Applications must still be able to
pass multiple addresses of the destination to transport layer (e.g.
M. Ohta Expires on May 1, 2003 [Page 4]
INTERNET DRAFT End to End Multihoming November 2002
BSD socket) to receive a packet to alternative addresses sent from
the other end of the communication.
The easiest way for applications know all the addresses of the
destination is to use DNS. With DNS reverse, followed by forward,
lookup, applications can get a list of all the addresses of the
destination from an address of the destination.
Note that policy based selection of a source address is incompatible
to the end to end principle, because it must be selected as the
destination address by the policy of the other end of the
communication using information local to the other end of the
communication. With so much asymmetric routing of the Internet
today, proper destination address to reply can not be guessed by the
querier.
Thus, DNS query should be modified to carry all the addresses of
clients and servers should try from the most favorable to the least
ones, based on locally available information such as metric in intra
domain full routing table.
Any source address may be selected.
However, to enable source address filtering to discard packets with
source addresses not belonging to an ISP, it is useful to enable a
host, not some intelligent intermediate router, select a source
address compatible with an outgoing ISP. For that purpose, intra
domain routing protocols should maintain routing table entries with
not only preference values of an external routes, but also proper
prefixes to be selected for source addresses, if the entries are
chosen by a host.
With DNS, it is also required that DNS reverse lookup works properly.
But, as the reverse lookup is the mechanism to delegate IP addresses,
the requirement is no more demanding than assigning valid IP
addresses.
A problem is that locally scoped address (IPv6 link and site local
addresses) can not be used for reverse look up. Use of 8+8 addressing
proposed by one of an Author with globally unique IID (Internet ID)
and ILOC (Internet Locator) is strongly encouraged. With 8+8
addressing, DNS reverse lookup can be performed with IID part only.
Note that 8+8 proposal must not be confused by latter proposal of
routing goof by Mike O'dell, which is a proposal to use intelligent
routers to rewrite source addresses to prevent source address
spoofing and to tunnel between intelligent routers for pseudo
multihoming, both of which are against the end to end principle and,
M. Ohta Expires on May 1, 2003 [Page 5]
INTERNET DRAFT End to End Multihoming November 2002
thus, lacks robustness and/or scalability.
5. Conclusions
For robust and scalable multihoming, IPv6 separation of nodes and
routers must be removed and the transition to the end to end
multihoming should occur with the transition to IPv6.
The modification is not so difficult, because most of the
applications, which must be modified for IPV6 anyway, use TCP only
and most of the UDP applications are DNS, which already tries all the
addresses, or multicast capable ones, which are hopeless.
One may argue that we can't further delay the transition to IPv6
merely because of a random proposal on multihoming.
Then, it is a good idea to start another transition, separated from
ones with legacy IPv6, by allocating a new address prefix of IPv6
address space for the end to end multihoming with 8+8 addressing.
It is important to make the end to end principle work by keeping the
number of top level routing prefix under the new address prefix small
Politics of address space allocation may be avoided if those who are
allocated IPv6 address space with the current prefix are
automatically allocated corresponding address space with the new
prefix.
It should be noted that, because of the end to end nature, the
architecture can be implemented purely on end systems without
modifying routing functionality of existing IPv4 or IPv6 routers.
6. Security Considerations
The author believes there is no special security concern.
7. Author's Address
Masataka Ohta
Graduate School of Information Science and Engineering
Tokyo Institute of Technology
2-12-1, O-okayama, Meguro-ku, Tokyo 152-8552, JAPAN
Phone: +81-3-5734-3299
Fax: +81-3-5734-3299
EMail: mohta@necom830.hpcl.titech.ac.jp
M. Ohta Expires on May 1, 2003 [Page 6]