[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01

Network Working Group                                     Juan Jose Adan
Internet Draft                                                      GISS
Expiration Date: March 2007


                                                            October 2006


                  Tunneled Inter-domain Routing (TIDR)


                      draft-adan-idr-tidr-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.


Abstract

   In this paper we propose a new hierarchical method to enhance
   the current routing and forwarding paradigm for the Internet
   called Tunneled Inter-Domain Routing (TIDR). We will present the
   way in which TIDR permits to establish tunnels to the edge of
   the network, and how they will be used to forward traffic to
   stub networks. These tunnels will be explicitly signaled by
   using a new transitive BGP attribute called LOCATOR. This new
   routing and forwarding paradigm provides, among others, the
   following benefits: global routing table reduction, inter-domain
   routing infrastructure protection, improved multi-homing of edge
   networks, numerous forwarding decisions for a particular address
   prefix, it stops the AS number consumption, and it can be
   smoothly deployed.


J.J. Adan                                                       [Page 1]


Internet Draft          draft-adan-idr-tidr-00.txt          October 2006



1. Introduction

   Routing protocols install all subnet prefixes in the routing table
   in the same manner, without taking into consideration the place
   where these subnets reside within the network. Because of this fact,
   every time there is a change in a stub network the RIB is always
   rebuilt again, thus possibly causing an instability to the routing
   system:

   1) In the Internet, prefixes of a multi-homed non-transit domain,
      i.e. an autonomous system not participating in true inter-domain
      routing, are given the same treatment as the prefixes of a transit
      domain. Irrespective of the type of domain all prefixes are
      installed by BGP [1] in the same global routing table, also known
      as the global routing information base (RIB).

   2) Within a single domain, stub network prefixes are installed by
      interior gateway protocols (IGPs), like OSPF [2] or IS-IS [3],
      in the same routing table (RIB) where they install transit
      networks, whether stub network prefixes are installed as a
      result of a full SPF run or a partial SPF run.

   Tunneled Inter-Domain Routing (TIDR) modifies both the usual routing
   and forwarding processes currently used in IP networks by treating
   stub networks in a different way than transit networks. This special
   treatment is twofold: stub network prefixes will not be installed in
   the RIB; and traffic for stub networks will be sent over tunnels
   established to the edge of the network. We will show how this special
   treatment of stub network prefixes is nothing else but an easy
   solution to the identifier-location split problem, and some of the
   many benefits that such a split provides in terms of scalability,
   stability and the introduction of new routing features.


2. Identifiers and Locators in TIDR

   It is well known that IP addresses are semantically overloaded because
   they carry information on both the location and the identity of a device.
   The need to split these two roles has been discussed many times in many
   different forums with regard to (a) the possible introduction of a new
   hierarchical routing paradigm in the Internet [4] [5] [6], (b) as a way
   to provide scalable site multi-homing [7], or (c) the introduction of a
   new addressing architecture [8], among other benefits.

   Some have pointed out that NAT is the feature that finally breaks the
   semantic overload of the IP address as both a locator and a global
   identifier [9] but what NAT really does is to translate global
   identifiers into another set of identifiers, namely private
   identifiers, which is precisely the reason why the end-to-end principle
   is broken by NAT. TIDR clearly differentiates the use of locators and
   identifiers and does not impede the use of either identifiers or new
   mechanisms for endpoint identification within the applications.


J.J. Adan                                                       [Page 2]


Internet Draft          draft-adan-idr-tidr-00.txt          October 2006



   The split of identifiers and locators in IP routing has failed so far
   because no simple method has been found to associate locators to
   identifiers. The use of tunnels for IP routing according to TIDR permits
   to base routing solely in locators while still providing transport-layer
   survivability between endpoint identifiers. We will show how locators are
   assigned to identifiers in TIDR by means of an in-depth analysis of current
   routing protocols. This analysis will allow us to identify stub networks
   and their possible locators, so as to modify the usual stub network
   installation in the RIB as well as to explain the new forwarding paradigm
   that we will use for them.

   In this paper we will focus on the use of TIDR within the Internet. We
   will show below how TIDR locators are assigned to identifiers by means of
   a new transitive BGP attribute called LOCATOR. This paper sets out some
   of the ideas initially presented in [10]. The use of the TIDR paradigm
   with IGPs will be the focus of a subsequent paper [11].


