Network Working Group Juan Jose Adan Internet Draft GISS Expiration Date: April 2007 November 2006 Tunneled Inter-domain Routing (TIDR) draft-adan-idr-tidr-01.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-01.txt November 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Identifiers and Locators in TIDR . . . . . . . . . . . . . . . 3 3. Tunneled Inter-domain Routing . . . . . . . . . . . . . . . . 4 4. Relativity of Identifiers and Locators . . . . . . . . . . . . 5 5. Using TIDR in the Internet . . . . . . . . . . . . . . . . . . 5 5.1. Initial Questions and Primordial Idea . . . . . . . . . . . . 5 5.2. TIDR Basic Mechanism for a Single-Homed Site . . . . . . . . 6 5.3. TIDR Basic Mechanism for a Multi-Homed Site . . . . . . . . . 7 6. Locators of Locators for a Hierarchical Internet: The Onion Model 8 7. TIDR Benefits for the Internet . . . . . . . . . . . . . . . . 9 7.1. Size Reduction of the Global RIB Table . . . . . . . . . . . 9 7.2. Deterministic Customer Traffic Engineering for Incoming Traffic 9 7.3. Numerous Forwarding Decisions for a Particular Address Prefix 9 7.4. TIDR Stops AS Number Space Depletion . . . . . . . . . . . . 9 7.5. Improved BGP Convergence . . . . . . . . . . . . . . . . . . 10 7.6. Protection of the Inter-domain Routing Infrastructure . . . . 10 7.7. Easy Separation of Control Traffic and Transit Traffic . . . 10 7.8. Different Layer-2 Protocol-IDs for Transit and Non-Transit Traffic . . . . . . . . . . . . . . .. . . . . . . . . . . . 10 7.9. Multihoming Resilience . . . . . . . . . . . . . . . . . . . 11 7.10. New Address Families and Tunneling Techniques . . . . . . . 11 7.11. TIDR for IPv4 or IPv6, and Migration to IPv6 . . . . . . . . 11 7.12. Scalability, Stability and Reliability . . . . . . . . . . . 12 7.13. Mobile IP . . . . . . . . . . . . . . . . . . . . . . . . . 12 7.14. Faster Inter-domain Routing. . . . . . . . . . . . . . . . . 12 8. Security Considerations . . . . . . . . . . . . . . . . . . . . 13 8.1. Identifier prefixes authentication . . . . . . . . . . . . . 13 8.2. Locator prefixes authentication . . . . . . . . . . . . . . . 13 8.3. Finer DoS attacks mitigation . . . . . . . . . . . . . . . . 14 9. Futures . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 13. Author's Address . . . . . . . . . . . . . . . . . . . . . . . 15 14. Full Copyright Statement . . . . . . . . . . . . . . . . . . 16 15. Intellectual Property . . . . . . . . . . . . . . . . . . . . 16 J.J. Adan [Page 2] Internet Draft draft-adan-idr-tidr-01.txt November 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 3] Internet Draft draft-adan-idr-tidr-01.txt November 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 4] Internet Draft draft-adan-idr-tidr-01.txt November 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 5] Internet Draft draft-adan-idr-tidr-01.txt November 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 6] Internet Draft draft-adan-idr-tidr-01.txt November 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. Therefore, the BGP best path selection algorithm will have to be modified in the following sense: if a router receives two announcements for prefix X, the first announcement having Locator1 and the second announcement having Locator2, the BGP best path algorithm will work as usual BUT it will have to add both Locator1 and Locator2 to the bestpath. These two locators will be carried within the same LOCATOR attribute, i.e. the LOCATOR attribute permits to announce several locators at the same time, and having different tunneling techniques (GRE, IP-in-IP, MPLS LSP, IPSec, ...). This and the structure of the LOCATOR attribute can be found in [12]. J.J. Adan [Page 7] Internet Draft draft-adan-idr-tidr-01.txt November 2006 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. 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 8] Internet Draft draft-adan-idr-tidr-01.txt November 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 9] Internet Draft draft-adan-idr-tidr-01.txt November 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 respectively. Using different layer-2 protocol-IDs between 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. J.J. Adan [Page 10] Internet Draft draft-adan-idr-tidr-01.txt November 2006 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 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. J.J. Adan [Page 11] Internet Draft draft-adan-idr-tidr-01.txt November 2006 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 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. J.J. Adan [Page 12] Internet Draft draft-adan-idr-tidr-01.txt November 2006 8. Security Considerations In addition to protection of the interdomain routing infrastructure and the separation of transit traffic from control traffic, TIDR can be used to provide additional security mechanisms for the routing information distributed by BGP. Remember that in a TIDR-aware Internet interdomain routing is based only on locators. These are some of the possible mechanisms: 8.1. Identifier prefixes authentication: Each locator included in the LOCATOR attribute structure can be stored together with the digital signature generated by the AS that is originating that specific locator. The originator AS will sign this locator using its private key, and any other AS receiving this locator will check its validity using the public key of the originator AS to determine if the locator is valid or not. The digital signature will authenticate that a specific locator is a valid locator for a particular identifier prefix. And we will say that an identifier prefix is authenticated only when it has at least an authenticated locator. Let's see this with an example: if a TIDR-aware router receives the identifier prefix P=192.0.2.0/24 with a LOCATOR attribute containing locator L=2.2.2.2 and L is originated by AS1, (i.e. AS1 is at the rightmost position of the AS-PATH attribute of the locator prefix announcement), the router will have to check using the public key of AS1 that the digital signature of this locator says that locator L is a valid locator for prefix P. But there is drawback: how do we know that AS1 has the right to employ locator L?. See next paragraph. 8.2. Locator prefixes authentication: Since in a TIDR-aware Internet transit traffic forwarding is based solely on locators it is extremely important to make sure that an ISP is authorized to use a specific locator prefix, and that only the authorised ISP can use it. A possible double-check mechanism to guarantee that locator prefixes are originated by the right AS could be achieved if there were specific IP address ranges for locators in every AS. For example, Class E addresses having 240 as the first octet could be assigned per AS, so that the 16 bits of the AS number are used for second and third octets of the Class E address range. Then, a locator prefix received in an BGP announcement will be valid if its second and third octets together are equal to the AS number of the AS that originated the prefix. Furthermore, to make sure that a locator prefix is really originated by its corresponding AS, this will add a LOCATOR attribute with a null locator in it, and will sign the locator as in the previous section. And an AS will not accept a locator prefix announcement received from a contiguous AS whose AS-PATH shows a different originator than that AS or that it is not duly signed. In the case of an IPv6 locator prefix per AS we could even accommodate 4-byte AS numbers and at the same time provide a great number of locators per AS. J.J. Adan [Page 13] Internet Draft draft-adan-idr-tidr-01.txt November 2006 8.3. Finer DoS attacks mitigation: As we have seen above, with TIDR we can have numerous forwarding decisions for a particular address prefix so that different applications can be treated differently. This permits not only to achieve different interdomain routing results for different applications but also to apply different QoS to them, or to improve the use of blacklists for DoS attack mitigation by selecting the specific application which is causing the problem instead of rejecting all the traffic coming from that IP address. By using FEC-based blackhole routing instead of prefix-based blackhole routing the network can protect legitimate traffic like VoIP traffic during a DoS attack. 9. Futures 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 in 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. 10. IANA Considerations None at this moment. J.J. Adan [Page 14] Internet Draft draft-adan-idr-tidr-01.txt November 2006 11. Acknowledgments 12. 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. 13. 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 15] Internet Draft draft-adan-idr-tidr-01.txt October 2006 14. 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. 15. 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 16]