Network Working Group                                          D. Massey
Internet-Draft                                            Colorado State
Intended status: Informational                                   L. Wang
Expires: August 29, 2007                                      U. Memphis
                                                                B. Zhang
                                                              U. Arizona
                                                                L. Zhang
                                                                    UCLA
                                                       February 25, 2007


         A Proposal for Scalable Internet Routing & Addressing
                      draft-wang-ietf-efit-00.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   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.

   This Internet-Draft will expire on August 29, 2007.

Copyright Notice

   Copyright (C) The IETF Trust (2007).









Massey, et al.           Expires August 29, 2007                [Page 1]

Internet-Draft                    eFIT                     February 2007


Abstract

   Our measurement studies of the global Internet routing system show
   that prefix de-aggregation has led to the DFZ routing table size
   growing at a rate which is much faster than the Internet itself.  The
   main causes of prefix de-aggregation include user site multihoming
   and traffic engineering.  We propose to move Internet service
   providers to a separate address space as an effective solution to the
   routing scalability problem.  We discuss different means to provide
   the mapping service between user and provider address spaces and the
   pros and cons of each approach, as well as why we believe such an
   architectural change is necessary to solve the routing scalability
   problem.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  The eFIT Proposal  . . . . . . . . . . . . . . . . . . . . . .  5
   3.  How To Bridge The Two Spaces?  . . . . . . . . . . . . . . . .  7
   4.  The Mapping Service  . . . . . . . . . . . . . . . . . . . . .  8
   5.  Handling Border Link Failures  . . . . . . . . . . . . . . . . 10
   6.  Related Efforts  . . . . . . . . . . . . . . . . . . . . . . . 12
     6.1.  Putting users and providers into separate IP address
           spaces . . . . . . . . . . . . . . . . . . . . . . . . . . 12
     6.2.  Location-Based Addressing  . . . . . . . . . . . . . . . . 13
     6.3.  Summary of Previous and Ongoing Efforts  . . . . . . . . . 13
   7.  Summary  . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
   8.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 17
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 18
   10. Security Considerations  . . . . . . . . . . . . . . . . . . . 19
   11. Informative References . . . . . . . . . . . . . . . . . . . . 20
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
   Intellectual Property and Copyright Statements . . . . . . . . . . 22

















Massey, et al.           Expires August 29, 2007                [Page 2]

Internet-Draft                    eFIT                     February 2007


1.  Introduction

   Analysis of the routing tables in the default free zone (DFZ) reveals
   important problems for Internet routing.  The first and most
   noticeable aspect is the growth in the table size.  Our analysis of
   data collected by RouteViews and RIPE BGP monitoring projects shows
   that the DFZ routing table size has been growing at a much higher
   rate than that of the routable address space in the Internet.  At the
   same time, it is well known that IPv4 address allocations are
   constrained by the shortage of remaining IPv4 address space.  An
   (unintended) side effect of this shortage may be limiting the speed
   of route table growth.  When IPv6 deployment starts rolling out in a
   wide scale and removes the current address space limits, we envision
   that the DFZ routing table could substantially accelerate its growth.

   By raising concerns over table size, we do not mean to imply that
   growth is inherently bad.  When managed correctly, growth in the
   table size can reflect the increasing importance and increasing scale
   of the network and is a sign of a healthy network.  But the current
   situation is an example of poorly managed growth.  In today's
   Internet routing and addressing architecture, both user sites and
   Internet service providers share the same address and routing space.
   But user sites and service providers do not share the same goals and
   same challenges.  From a provider perspective, the routing system
   needs topologically aggregatable address assignment and usage.  The
   assignment and use of topologically aggregatable addresses could not
   only reduce the table size, but enable better network routing by
   creating more meaningful entries in the table.  However enterprise
   customers desire Provider-Independent (PI) address blocks in order to
   maintain the freedom to switch between ISPs while avoiding
   renumbering, and to ease multihoming which has become a universal
   practice.  From the perspective of a user site, multihoming is
   necessary and should be encouraged to help provide a more robust
   Internet.  In fact, our data suggests that a main cause of the rapid
   routing table growth is site multihoming.  Transit providers and user
   sites effectively seek opposite approaches to address allocation and
   routing announcements with both sides supported by valid technical
   and economic reasons.  Overall, the global routing system is losing
   the ground of topologically aggregatable address usage, as evidenced
   by increasingly fragmented prefixes in BGP routing announcements.
   These issues have also been identified in the report of IAB Workshop
   on Routing and Addressing [RAWS].

   Recognizing the direct conflicts between Internet users and ISPs with
   regard to the IP address allocation and usage, we propose to solve
   the global routing scalability problem by putting the ISPs in a
   separate IP address space, where the addresses can be allocated in a
   topologically aggregatable way to enable scalable routing.  Data



