[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Backwards compatability with existing IPv6 [was: Re: Network layer reqt? [was Re: Transport level multihoming]]
In the future, please restrict yourself to posting the URL for this
draft rather than the entire text.
Ben
On Tue, Apr 10, 2001 at 10:08:44AM +0900, Masataka Ohta wrote:
> Sean;
>
> > I think you are missing the salient point. I agree with Thomas
> > completely that arguing about whether changes should be accepted
> > or not accepted is ridiculous in the absence of any proposed changes
> > in the form that the wg can deal with in a normal IETF way.
> >
> > In other words, feel free to drop a draft onto the list.
>
> I think this is the third time, but as you insist...
>
> Masataka Ohta
> ---
>
>
>
>
>
>
> INTERNET DRAFT M. Ohta
> draft-ohta-e2e-multihoming-01.txt Tokyo Institute of Technology
> April 2001
>
> The Architecture of End to End Multihoming
>
> 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.
>
> Copyright (C) The Internet Society (March/5/2000). All Rights
> Reserved.
>
> 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
>
>
>
> M. Ohta Expires on October 31, 2001 [Page 1]
>
> INTERNET DRAFT End to End Multihoming April 2000
>
>
> architecture needs no routing protocol changes. Instead, APIs and
> applications must be modified to some extent.
>
> 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
>
>
>
> M. Ohta Expires on October 31, 2001 [Page 2]
>
> INTERNET DRAFT End to End Multihoming April 2000
>
>
> APIs and the applications should be modified to implement the end to
> end multihoming.
>
> 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.
>
>
>
> M. Ohta Expires on October 31, 2001 [Page 3]
>
> INTERNET DRAFT End to End Multihoming April 2000
>
>
> In the past, IPv4 address was not assigned with hierarchy and scale
> of integration was small.
>
> 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
>
>
>
> M. Ohta Expires on October 31, 2001 [Page 4]
>
> INTERNET DRAFT End to End Multihoming April 2000
>
>
> 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.
> 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 selection of a source address violates the end to end
> principle, because it must be selected as the destination address by
> the other end of the communication using information local to the
> other end of the communication. With so much assymmetric 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 favourable to the least
> ones.
>
> 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,
> thus, lacks rubustness 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
>
>
>
> M. Ohta Expires on October 31, 2001 [Page 5]
>
> INTERNET DRAFT End to End Multihoming April 2000
>
>
> 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
> Computer Center, Tokyo Institute of Technology
> 2-12-1, O-okayama, Meguro-ku, Tokyo 152-8550, JAPAN
>
> Phone: +81-3-5734-3299
> Fax: +81-3-5734-3415
> EMail: mohta@necom830.hpcl.titech.ac.jp
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> M. Ohta Expires on October 31, 2001 [Page 6]
>
> INTERNET DRAFT End to End Multihoming April 2000
>
>
> 8. Full Copyright Statement
>
> "Copyright (C) The Internet Society (April/5/2001). All Rights
> Reserved.
>
> This document and translations of it may be copied and furnished to
> others, and derivative works that comment on or otherwise explain it
> or assist in its implementation may be prepared, copied, published
> and distributed, in whole or in part, without restriction of any
> kind, provided that the above copyright notice and this paragraph are
> included on all such copies and derivative works. However, this
> document itself may not be modified in any way, such as by removing
> the copyright notice or references to the Internet Society or other
> Internet organizations, except as needed for the purpose of
> developing Internet standards in which case the procedures for
> copyrights defined in the Internet Standards process must be
> followed, or as required to translate it into languages other than
> English.
>
> The limited permissions granted above are perpetual and will not be
> revoked by the Internet Society or its successors or assigns.
>
> This document and the information contained herein is provided on an
> "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
> TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
> BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
> HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
> MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> M. Ohta Expires on October 31, 2001 [Page 7]
>