3. Tunneled Inter-domain Routing

   Do we really need stub networks prefixes for actual IP routing?. TIDR
   permits to send traffic for stub networks over tunnels established to
   the edge of the network. But, where is the edge of a network?. In TIDR,
   the edge of a network will be the place where stub networks are attached.
   And the exact meaning of "stub network" will be relative to the environment
   we are analyzing: the Internet or an enterprise domain.

   TIDR proposes a new method that current routing protocols will use to
   manage stub networks. In TIDR stub networks will not be installed in the
   RIB, as usual, but in a new table called Tunnel Information Base (TIB).
   Afterwards, when routing a packet to the destination prefix, the TIB will
   be searched first to perform tunnel imposition, and secondly the RIB for
   actual routing. After the edge router performs tunnel imposition, all
   routers in the middle will route this packet until the router being the
   tail-end of the tunnel.

   All we need is to find a way for a router to tell it is able to receive
   tunneled traffic for a given prefix. For that purpose we will analyze
   current routing protocols to find out what information can be used as a
   locator for a specific stub network. Once we find a possible locator then
   we will be able to send tunneled traffic for that stub network, provided
   that both the router performing tunnel imposition and the router receiving
   the tunneled packet are TIDR-aware. Therefore, the receiving router, in
   addition to the IP address of the tunnel destination (locator), will have
   to tell the types of encapsulations it supports for a particular prefix,
   and the router performing tunnel imposition will have to support that
   specific encapsulation method, a multipoint GRE tunnel for instance.







J.J. Adan                                                       [Page 3]


Internet Draft          draft-adan-idr-tidr-00.txt          October 2006


4. Relativity of Identifiers and Locators

   As we have already mentioned, IP addresses are semantically overloaded
   because they provide information on the location where a device is and on
   the identity of the endpoint. TIDR permits to split both functions very
   smoothly because a normal IP address will become identifier or locator
   depending on the way we will use it: it will become just a mere endpoint
   identifier as long as there exists a locator to which we can tunnel its
   traffic. And similarly, a normal IP address will become a locator whenever
   it is used as a tunnel destination. This does not mean that this IP works
   as a locator only, but it means that it will work as a locator in TIDR
   routing (i.e. it will be in the RIB). Then, the role of an IP address as an
   identifier or as a locator is relative to the use we decide to do with it.


5. Using TIDR in the Internet

5.1. Initial Questions and Primordial Idea.

   Why do we need to assign a public autonomous system number (AS) to
   non-transit multi-homed domains when the fact is that they do not
   participate in inter-domain routing?. Do we really need the prefixes
   residing within non-transit multi-homed domains for inter-domain routing
   when they are beyond the inter-domain routing infrastructure?. We will
   show how TIDR allow us to get rid of these two needs.

   Let´s start by looking at the AS_Path attribute received in the BGP
   advertisement for one of these customer prefixes: if the right-most AS in
   the path would be able to accept tunneled traffic for each and every prefix
   originated by that AS, then we could move all of these prefixes from the
   global RIB to the TIB. All we need is to assign an IP address to that AS
   for using it as the tunnel destination for all the traffic sent to that AS.

   This IP could be formed using a spare /8 prefix and the AS number for second
   and third octets, and it would be used as an anycast address assigned to a
   tunnel interface in every border router. Obviously, this IP address would
   have to be stored in the global RIB. This approach would permit to reduce the
   global RIB size but it would not provide new features to the inter-domain
   routing system.

   Let´s continue to look at the AS_Path attribute: if the penultimate AS in the
   path would be able to accept tunneled traffic for that prefix then we could
   again move the prefix from the RIB to the TIB. But the penultimate AS-es in
   the AS_Path of all the BGP updates received for a customer prefix turn to be
   the upstream providers for the customer AS. This second approach, in addition
   to reduce the size of the global RIB, will provide new features as we will
   show below.

   Therefore we need to find a way for the provider AS to tell it is able to
   receive tunneled traffic for a given customer prefix. For that purpose we
   will use a new transitive BGP attribute that we will call LOCATOR and that
   the transit AS will add to the announcement of the customer prefix. The