Massey, et al.           Expires August 29, 2007                [Page 3]

Internet-Draft                    eFIT                     February 2007


   traffic between Internet users can be tunneled over the transit core,
   in a way similar to VPNs which are widely used today for
   interconnecting multiple sites of the same enterprise network across
   the global Internet backbone.  Our proposed solution is to tunnel all
   data traffic between all user sites across the backbone.  The
   separate address spaces allows both providers and user sites to move
   forward in a way that meets their respective technical and economic
   objectives.  It has further advantages for facilitating the roll-out
   of IPv6 addresses since data is now tunneled across the core,
   irrespective of whether the user site has deployed IPv4 or IPv6
   addresses.  Overall, we believe the approach has great promise for
   both provider and user site view address allocations, route
   announcements, and routing in general.

   In the rest of this draft we describe the proposed solution in more
   detail and outline the open issues in its implementation.  We also
   identify the pros and cons of different solutions to the open issues.


































Massey, et al.           Expires August 29, 2007                [Page 4]

Internet-Draft                    eFIT                     February 2007


2.  The eFIT Proposal

   The Internet is comprised of two types of networks: user networks and
   transit provider networks.  User networks correspond to business,
   universities, and organizations.  To them, the Internet is a means to
   some end(s), i.e., they run applications to communicate with other
   user networks over the Internet.  On the other hand, transit networks
   are ISPs, whose goal is to realize and sell end-to-end data delivery
   service.  The number of user networks is much larger than that of
   transit networks.  Moreover, user networks are growing at a faster
   rate than transit networks which actively adjust their connectivity
   in order to accommodate the growing user networks.  These two types
   of networks have different purposes, different growth trends, and
   different operational goals.  Putting them in the same address and
   routing space has been the root cause for many problems as the
   Internet grows substantially.

   We propose to separate user networks and transit provider networks in
   terms of both addressing and routing.  First, user networks and
   transit networks use separate address spaces, and their address
   formats can be different.  Second, their routing spaces are
   separated.  A provider routing protocol is operated among routers
   inside the transit core to maintain routes to all the provider
   networks only.  The provider routing fundamentally differs from the
   current BGP as it is confined within the provider space.  Each user
   network runs its own routing protocol to maintain routes to reach
   internal subnets and its immediate neighbors (its providers or other
   directly connected user networks).  There is no routing protocol
   operating across the links between the user networks and the transit
   core.

   A network becomes part of the provider space if it obtains a provider
   address prefix and runs the provider routing protocol with other
   transit providers.  A user network can continue using its current
   provider independent address block if it has one or it can obtain one
   from a regional Internet registry.  It can also use its current
   intra-domain routing protocol.

   End-to-end data delivery is achieved by tunneling user packets across
   the provider space.  When a user packet reaches the border of the
   transit core, the ingress edge router will map the destination user
   address to a provider address that directly connects to the
   destination user network.  The ingress edge router encapsulates the
   user packet and sends it to the destination provider address.  Once
   the packet arrives at the other end of the tunnel, the egress edge
   router will decapsulate it and send the original data packet into the
   destination user network.  A mapping service is needed to map user
   addresses to corresponding provider addresses.  It will be discussed



Massey, et al.           Expires August 29, 2007                [Page 5]

