[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: initial issues
Masataka,
We all ready have I think a list of folks on here who are coming from
different venues and needs, which is a very desirable thing to reach a
consensus on a hard problem. But if we get in flame wars what will happen
is will fan the flames of differences btw the list into emotion and
non-technical productive discussion. Words like stupid (or my favorite one
even
"battles") are not helpful.
Once we all get to know each other and get some productive stuff done then
have it by all means. But lets just get a charter, strategy, begin
requirements definition and not try to change what one may or may not like
in IPv6 right now. That is really why IPng exists. This list is not a back
door to change what is in IPng's charter.
my 2cents,
/jim
> -----Original Message-----
> From: ext Masataka Ohta [mailto:mohta@necom830.hpcl.titech.ac.jp]
> Sent: Tuesday,February 13,2001 5:48 PM
> To: Ben Black
> Cc: Sean Doran; multi6@ops.ietf.org
> Subject: Re: initial issues
>
>
> Ben;
>
> > >
> > > > * This started off a thread in private about what
> > > > the address assignment policy for v6 should be. Randy
> noted also that
> > > > the IESG has asked for a revision to _2.5.6 of
> > > > draft-ietf-ipngwg-addr-arch-v3-04.txt to make it
> classless rather
> > > > than clasful. In other words, the multihoming
> environment for v6
> > > > is going to be identical to v4, viz. CIDR. TLA/NLA
> will no longer exist.
> > >
> > > Stupid.
> > >
> >
> > This is not constructive.
>
> Yes, because the thread is not constructive.
>
> As you should be aware, in this thread, you are not constructive.
>
> > You obviously have strong religious beliefs
> > regarding what is and is not multihoming, how the Internet
> _should_ work,
> > and how networks are engineered. Many others have
> different views, and
> > my personal experiences contradict your assertions
> regarding how networks
> > that work are built. Can we please focus on _requirements_?
>
> The requirement is multihoming.
>
> It is worthless to spend a lot of words try to modify the
> definition of
> multihoming, because the requirement is not modified.
>
> > As an aside, I personally think a GSE-like approach is more
> realistic
> > given the views on multihoming I've seen expressed on
> various lists and
> > at the multi6 BoF.
>
> You are not constructive, again.
>
> You are merely stating that there is strong religious beliefs on GSE
> on various lists and the multi6 BoF.
>
> To be destructively construcive, it was easy to see GSE violate
> the end to end principle and have scalability/robustness problem.
>
> Masataka Ohta
>
> PS
>
> A constructive proposal is attached.
> ---
> INTERNET DRAFT
> M. Ohta
> draft-ohta-e2e-multihoming-00.txt Tokyo Institute of
> Technology
>
> M. Sola
> Waseda
> University
>
> April 2000
>
> 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 (April/28/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
>
>
>
> M. Ohta Expires on October 5, 2000
> [Page 1]
> >
> INTERNET DRAFT End to End Multihoming
> April 2000
>
>
> 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.
>
> 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. 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.
>
>
>
>
> M. Ohta Expires on October 5, 2000
> [Page 2]
> >
> INTERNET DRAFT End to End Multihoming
> April 2000
>
>
> 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.
>
> 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
>
>
>
> M. Ohta Expires on October 5, 2000
> [Page 3]
> >
> INTERNET DRAFT End to End Multihoming
> April 2000
>
>
> 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.
>
> 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 standard
> timing of TCP.
>
> Without TCP, applications must be able to detect loss of
> connectivity
> in application dependent way and try other addresses by
> themselves or
>
>
>
> M. Ohta Expires on October 5, 2000
> [Page 4]
> >
> INTERNET DRAFT End to End Multihoming
> April 2000
>
>
> 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 is unimportant,
> because it is
> selected as the destination address by the other end of the
> communication.
>
> With DNS, it is 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.
>
> 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.
>
>
>
> M. Ohta Expires on October 5, 2000
> [Page 5]
> >
> INTERNET DRAFT End to End Multihoming
> April 2000
>
>
> 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
>
> Manolo Sola
> Department of Information and Computer Science
> School of Science and Engineering, Waseda University
> 3-4-1, Okubo, Shinjuku-ku, Tokyo 169-8555, JAPAN
>
> Phone: +81-3-5734-3299
> Fax: +81-3-5734-3415
> EMail: sola@jet.es
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> M. Ohta Expires on October 5, 2000
> [Page 6]
> >
> INTERNET DRAFT End to End Multihoming
> April 2000
>
>
> 8. Full Copyright Statement
>
> "Copyright (C) The Internet Society (April/28/2000). 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 5, 2000
> [Page 7]
> >
>