J.J. Adan                                                       [Page 4]


Internet Draft          draft-adan-idr-tidr-00.txt          October 2006


   LOCATOR attribute will contain, among other things, the IP address of the
   tunnel destination (i.e. the locator) as well as the types of encapsulations
   it supports for a particular prefix. This tunnel could be for instance a
   multipoint GRE tunnel.

   To better understand the way TIDR works for inter-domain routing we will
   explain roughly this mechanism for a single-homed site to get the basic idea,
   and later we will extend the explanation for a multi-homed site.


5.2. TIDR Basic Mechanism for a Single-Homed Site.

   Let´s consider a site single-homed to upstream provider ISP1 that uses a
   provider-independent prefix, what implies its presence in the BGP global RIB.
   Let´s suppose now that ISP1 is TIDR-aware, which means it will advertise the
   prefix using a new transitive BGP attribute called LOCATOR to tell other
   autonomous systems that ISP1 is willing to receive traffic for its customer
   using a specific tunnel encapsulation.

   When this BGP announcement arrives to the routers of the TIDR-aware ISP2,
   they will install the prefix in the RIB as usual, but they will also install
   the prefix in the TIB. Later, when one of these routers receives a packet for
   the single-homed site it will check the TIB before the RIB and, since it will
   get a match, it will encapsulate the IP packet according to the tunnel
   encapsulation that ISP1 specified in the LOCATOR attribute and that was
   stored in the TIB. Any ISP in the path from ISP2 to ISP1 will only have to
   look up ISP1 prefixes to route the packet towards ISP1. Upon receipt of the
   encapsulated packet, ISP1 will extract the original IP packet and deliver it
   to the single-homed site.

   When all autonomous systems in the Internet are TIDR-aware the final result
   is that all routers having full-routing will have the customer prefix both in
   the RIB and the TIB. When a new packet is sent to the customer only the first
   TIDR-aware router will have to look up the TIB+RIB whereas the rest of the
   transit routers will only have to look up the RIB. In other words, the router
   performing tunnel imposition will use the TIB+RIB, and the others will use
   the RIB.

   Therefore, in a TIDR-aware Internet, we just need to store the single-homed
   site prefixes in the TIB of the edge routers, i.e. ISP routers connecting to
   the customers. And we no longer need to store them in the TIB of transit
   routers. So, we have just moved prefixes from the global RIB to the global
   TIB, thus reducing the size of the global RIB. And, since only edge routers
   perform tunnel imposition using the TIB, this table is not necessary for pure
   transit routers.

   In summary: (1) prefixes announced with a LOCATOR attribute will become pure
   endpoint identifier prefixes in terms of inter-domain routing because they
   will not be needed for inter-domain routing, and they will be stored in the
   TIB; and (2) inter-domain routing will be only based on the locator prefixes
   stored in the RIB that TIDR-aware ISPs assigned to the customer prefixes by
   means of the LOCATOR attribute.

   In short, the TIB is for identifiers and the RIB for locators.

J.J. Adan                                                       [Page 5]


Internet Draft          draft-adan-idr-tidr-00.txt          October 2006