Internet-Draft                    eFIT                     February 2007


   in Section 4.

   On the surface the encapsulation step in crossing the transit core
   may bear a resemblance to NAT (Network Address Translation); however,
   our proposal differs from NAT in fundamental ways.  We assign unique
   and provider-independent addresses to all hosts in user space, thus
   they can be reached in the face of individual provider failures.  Any
   user host can directly talk to any other user host by simply putting
   the destination address in the packet.  Therefore our proposal helps
   reinstall the end-to-end transparency model in the Internet.

   Viewed from user networks, the provider space is a single logical hop
   connecting all user networks, very much like a single "wire"
   providing data transit service.  Therefore, we call our proposal eFIT
   (enable Future Internet innovation through Transit wire).  In this
   architecture, user networks and transit provider networks are
   decoupled in both addressing and routing.  It helps scale global
   routing and also allow user networks and transit networks to evolve
   independently.

   With this separation, the routing table size of global DFZ routers is
   under control, because it only needs to record routes to each
   provider network, whose number is small and grows slowly.  One
   provider network may announce multiple prefixes.  However, since the
   addressing is separated from that of user networks, we can design the
   format of provider addresses and allocate them in a way to encourage
   aggregation.  More importantly, the routing table will not be
   inflated by user networks' multi-homing and traffic engineering
   practices or the fast increase of user networks.  Another benefit is
   that the number of routing updates is under control for DFZ routers,
   because the instability from user networks is insulated from the
   transit core.  Considering that there is a large and increasing
   number of user networks, and some of them are the sources of frequent
   routing instability, the separation will reduce the routing updates
   in the transit core significantly.  In short, since the global
   routing is confined among provider networks only, its scalability
   will be much better than that of today's Internet, and will also be
   able to sustain Internet growth in the near future.

   The separation is also beneficial to user networks.  They will have
   truly provider-independent addresses, which enable them to change
   providers without renumbering.  They may also have an address format
   that is designed to best facilitate their internal routing.  They can
   explore different site multihoming and traffic engineering techniques
   without affecting the scalability of the global routing system.






Massey, et al.           Expires August 29, 2007                [Page 6]

Internet-Draft                    eFIT                     February 2007


3.  How To Bridge The Two Spaces?

   Separating the user networks and provider networks makes the global
   routing system scale.  But at the same time, end-to-end data delivery
   also requires bridging the two spaces.  Three mechanisms are
   essential to the bridging.

   First, a mapping service is needed to map each user address to its
   provider attachment points, i.e., the egress transit router(s)
   through which data packets can be delivered to the user address.
   These egress transit routers are directly connected to the user
   network that owns the particular user address.

   Second, end-to-end data delivery across the transit core is achieved
   by encapsulating user data packets in a provider space packet header,
   whose source address is the ingress transit router connected to the
   source user network, and whose destination address is the egress
   transit router connected to the destination user network.

   Third, the failures of links between user space and provider space
   must be handled by a mechanism external to the routing system.  In
   eFIT, provider network routing and user network routing are confined
   to their own space, while links between them are in neither space.
   Therefore, failures of such border links are not reflected in either
   provider routing or user routing.  A mechanism is needed so that the
   ingress transit router can stop sending data packets destined to the
   failed link until it is up again.

   In the next two section, we will discuss potential approaches to
   implement the mapping service and handle border link failures.





















Massey, et al.           Expires August 29, 2007                [Page 7]

Internet-Draft                    eFIT                     February 2007


4.  The Mapping Service

   The basic functionality of the mapping service is that, given a
   destination user address, it should return one or more destination
   provider addresses so that the packet can be encapsulated and
   forwarded across the transit core to reach the destination user
   network.

   The mapping service should be implemented by the transit core;
   otherwise it will introduce another dependency between the two
   spaces.  Since the transit service providers are responsible for data
   delivery between user networks, they have the incentive to provide
   quick and secure mapping service.

   In general, there are two types of approaches to implement this
   service.

      Flooding: This approach simply floods the mapping data through all
      transit service providers; Each provider can then decide how it
      may further distribute the information to its own edge routers.
      An advantage of this approach is that the mapping information is
      readily available locally at the edge routers, therefore packet
      forwarding should not experience any significant delay from
      looking up the mapping information.  The disadvantage is that any
      change in the mapping information must be proactively propagated
      to all providers, even when the change may not affect any data
      traffic.  Given the number of user networks may grow at a rapid
      rate, the dissemination system can potentially face a scalability
      challenge.

      Distributed Servers: this approach builds a system of distributed
      servers that make the mapping information available through query
      and reply.  This system of servers can be implemented either in a
      hierarchy such as that of the DNS, or in a flat structure such as
      distributed hash tables (DHTs).  One advantage is that a change in
      the mapping information only results in a change to some servers,
      rather than being proactively propagated globally.  Another
      advantage is that individual responsible parties can selectively
      enhance their own mapping service through more replications or
      fast servers.  The disadvantage of this approach is that the
      lookup process may add extra delay to packet forwarding.  Caching
      and prefetching popular mapping entries can provide effective
      performance improvement, but with associated increase in system
      complexity.

   Overall, there are interesting trade-offs in each approach and
   further research is needed.




