idnits 2.17.1 draft-ietf-idr-aggregation-tutorial-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-27) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 25 instances of too long lines in the document, the longest one being 2 characters in excess of 72. == There are 18 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 1997) is 9783 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 1519 (ref. '3') (Obsoleted by RFC 4632) ** Downref: Normative reference to an Historic RFC: RFC 1518 (ref. '4') ** Obsolete normative reference: RFC 1771 (ref. '5') (Obsoleted by RFC 4271) ** Downref: Normative reference to an Informational RFC: RFC 2071 (ref. '6') ** Obsolete normative reference: RFC 1971 (ref. '8') (Obsoleted by RFC 2462) Summary: 15 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT John W. Stewart, III / ISI 3 Enke Chen / Cisco 4 July 1997 6 Route Aggregation Tutorial 7 9 Status of this Memo 11 This document is an Internet-Draft. Internet-Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its areas, 13 and its working groups. Note that other groups may also distribute 14 working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six 17 months. Internet-Drafts may be updated, replaced or obsoleted by 18 other documents at any time. It is not appropriate to use Internet- 19 Drafts as reference material or to cite them other than as a "working 20 draft" or "work in progress." 22 Please check the abstract listing contained in each Internet-Draft 23 directory to learn the current status of this or any other Internet- 24 Draft. 26 Abstract 28 Route aggregation is critical to the long-term viability of the 29 Internet. This document presents practical information that network 30 managers can use to both understand the concepts of aggregation as 31 well as put those concepts into use in order to do their part to make 32 the Internet stable and allow its continued growth. The intended 33 audience for this document is anyone responsible for configuring a 34 network which has its own Autonomous System Number (ASN) and 35 exchanges routing information with its Internet Service Provider(s) 36 (ISP(s)) using the Border Gateway Protocol (BGP). This document does 37 not cover multi-homing, though multi-homed sites can still benefit 38 from understanding this material. 40 1. Introduction 42 The long-term viability of the Internet depends on its ability to 43 support the continued growth in demand. A large part of its ability 44 to grow is dependent on the successful scaling of the routing system. 45 Because the complexity of the Internet's routing system is a function 46 of the number of reachable destinations, great care must be taken 47 that, as the net grows, the demands on the routing system don't 48 outpace advances in hardware and software. 50 In the early 1990s, the paradigm for large scale Internet routing 51 changed from a "Classful" system to a "Classless" system. The 52 Classless system applies techniques of hierarchy to achieve large 53 scaling. In order for Classless routing to achieve its goal of 54 allowing the routing system to scale very well, networks in all areas 55 of the Internet must be vigilant about "route aggregation." This 56 document provides educational information, both conceptual and 57 practical, in an effort to encourage efficient aggregation throughout 58 the Internet. 60 2. Network Classes and the Bit-Level Detail 62 As originally specified in the early 1980s, the Internet Protocol 63 (IP) included the idea of network "Classes." [1] In IP, a certain 64 number of bits in the 32-bit addresses refer to the network and the 65 remainder of the bits refer to a host on that network. (In the mid 66 1980s IP was extended such that part of the host bits can refer to a 67 subnet and the remainder would refer to a host on that subnet. [2]) 68 The point of the different Classes was to have addresses with 69 different numbers of network/host bits. The Class of an address 70 could be determined by the high-order bits. A Class A address had 71 "0" as the high-order bit, and then 7 bits of network and 24 bits of 72 host; a Class B address had "10" as the high-order two bits, and then 73 14 bits of network and 16 bits of host; and a Class C address had 74 "110" as the high-order three bits and then 21 bits of network and 8 75 bits of host. Looking at an address in "dotted quad notation" (e.g., 76 166.45.3.46), Class A networks have a first number of 0-127, Class B 77 networks have a first number of 128-191 and Class C networks have a 78 first number of 192-223. A Class A network could number 1.7 million 79 hosts, a Class B 65,000 and a Class C 256. Diagramatically: 81 3 3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1 82 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 83 Class +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 84 A |0 | 85 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 86 |<--network-->|<---------------------host-------------------->| 88 3 3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1 89 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 90 Class +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 91 B |1 0 | 92 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 93 |<---------network--------->|<-------------host------------>| 95 3 3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1 96 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 97 Class +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 98 C |1 1 0 | 99 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 100 |<----------------network---------------->|<-----host---->| 102 Although the original intent of having Classes was to allow for 103 flexible addressing, experience showed that the hard boundary of the 104 three Classes actually made the addressing less flexible. For 105 example, if a site connecting to the Internet needed to address 300 106 hosts, then a Class C network wouldn't be adequate and a Class B 107 would need to be assigned. This resulted in poor utilization of the 108 assigned address space and caused a faster-than-necessary rate of 109 consumption of the available IP address space. 111 Another problem with the scalability of Internet routing under the 112 Classful system had to do with the address allocation policies used. 113 At that time, when a site connected to the Internet, it would go to a 114 central registry to get a unique IP network and then it would go to 115 an ISP to procure connectivity. What this means is that if an ISP 116 had 1000 customers, each of whom had been assigned a Classful network 117 of some type, then that ISP would have to announce each of those 1000 118 networks to other providers in the Internet. In other words, the 119 Internet's routing system was not taking advantage of the inherent 120 provider/subscriber hierarchy and instead was being "flat-routed." 122 3. The Introduction of CIDR 124 In the early 1990s, a number of ISPs began to have operational 125 problems related to the size of a full Internet routing table because 126 of the limited amount of memory available in commercial routers. (A 127 "full routing table" means a routing table which does not contain a 128 default route and instead contains an entry for every active network 129 in the Internet.) Because of these problems, Classless Inter-Domain 130 Routing (CIDR) was created. [3] 132 CIDR removed the idea of Classes from IP. Instead of having networks 133 with an implied number of bits referring to network/host, there are 134 "prefixes" with an associated mask explicitly identifying which bits 135 refer to network/host. For example, the prefix "38.245.76.0" with a 136 mask of "255.255.255.0" has 24 bits of network and 8 bits of host 137 (i.e., it can address the same number of hosts as a Class C network 138 even though the prefix is in the Class A range). The CIDR paradigm 139 prefers the term "prefix" over "network" because it's more clear that 140 no Class is being implied. Another way to write this example prefix 141 is "38.245.76.0/24", meaning that the mask contains 24 1s in the 142 high-order portion of the mask. 144 The strength of CIDR is that the masks can be on arbitrary bit 145 boundaries and don't have to be on byte boundaries. So for example, 146 going back to the case of the site which needs to address 300 hosts, 147 the site could be allocated a "/23" (i.e., a prefix which has 23 bits 148 for network and 9 bits for host, thus allowing 512 hosts to be 149 addressed with the single prefix). 151 To complete the picture, in order for CIDR to actually help achieve 152 better scaling of Internet routing, a specific address allocation 153 architecture must be used. [4] Rather than the pre-CIDR style where 154 sites would go to a centralized registry to get an address which does 155 not take into account where that site connects to the Internet, 156 CIDR-style address allocation involves registries allocating address 157 space to ISPs who, in turn, sub-allocate it to their customers. So 158 for example, a registry might allocate the prefix 204.71.0.0/16 159 (called a "CIDR block") to ISP1, and then ISP1 could sub-allocate 160 204.71.1.0/24 to SmallCustomer1, 204.71.2.0/24 to SmallCustomer2, 161 204.71.128.0/22 to MediumCustomer and 204.71.136.0/20 to 162 LargeCustomer. The benefit, then, is that when ISP1 exchanges 163 routing information with other ISPs, it only needs to announce the 164 single prefix 204.71.0.0/16 and not each of the individual prefixes 165 used by its customers. The ability to merge multiple prefixes which 166 have some number of leading bits in common is called "aggregation." 168 In 1993, the deployment of a routing protocol which supported CIDR 169 (specifically BGP Version 4 [5]) had an immediate and measurably 170 positive effect on route scaling. Immediately after its deployment a 171 full routing table went down in size in absolute numbers (this was 172 possible only because address allocation had already been done for 173 some time in the CIDR style even though the routing hadn't yet taken 174 advantage of it) and, more importantly, the rate of growth was 175 slowed. 177 4. A Note on Renumbering 179 The crux of CIDR is that the Internet's generally hierarchical 180 topology is being reflected in the addressing. As a result, if a 181 site started out as a customer of ISP1 and is thus numbered out of 182 one of ISP1's CIDR blocks, but then that site terminates the 183 relationship with ISP1 and "rehomes" to ISP2, then the site would 184 need to renumber its nodes to be part of one of ISP2's CIDR blocks. 185 The major reason for this is to retain efficiency in the routing 186 system. [6] 188 Renumbering is an unfortunate necessity in the current IPv4 Internet. 189 This is the reason for the recent advance of renumbering technology 190 in IPv4 (e.g., DHCP [7]) as well as the focus of easy renumbering in 191 IPv6. [8] Sites should keep this "unfortunate necessity" in mind 192 when deploying equipment to make sure that their infrastructure can 193 be renumbered easily if that becomes necessary. 195 5. Practical Aggregation 197 As stated earlier, aggregation refers to the combining of multiple 198 contiguous prefixes into a single prefix. For example, assume the 199 prefixes 209.123.10.0/24 and 209.123.11.0/24. The binary 200 representation for 209.123.10.0/24 is: 202 3 3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1 203 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 |1 1 0 1 0 0 0 1 0 1 1 1 1 0 1 1 0 0 0 0 1 0 1 0 0 0 0 0 0 0 0 0| 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 |<---- 209 ---->|<---- 123 ---->|<---- 10 ---->|<---- 0 ---->| 209 And the binary representation for 209.123.9.0/24 is 211 3 3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1 212 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 214 |1 1 0 1 0 0 0 1 0 1 1 1 1 0 1 1 0 0 0 0 1 0 1 1 0 0 0 0 0 0 0 0| 215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 216 |<---- 209 ---->|<---- 123 ---->|<---- 11 ---->|<---- 0 ---->| 218 The important thing to note here is that the two networks can be 219 aggregated into the single prefix 209.123.10.0/23 because they have 220 the leading 23 bits in common. 222 The example above is very simple. A real example of a very large 223 degree of aggregation is the prefix 208.0.0.0/12, which covers the 224 4096 Class C networks 208.0.0.0/24 through 208.15.255.0/24. It's 225 obvious from this example how profound an impact aggregation can have 226 on the size of a routing table and the resources required for the 227 associated storage and computation. 229 It is important to aggregate as much as possible, even in the simple 230 example presented earlier, because small non-optimalities can add up 231 and result in a poorly aggregated global routing system. If you 232 exchange routes with your provider using BGP, then it is your 233 responsibility to do the aggregation configuration. (Note that 234 aggregation can only be done with BGP4, so if you are running an 235 earlier version of BGP, you should upgrade your software; most major 236 router manufacturers have implemented BGP4.) Assuming that your AS 237 number is 5555, your provider's AS number is 2222 and the IP address 238 of your provider's BGP speaker is 1.2.3.4, the Cisco syntax for 239 configuring the aggregation would be: 241 router bgp 5555 242 network 209.123.10.0 mask 255.255.254.0 243 neighbor 1.2.3.4 remote-as 2222 244 ... 245 ip route 209.123.10.0 255.255.255.0 Ethernet0 246 ip route 209.123.11.0 255.255.255.0 Ethernet1 247 ip route 209.123.10.0 255.255.254.0 Null0 254 249 The "network" line in the BGP section tells the router to announce 250 that network if it has a route to it. The third static route for 251 209.123.10.0/23 creates a "pull-up" route for the aggregate so that 252 the router actually has a route to it so that the "network" line 253 takes effect and the prefix is announced. The static route for the 254 aggregate is only needed in order for the "network" line to take 255 effect; that static route will never be used for packet forwarding 256 because the static routes for the individual Class C networks are 257 more specific and therefore take precedence. This configuration 258 information is required only on the router which speaks BGP with your 259 provider's router. 261 6. References 263 [1] Postel, J., "Internet Protocol", RFC 791, September 1991. 265 [2] Postel, J., Mogul, J.C., "Internet Standard Subnetting 266 Procedure", RFC 950, August 1985. 268 [3] Fuller, V., Li, T., Yu, J., and K. Varadhan, "Classless Inter- 269 Domain Routing (CIDR): an Address Assignment and Aggregation 270 Strategy", RFC 1519, September 1993. 272 [4] Rekhter, Y., Li, T., "An Architecture for IP Address Allocation 273 with CIDR", RFC 1518, September 1993. 275 [5] Rekhter, Y., and Li, T., "A Border Gateway Protocol 4 (BGP-4)", 276 RFC1771, March 1995. 278 [6] Ferguson, P., Berkowitz, H., "Network Renumbering Overview: Why 279 would I want it and what is it anyway?", RFC 2071, January 1997. 281 [7] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 282 1997. 284 [8] Thomson, S., Narten, T., "IPv6 Stateless Address 285 Autoconfiguration", RFC 1971, August 1996. 287 7. Authors' Addresses 289 John W. Stewart, III 290 USC/ISI 291 4350 North Fairfax Drive 292 Suite 620 293 Arlington, VA 22203 294 phone: +1 703 807 0132 295 email: jstewart@isi.edu 297 Enke Chen 298 Cisco Systems 299 170 West Tasman Drive 300 San Jose, CA 95134-1706 301 Phone: +1 408 527 4652 302 email: enkechen@cisco.com