5.3. TIDR Basic Mechanism for a Multi-Homed Site.

   Let´s consider now a site multi-homed to two TIDR-aware ISPs, ISP1 and ISP2.
   Whether this customer uses a provider-independent or provider-assigned prefix
   both ISP1 and ISP2 will have to announce the prefix to the rest of the
   Internet. But now, since they are TIDR-aware, they will advertise the
   customer prefix adding the LOCATOR attribute. ISP1 advertisement will have a
   LOCATOR attribute pointing to an ISP1 tunnel interface, and ISP2
   advertisement will have a LOCATOR pointing to an ISP2 tunnel interface. Even
   more, each LOCATOR will include in a field called REMOTE-PREFERENCE the
   preference that the customer wants to assign to each specific advertisement.
   How the customer will specify this is not considered in this document, but a
   simple method would be to run BGP with a private AS number and send specific
   communities that ISP1 and ISP2 would map to specific REMOTE-PREFERENCE
   values.

   When these two BGP announcements arrive to the routers of the TIDR-aware ISP3
   they will install the prefix in the RIB as usual, but they will also install
   the prefix in the TIB. Later, when one of these routers receives a packet for
   the multi-homed site it will check the TIB before the RIB and it will find
   two locators. By comparing the REMOTE-PREFERENCE of the two locators it will
   choose the best locator and will encapsulate the packet according to the
   information stored in the TIB. Let´s suppose that ISP1 sent the LOCATOR
   having the highest REMOTE-PREFERENCE. Then, any ISP in the path from ISP3 to
   ISP1 will only have to look up ISP1 prefixes to route the packet towards
   ISP1.

   As in the single-homed case, in a TIDR-aware Internet we just need to store
   the multi-homed site prefixes in the TIB of the edge routers, i.e. ISP
   routers connecting to the customers. And we no longer need to store them in
   the TIB of transit routers. So, we have just moved prefixes from the global
   RIB to the TIB. But in the multi-homed case, TIDR provides an additional
   benefit, namely that the customer will be able to specify through which of
   its ISPs wants to receive incoming traffic for a specific prefix.

   To avoid that only one of the locators arrives to ISP3 because of the effect
   of the BGP best path selection algorithm somewhere in the path, we will need
   to slightly modify this algorithm so that a TIDR-aware router will include in
   the announcement of the best path all the locators that were present in the
   updates that it used to determine the best path. This and the structure of
   the LOCATOR attribute can be found in [12].


6. Locators of Locators for a Hierarchical Internet: The Onion Model

   If by using TIDR locators we can reduce the size of the global inter-domain
   routing table, couldn´t we apply the same idea again to assign also locators
   to locator prefixes and obtain this way a hierarchy of locators?. Let´s
   consider a customer network multi-homed to two different regional ISPs (ISP1
   and ISP2). ISP1 is, in turn, multi-homed to two transit providers ISP-101 and
   ISP-102. ISP1 will generate identifier prefixes for its customers´ prefixes
   and will generate locator prefixes to announce its TIDR tunnel destinations.


J.J. Adan                                                       [Page 6]