Massey, et al.           Expires August 29, 2007                [Page 8]

Internet-Draft                    eFIT                     February 2007


   The basic mapping service essentially provides the binding between a
   user address and its provider attachment points.  This binding can be
   used to support the migration from IPv4 to IPv6.  For example, a user
   network can move to IPv6 independently from whether its ISPs have
   deployed IPv6, as long as the mapping service supports the mapping
   between the IPv6 user address to the IPv4 provider addresses.  The
   mapping service also opens the door to new services or functionality.
   For example, the mapping information could specify the address
   owner's preferred traffic distribution among its multiple provider
   attachment points, in order to load balance incoming traffic.









































Massey, et al.           Expires August 29, 2007                [Page 9]

Internet-Draft                    eFIT                     February 2007


5.  Handling Border Link Failures

   In this section, we discuss how to handle the failures of border
   links between user networks and their providers effectively and
   efficiently.  We note that these failures could be treated as mapping
   changes and thus handled by the mapping service directly, i.e.,
   treating every link up and down as a change of the mapping
   information.  However, the link failures could occur much more
   frequently than changes in business relationship such as a user
   network subscribing to a new ISP.  If the link failures are
   propagated as mapping changes, a damping mechanism must be in place
   to prevent a flapping link from overloading the mapping service with
   its frequent status changes.

   Below we discuss other options that do not necessarily involve the
   mapping service, i.e., the link failures are not treated as mapping
   changes.

   1.  Masking the failure via tunneling: This approach lets the egress
       transit router mask the link failure by redirecting the packet to
       another router that is also connected to the destination user
       network; The first router can use the mapping service to find the
       second router.  This is a viable approach if both routers belong
       to the same provider, or otherwise the first router may not have
       the economic incentive to redirect the packet to a competitor.

   2.  Notifying ingress transit routers after the failure: this
       approach notifies ingress transit routers about the link failure
       so that they will stop sending data packets towards the failed
       link for a period of time specified in the notification messages.
       The propagation of such notification messages can be proactive or
       reactive.

       *  In the proactive mode, the egress transit router sends the
          failure notification to all the ingress transit routers
          whenever the failure occurs, e.g., through a flooding
          mechanism.  However, this mode is appropriate only if the link
          fails occasionally.  Otherwise, a flapping link could lead to
          frequent waves of failure notification messages flooded
          everywhere.  Note that if the mapping service is implemented
          using flooding, this function could be (but does not have to
          be) provided by the mapping service, except that the receiver
          needs to know that this is a temporary failure, not a long-
          term change.  If the mapping service is implemented using a
          network of servers, the proactive propagation of the
          notification messages to the ingress transit routers needs to
          be handled by a separate mechanism.




Massey, et al.           Expires August 29, 2007               [Page 10]

Internet-Draft                    eFIT                     February 2007


       *  In the reactive mode, the router propagates the information
          only to the ingress transit routers that are currently
          communicating with the affected destination users.  For
          example, whenever the router receives a packet destined to the
          other side of a failed link, it sends an ICMP packet back to
          the the ingress transit router in the source provider network.
          This approach has a lower control traffic overhead than the
          proactive mode because it limits the impact to only active
          sources.  On the flip side, it incurs extra delay for the
          first few packets sent to the destination, because the packets
          get dropped and retransmissions will not succeed until the
          notification message is received.  Moreover, it could lead to
          a lot of notification traffic if the egress router does not
          keep track of which ingress routers have received its
          notifications.

       Overall, The tradeoff depends on the scale of the system and
       failure impact.  Proactive notification is more suitable where
       the overhead of propagating updates everywhere is manageable and
       when the destination is very popular.  Reactive notification is
       more suitable when the system is very large and the destination
       has only a few active sources.  Another critical problem is
       security: How does the receiving router trust that the failure
       notification message indeed comes from the egress transit router?
       More research is needed to design an efficient and scalable
       mechanism to handle border link failures.

























Massey, et al.           Expires August 29, 2007               [Page 11]

Internet-Draft                    eFIT                     February 2007


6.  Related Efforts

   The scalability problem of the existing addressing and routing
   architecture has long been recognized.  Over the years a number of
   alternate routing designs have been proposed.  The proposed solutions
   share major goals of scalable support for multihoming and avoiding
   user renumbering when switching providers, and their approaches fall
   into one of the two categories, 1) putting user and provider into
   separate address spaces and 2) encoding location information into IP
   addresses.  Although these designs were not (or have yet to be)
   adopted for deployment, they offer important insights on the reasons
   why they have yet to materialize.

6.1.  Putting users and providers into separate IP address spaces

   Recognizing the fundamental conflict between providers' desire for
   prefix aggregation for routing scalability and user sites' desire for
   provider-independent addresses to ease multihoming and avoid
   renumbering, Hinden & Deering proposed ENCAPS in 1996 ([RFC1955],
   [ENCAPS]).  The basic idea is to separate provider networks and user
   sites into two address spaces, and to use IP-in-IP tunnels to carry
   packets from source user networks over the provider space to reach
   destination user networks.  Our eFIT proposal shares the same
   solution direction with ENCAPS, so is another more recent effort LISP
   [LISP] which sketched out an instantiation of ENCAPS implementation.

   O'Dell made another new routing design, named GSE [GSE], in 1997.
   The basic idea is to divide IPv6's 16-byte address into two parts,
   with the lower N bytes being used for the End System Designator (ESD)
   and local routing, and the higher (16 - N) bytes used for routing
   between providers.  [GSEOverview] provides a comprehensive analysis
   of GSE's pros and cons, as well as the open issues in its
   implementation.

   In essence GSE uses the upper (16-N) bytes of IPv6 address to
   represent the address space in the provider domain, hence GSE shares
   the fundamental idea with ENCAPS in envisioning a network where
   customers and providers live on separate address spaces.  As such it
   also shares with ENCAPS the need for a mapping service.  ENCAPS needs
   this mapping service to map the destination user address to the
   address of the tunnel exit point which should be a router of the
   provider serving the destination user, while GSE needs this mapping
   service to map ESDs to the corresponding upper (16 - N) bytes of IPv6
   addresses.







Massey, et al.           Expires August 29, 2007               [Page 12]

Internet-Draft                    eFIT                     February 2007


6.2.  Location-Based Addressing

   Another way to allocate addresses in an aggregatable manner is to
   base the allocation on locations, which was proposed by Deering in
   early 90's [MetroAddr].  This approach can avoid user renumbering
   when they change providers, as long as they stay in the same
   location.

   More recently a similar proposal, Geo-based addressing [GeoAddr] has
   been made.  Although this proposal has certain differences from
   [MetroAddr], for example encoding latitude and longitude information
   into the address instead of metro-area ID, the two proposals bear
   fundamental similarities.  They are both proposed as one of the ways,
   but not necessarily the only way, to allocate IPv6 addresses, both
   envisioned coexistence of location-based and provider-based
   addresses, and which type to use would be based on the need of
   individual parties.

   However location-based addressing imposes two infeasible conditions
   to the routing system.  First, routing over location-based addresses
   requires that ISPs interconnect at each location.  Second, location-
   based addresses do not reflect interconnectivity among providers to
   enable routing policies.

6.3.  Summary of Previous and Ongoing Efforts

   As time goes, multiple solution development efforts have pointed to
   the same direction of separating user sites and provider networks
   into distinct address spaces in order to solve routing scalability
   problem.  We believe that this is not coincidental, but rather
   showing a convincing sign that the separation is a right way forward.

   We also believe that encoding location information into IP address
   can serve very useful purposes.  However solely location-based
   addressing is problematic as it is unable to support routing
   policies.  We have an ongoing effort which proposes a new address
   structure for the provider address space and utilizes location
   information to facilitate scalable routing and traffic engineering.













Massey, et al.           Expires August 29, 2007               [Page 13]

Internet-Draft                    eFIT                     February 2007