Internet Draft          draft-adan-idr-tidr-00.txt          October 2006



   Let´s suppose now that ISP-101 supports hierarchical TIDR (H-TIDR), which
   means that ISP-101 will assign new locators to the locator prefix that ISP1
   announced to the Internet. The LOCATOR attribute for this locator prefix will
   now contain as tunnel destination an IP address of ISP-101, and the LOCATOR
   attribute will mark this new locator as a level-2 locator. When this BGP
   announcement arrives to a level-2 aware AS, it will not install the locator
   prefix in the TIB as with any identifier locator but it will install the
   locator prefix in the RIB and it will mark it to know that a level-2 locator
   is available for it. This level-2 locator will be installed in a new table
   called RIB-2. Later, when ISP-101 receives traffic which is tunneled with the
   level-1 locator it will perform either a second tunnel imposition using the
   level-2 locator (telescoping) or even it could swap the incoming level-1
   tunnel encapsulation with a new level-2 tunnel encapsulation (tunnel
   swapping).

   If ISP-102 doesn´t support level-2 locators it will not add any locator to
   the locator prefix it receives from ISP1 nor will it use the locator that
   ISP-101 added. It will just install the locator prefix in the RIB and ignore
   the level-2 locator included in the LOCATOR attribute received.

   In the case of telescoping the second tunnel could even use a different
   tunneling technique than the one used for the level-1 locator. Traffic
   entering the core level-2 domain could be encapsulated using a tunneling
   technique not available for instance in the core level-1 domain. As an
   example, there could be a level-2 domain in which all the AS-es exchange MPLS
   labels between them in some way, so that traffic coming from the core level-1
   domain would be forwarded using MPLS label switching within the core level-2
   domain.

   In the case of tunnel swapping both incoming and outgoing packets will need
   to have the same tunneling encapsulation for the receiver AS to be able to
   detunnel the packet, unless it supports more than one type of encapsulation.

   In summary, hierarchical TIDR would permit: (1) a new global structure for
   the Internet, an onion model for a hierarchical Internet based on levels so
   that all providers in level N will have to perform core level-N routing using
   the level-N locators stored in the RIB-N table; (2) new possibilities for
   inter-domain routing can be devised, either based on tunnel stacking
   (telescoping) or tunnel swapping, two mechanisms that will have to be further
   investigated; (3) a more consistent classification of providers based on the
   levels of core routing they support, different from the current
   classification of tier-1, tier-2 and tier-3 providers; and (4) new types of
   transit and peering relationships between providers and customers.











J.J. Adan                                                       [Page 7]


Internet Draft          draft-adan-idr-tidr-00.txt          October 2006



7. TIDR Benefits for the Internet

   Let´s briefly list the benefits that TIDR would provide to the Internet
   global routing system [10]:


7.1. Size Reduction of the Global RIB Table

   TIDR reduces the size of the global RIB because in a full TIDR-aware Internet
   only locator prefixes will be stored in the RIB, which is the table that is
   actually used for inter-domain routing.


7.2. Deterministic Customer Traffic Engineering for Incoming Traffic

   Traffic engineering for the incoming traffic can be hardly achieved in
   practice by using AS-PATH prepending or limiting the scope of outgoing
   announcements. As it was shown above, TIDR permit customers to specify in a
   deterministic way the path that incoming traffic will take for a specific
   prefix by means of the REMOTE-PREFERENCE. Although the sending AS will use
   LOCAL-PREFERENCE to decide which outgoing path the tunneled traffic will
   take, by selecting the locator with the highest REMOTE-PREFERENCE for
   tunneling, we will get the receiving AS to receive that traffic through the
   desired incoming path.


7.3. Numerous Forwarding Decisions for a Particular Address Prefix

   In TIDR identifier prefixes, which are stored in the TIB, are not used for
   routing but only for tunnel imposition. To have numerous forwarding decisions
   for an address prefix the only thing we need is to enrich the type of objects
   that we can store in the TIB. Let´s define for this purpose two new address
   families: FECv4 for IPv4 forwarding equivalence classes, and FECv6 for IPv6
   forwarding equivalence classes. A FECv4 or FECv6 object will be made up of a
   range of IP addresses, a range of transport protocols, and a range of ports
   basically. For example, a FECv4 object could be: IP=192.0.2.1, protocol=TCP,
   port=80; and a second FECv4 object could be: IP=192.0.2.1, protocol=UDP,
   ports=(16384-32767). To get BGP to distribute these new NLRI types we will
   need to assign new AFI-SAFI combinations for FECv4 and FECv6 NLRIs
   respectively. Finally, by assigning different locators to these two objects
   we will get different inter-domain routing for them so that, for instance,
   HTTP traffic and VoIP traffic will be received via different providers, or to
   apply different QoS policies to them.


7.4. TIDR Stops AS Number Space Depletion.

   With TIDR we can devise a situation in which a customer network will be able
   to control its routing policy without using a public AS number but a private
   AS number. Let´s see how.




J.J. Adan                                                       [Page 8]


Internet Draft          draft-adan-idr-tidr-00.txt          October 2006



   In the current Internet, the reason why a non-transit multi-homed AS needs to
   run BGP using a public AS number is twofold. Firstly to exchange routing
   information with its providers so as to learn external routes and to announce
   its own prefixes. And secondly to be able to manipulate BGP attributes. The
   aim is to carry out a specific inter-domain routing policy so that the multi-
   homed site can decide which exit outgoing traffic to a certain target will
   take, and to try to influence in the entry point that incoming traffic will
   use.

   First goal can also be achieved if the customer network runs BGP using a
   private AS number with its providers. Once the customer receives the external
   routes from its providers, it will be able to set the right LOCAL-PREFERENCE
   values to select the path for outgoing  traffic. The problem with using a
   private AS number comes from the fact that the customer will not be able to
   influence on the path that incoming traffic will take. But in TIDR there is a
   deterministic way to select this: the customer routers will send specific BGP
   communities to its providers which they will use to set concrete values to
   the REMOTE-PREFERENCE in the LOCATOR attribute that they will send to the
   Internet.


7.5. Improved BGP Convergence

   Improved BGP convergence speed because of (1) a smaller global RIB; and
   (2) shorter AS_Paths, the latter being a consequence of the previous point.


7.6. Protection of the Inter-domain Routing Infrastructure:

   Inter-domain routing in the TIDR paradigm is based on locators that identify
   tunnel destinations so that traffic from customer networks is tunneled as it
   enters the inter-domain infrastructure. As a consequence, customer traffic
   directly sent to a TIDR locator should be discarded so as to protect TIDR
   tunnel destinations.


7.7. Easy Separation of Control Traffic and Transit Traffic

   Transit traffic will be received as tunneled traffic whereas control traffic
   will not be tunneled. This fact permits for instance to apply different rate
   limiting techniques to control traffic than to transit traffic. And since we
   can assign different locators to different identifier prefixes we will be
   able to apply different QoS features to the different sent/received traffics.


7.8. Different Layer-2 Protocol-IDs for Transit and Non-Transit Traffic.

   A further security mechanism to differentiate transit from control traffic
   could be the utilization of two different layer-2 protocol-IDs for tunneled
   and non-tunneled traffic. Using different layer-2 protocol-IDs between




J.J. Adan                                                       [Page 9]


Internet Draft          draft-adan-idr-tidr-00.txt          October 2006



   adjacent routers we can also optimise packet switching because traffic
   received with a specific layer-2 protocol-ID will be switched using its
   corresponding table: the RIB for tunneled traffic, and the TIB+RIB for non-
   tunneled traffic and control traffic.


7.9. Multihoming Resilience

   Let´s suppose that a customer network is multi-homed to two different
   upstream providers ISP1 and ISP2 which announce the customer prefix
   192.0.2.0/24 with locators L1 and L2 respectively. Let´s also suppose that L1
   has a higher REMOTE-PREFERENCE than L2. Therefore, a remote AS will be using
   locator L1 to send tunneled traffic to hosts covered by the aforementioned
   prefix. If for some reason the customer network looses connectivity with
   ISP1, ISP1 will detect the loose of connectivity and, after some specific
   time, will send a BGP update to remove locator L1 from the global TIB. In the
   meantime, ISP1 may continue to receive tunneled traffic for its customer but,
   instead of dropping these packets, ISP1 will first detunnel the traffic and
   then perform a new tunnel imposition using the locator L2 that ISP2 announced
   to the Internet.