7.  Summary

   In concluding this draft we would like to clarify three important
   points: (1) exactly what need to be separated, (2) the impact on
   existing implementations, and (3) why we believe it is necessary to
   separate ISPs from the user address space in order to solve the
   routing scalability problem.

   As far as the global routing scalability is concerned, the root cause
   of the problem is due to user sites and ISPs live on the same address
   and routing space, while each has goals conflicting with that of the
   other.  Thus our proposed solution calls for a separation of the
   provider and user address spaces.  The IAB workshop report [RAWS]
   identified the same problem, although it phrased the problem as "the
   overloading of IP address semantics".  We would like to clarify that
   the problem is not overloading address and identifier, but
   overloading providers and end users on the same address space.

   There may exist a need for host identifiers.  For example a multi-
   connected host may have multiple IP addresses, one for each of its
   interfaces, and it may desire to move a running TCP connection from
   one interface to another.  This would require a host identifier that
   is independent from IP addresses, such as the one defined by HIP
   [HIP].  However deploying HIP alone is not a solution to the routing
   scalability problem, even though it offers each host an identifier.
   Both provider networks and user sites need IP addresses to manage
   their networks and forward packets.  One can envision a host
   identifier solution being deployed on top of, but not in place of,
   user IP addresses.

   The second point is about the impact of our proposed solution on
   currently deployed systems and protocols. eFIT and similar solutions
   introduce a new component into the Internet architecture, the mapping
   service.  If we design the mapping service right, then by and large
   all user sites and ISPs should be able to stay with their current
   operational practice regarding packet transmission and forwarding,
   with all user sites using provider-independent addresses and all ISPs
   using topologically aggregatable addresses.  The edge routers
   connecting user sites to the transit core will need to be changed to
   use the mapping service and tunnel packets over the transit core.

   The last point we would like to stress is the necessity for deploying
   our proposed solution (or a similar one in the same direction).
   Putting ISPs in a separate IP address space for a scalable global
   routing system requires a new mapping component to bridge the two
   address spaces.  Research efforts are needed to develop a reliable
   and robust mapping service.  This new mapping service will
   necessarily bring additional complexity into the Internet



Massey, et al.           Expires August 29, 2007               [Page 14]

Internet-Draft                    eFIT                     February 2007


   architecture, thus a question naturally arises: why is it necessary
   to change the existing addressing and routing architecture?

   We believe the answer lies in the fact that the Internet has grown by
   orders of magnitude.  The existing address architecture of having all
   the IP boxes living in the same address space was designed at the
   birth of the Internet when it was very small in size.  Today the
   Internet has become the largest cohesive system we have ever built,
   and perhaps the most important infrastructure for the society.
   Different parts of Internet have become specialized to serve
   different purposes, for example user sites are multi-homed for
   enhanced reliability and performance, while service provider networks
   are specialized for high performance, yet economical, packet delivery
   service.  The different goals of different parties brought different
   and conflicting requirements to the shared address space.  Thus the
   original address architecture can no longer meet the functional
   requirements of today's grown up Internet.

   In a 1928 article by J. B. S. Haldane, "being the right size"
   [RIGHTSIZE], the author illustrated the relation between the size and
   complexity of biological entities through a vivid example.  As stated
   in the article, "a typical small animal, say a microscopic worm or
   rotifer, has a smooth skin through which all the oxygen it requires
   can soak in."  However, "increase its dimensions tenfold in every
   direction, and its weight is increased a thousand times, so that if
   it is to use its muscles as efficiently as its miniature counterpart,
   it will need a thousand times as much food and oxygen per day.  Now
   if its shape is unaltered its surface will be increased only a
   hundredfold, and ten times as much oxygen must enter per minute
   through each square millimeter of skin."  That is why all large size
   animals have lung, an organ specialized for soaking oxygen.  The
   author concludes that "for every type of animal there is a most
   convenient size, and a large change in size inevitably carries with
   it a change of form."

   We believe the same is true for Internet.  As it grows large in user
   population size, it is no longer feasible for its transit core to
   deliver packets by maintaining the reachability information of end
   users.  In addition, the transit core is also under competitive
   market forces to maintain a modest cost in carrying out packet
   delivery service.  The growth makes it necessary for the transit core
   to operate in a separate address space than the edge users, so that
   each can evolve independently to fulfill its own role.  We also
   believe that this separation opens the door for adding new functions
   and capabilities to the routing system; we will elaborate in more
   detail in our future documents.

   We would like to solicit the community's input and comments regarding



Massey, et al.           Expires August 29, 2007               [Page 15]

Internet-Draft                    eFIT                     February 2007


   moving the Internet routing and addressing architecture towards this
   proposed direction.  Comments can be sent directly to the authors.

















































Massey, et al.           Expires August 29, 2007               [Page 16]

Internet-Draft                    eFIT                     February 2007


8.  Acknowledgments

   Our efforts on global routing system studies have been supported by
   research fundings from DARPA and NSF.















































Massey, et al.           Expires August 29, 2007               [Page 17]

Internet-Draft                    eFIT                     February 2007


9.  IANA Considerations

   This document requires no actions by IANA.
















































Massey, et al.           Expires August 29, 2007               [Page 18]

Internet-Draft                    eFIT                     February 2007


10.  Security Considerations

   The security of the global routing system is of great concern.  This
   document introduces a proposed solution to routing scalability
   problem.  The proposed solution has a potential to enhance routing
   system security, although the specific design and evaluation are yet
   to be carried out.  The document is informational and it proposes no
   new protocol or protocol usage, and as such presents no new security
   issues.










































Massey, et al.           Expires August 29, 2007               [Page 19]

Internet-Draft                    eFIT                     February 2007


11.  Informative References

   [ENCAPS]   Deering, S., "The Map & Encap Scheme for scalable IPv4
              routing with portable site prefixes",
               http://irl.cs.ucla.edu/references/Deering-encap.pdf,
              March 1996.

   [GSE]      O'Dell, M., "GSE - An Alternate Addressing Architecture
              for IPv6", Internet Draft, http://www.watersprings.org/
              pub/id/draft-ietf-ipngwg-gseaddr-00.txt, 1997.

   [GSEOverview]
              Zhang, L., "An Overview of Multihoming and Open Issues in
              GSE", IETF Journal http://www.isoc.org/tools/blogs/
              ietfjournal/?p=98#more-98, 2006.

   [GeoAddr]  Hain, T., "An IPv6 Provider-Independent Global Unicast
              Address Format", Internet Draft, http://www.ietf.org/
              internet-drafts/draft-hain-ipv6-pi-addr-10.txt,
              August 2006.

   [HIP]      Moskowitz et al., R., "Host Identity Protocol",  http://
              www.ietf.org/internet-drafts/draft-ietf-hip-base-07.txt,
              2007.

   [LISP]     Farinacci, D., Fuller, V., and D. Oran, "Locator/ID
              Separation Protocol (LISP)", Internet Draft, http://
              www.ietf.org/internet-drafts/draft-farinacci-lisp-00.txt,
              2007.

   [MetroAddr]
              Deering, S. and R. Hinden, "IPv6 Metro Addressings",
               http://irl.cs.ucla.edu/references/Deering-metro.txt,
              March 1996.

   [RAWS]     Meyer, D., Zhang, L., and K. Fall, "Report from the IAB
              Workshop on Routing and Addressing", Internet Draft, http:
              //www.ietf.org/internet-drafts/
              draft-iab-raws-report-01.txt, 2007.

   [RFC1955]  Hinden, R., "New Scheme for Internet Routing and
              Addressing (ENCAPS) for IPNG", RFC 1955  , June 1996.

   [RIGHTSIZE]
              Haldane, J., "Being the Right Size",
               http://irl.cs.ucla.edu/papers/right-size.html, 1928.





Massey, et al.           Expires August 29, 2007               [Page 20]

Internet-Draft                    eFIT                     February 2007


Authors' Addresses

   Dan Massey
   Colorado State

   Email: massey@cs.colostate.edu


   Lan Wang
   U. Memphis

   Email: lanwang@memphis.edu


   Beichuan Zhang
   U. Arizona

   Email: bzhang@cs.arizona.edu


   Lixia Zhang
   UCLA

   Email: lixia@cs.ucla.edu



























Massey, et al.           Expires August 29, 2007               [Page 21]

Internet-Draft                    eFIT                     February 2007


Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.


Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Massey, et al.           Expires August 29, 2007               [Page 22]