7.10. New Address Families and Tunneling Techniques

   The separation between identifiers and locators according to  TIDR also
   allows us to use different address families for them. We will be able for
   example to use IPv6 for identifiers while still  keeping IPv4 for locators.
   Even more, since in TIDR inter-domain routing is based only on locators we
   could use several address families for identifiers simultaneously. This
   result in not very surprising because it is well known that some tunneling
   techniques (like GRE or MPLS) are multiprotocol.

   And we can use several encapsulations at the same time with a tunnel endpoint
   (locator). As it was mentioned above, within the LOCATOR structure it is
   specified the various types of tunneling techniques that we can use for a
   specific tunnel destination, GRE or IP-in-IP for instance, and both could be
   used with the same locator.

   By decoupling locators addressing from identifiers addressing TIDR leaves
   open the possibility of using either new encapsulation techniques as soon as
   they are available, or any existing encapsulation technique once it is found
   the way to integrate its use within TIDR. Lastly, in a hierarchical multi-
   level core Internet different technologies could be deployed so that
   technologies which are available at one level are not available or
   appropriate for other levels.


7.11. TIDR for IPv4 or IPv6, and Migration to IPv6

   What we have presented on TIDR is valid for both IPv4 and IPv6. TIDR permits
   easily to transport IPv6 traffic over the current IPv4 infrastructure, and
   viceversa. For example, IPv6 identifier prefix 2001:DB8::/32 could be


J.J. Adan                                                      [Page 10]


Internet Draft          draft-adan-idr-tidr-00.txt          October 2006



   assigned an IPv4 locator Lv4=2.2.2.2, and the IPv4 identifier prefix
   192.0.2.0/24 could be assigned an IPv6 locator Lv6=2000::1. Furthermore,
   there is no problem in assigning at the same time IPv4 and IPv6 locators to
   the same prefix so that different AS-es use the locator they want: in the
   migration to IPv6 there may be AS-es running IPv6 in their backbone whereas
   some others continue to use IPv4.

   TIDR tunnels provide an easy transport of IPv6 over an IPv4 infrastructure,
   and there is no need for renumbering when a site is multihomed to a new
   different provider: the change will only affect to the TIB, whereas the RIB
   will remain the same thus not affecting at all to the interdomain routing
   system.


7.12. Scalability, Stability and Reliability

   We have already shown (1) how changes in the customer prefixes will only
   affect the TIB, not the RIB, so that the interdomain routing system will not
   be affected by customer prefixes instabilities, and (2) how TIDR could be
   further employed to establish a hierarchical Internet with different levels
   of locators in the core routing domain. The former is based on moving
   prefixes from the RIB to the TIB, while the  latter moves locators from the
   RIB to the RIB-2 and so on. This results in a enormous increase of the
   scalability and stability of the global routing system which will based on a
   set of tables TIB (=RIB-0), RIB, RIB-2, etc. whose scalability and stability
   are independent of each other. And, in the same way that the interdomain
   routing system based on level-1 locators will not be affected by identifier
   prefixes instabilities, the core level-2 locators will not be affected by
   level-1 locators instabilities.

   Moreover, if we use anycast locators, i.e. we configure the same tunnel
   endpoints in several routers, a higher reliability is endowed for the global
   routing system so that transit traffic which is tunneled to a specific
   locator will continue to be  dispatched in the event of a failure in one of
   the routers having that tunnel endpoint defined.


7.13. Mobile IP

   TIDR tunneling can be also used for mobile IP. The mobile node (MN) will be
   assigned a locator by its home agent (HA) and as soon as it moves to a
   foreign network the HA will authorize the foreign agent (FA) to issue a new
   locator that will permit the FA to receive tunneled traffic for the MN.


7.14. Faster Inter-domain Routing

   Although the use of TIDR tunnels has also its drawbacks, e.g. original
   packets are increased in size as they enter the interdomain routing
   infrastructure, since the size of the global table will be smaller we will




J.J. Adan                                                      [Page 11]


Internet Draft          draft-adan-idr-tidr-00.txt          October 2006



   get firstly a destination IP address lookup much faster, and in a second
   place a simplification of unicast reverse path forwarding (RPF) checking.
   Some companies have developed special linecards to process big amounts of GRE
   tunnels in hardware and routers with hard disk will be able to accommodate
   big TIB tables where the interdomain routing policy for identifier prefixes
   will be stored.



8. Closing

   The clear separation between identifiers and locators that TIDR introduces
   allows us to divide the whole internetwork in three routing domains: (i) Core
   Routing Domains which use  locators stored in the RIBs; (ii) Peripheral
   Routing Domains which use the identifiers; and (iii) Private Routing Domains
   which are behind NAT devices. This separation can be again used within each
   of these domains.

   When BGP-4 was first introduced in the Internet back in 1994 there were less
   than 20,000 routes in the global RIB. Today this number is close to reach
   200,000, so roughly speaking it has increased ten-fold. During these 12 years
   CPUs processing power, computer memory sizes and link capacities have
   increased more than that. It is well known that if we want to have better
   routing services int the Internet we will have to distribute much more policy
   information for both routing and signaling. Although some of this information
   could be stored in data repositories (like the DNS, or HTTP or Radius
   servers), we have shown how TIDR allows us to store this inter-domain routing
   policy information in new tables that BGP will manage.

   TIDR defines a new tunnel-based mechanism that permits to smoothly deploy a
   new routing paradigm in the Internet and in an incremental way. By using a
   new transitive BGP attribute called LOCATOR we can distribute new routing
   objects that will provide many benefits to the global routing system in terms
   of scalability, stability, resilience, quality of service, traffic
   engineering and security.

   Maybe in the future we will be able to move some of these functions beyond
   the edge of the interdomain infrastructure, storing some of this information
   in a big data repository like the DNS so that hosts, after performing name
   resolution, will also query the repository for tunnel resolution so as to
   perform tunnel imposition by themselves.













J.J. Adan                                                      [Page 12]


Internet Draft          draft-adan-idr-tidr-00.txt          October 2006



10. References

[1] Y. Rekhter and T. Li, S. Hares (Eds) , "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January  2006.

[2] J. Moy, "OSPF Version 2", RFC 2328, April 1998.

[3] R. Callon, "Use of OSI IS-IS for Routing in TCP/IP and Dual Environments", RFC 1195, December 1990.

[4] P. Gross, P. Almquist, "IESG Deliberations on Routing and Addressing", RFC 1380, November 1992.

[5] I. Castineyra, N. Chiappa, M. Steenstrup, "The Nimrod Routing Architecture", RFC 1992, August 1996.

[6] G. Huston, "Commentary on Inter-Domain Internet", RFC 3221, December 2001.

[7] IETF 57th, MULTI6 WG Meetings, Vienna (Austria), July 2003.

[8] A. Doria, E. Davies, F. Kastenholz (Eds), "Requirements for Inter-Domain Routing", draft-irtf-routing-reqs-03.txt, July 2004.

[9] T. Hain, "Architectural Implications of NAT", RFC 2993, November 2000.

[10] J.J. Adán Luengo: "Tunneled Inter-domain Routing (TIDR): A Proposal for a New Internet Routing Paradigm", M-007465/2005, September 2005. Unpublished.

[11] J.J. Adán Luengo: "Using Tunneled Inter-Domain Routing (TIDR) with IGPs. A New Routing and Forwarding Architecture for IP Networks". Work in progress.

[12] J.J. Adán Luengo, "TIDR - The LOCATORS Attribute", work in progress.



11. Author's Address

      Juan Jose Adan
      Gerencia de Informatica de la Seguridad Social (GISS)
      c/ Doctor Tolosa Latour s/n
      E-28041 Madrid, Spain
      Email: juan-jose.adan@giss.seg-social.es












J.J. Adan                                                      [Page 13]


Internet Draft          draft-adan-idr-tidr-00.txt          October 2006



12. Full Copyright Statement

   Copyright (C) The Internet Society (2006).

   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 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.


13. 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.













J.J. Adan                                                      [Page 14]


Html markup produced by rfcmarkup 1.123, available from https://tools.ietf.org/tools/rfcmarkup/