idnits 2.17.1 draft-ietf-idr-aggregation-tutorial-01.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-26) 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 17 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 (March 1998) is 9539 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) == Outdated reference: A later version (-04) exists of draft-ietf-idr-aggregation-framework-01 ** Downref: Normative reference to an Informational draft: draft-ietf-idr-aggregation-framework (ref. '9') Summary: 15 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT John W. Stewart, III / Juniper 3 Enke Chen / Cisco 4 March 1998 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 network 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 This document assumes only a very casual understanding of Internet 61 addresses. Once readers clearly understand this document, they may 62 wish to read "A Framework for Inter-Domain Route Aggregation" [9] to 63 understand the big picture of large-scale aggregation in the 64 Internet. 66 2. Network Classes and the Bit-Level Detail 68 As originally specified in the early 1980s, the Internet Protocol 69 (IP) included the idea of network "Classes." [1] In IP, a certain 70 number of bits in the 32-bit addresses refer to the network and the 71 remainder of the bits refer to a host on that network. (In the mid 72 1980s IP was extended such that part of the host bits can refer to a 73 subnet and the remainder would refer to a host on that subnet. [2]) 74 The point of the different Classes was to have addresses with 75 different numbers of network/host bits. The Class of an address 76 could be determined by the high-order bits. A Class A address had 77 "0" as the high-order bit, and then 7 bits of network and 24 bits of 78 host; a Class B address had "10" as the high-order two bits, and then 79 14 bits of network and 16 bits of host; and a Class C address had 80 "110" as the high-order three bits and then 21 bits of network and 8 81 bits of host. Looking at an address in "dotted quad notation" (e.g., 82 166.45.3.46), Class A networks have a first number of 0-127, Class B 83 networks have a first number of 128-191 and Class C networks have a 84 first number of 192-223. A Class A network could number 1.7 million 85 hosts, a Class B 65,000 and a Class C 256. Diagramatically: 87 3 3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1 88 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 89 Class +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 90 A |0 | 91 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 92 |<--network-->|<---------------------host-------------------->| 94 3 3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1 95 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 96 Class +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 97 B |1 0 | 98 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 99 |<---------network--------->|<-------------host------------>| 101 3 3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1 102 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 103 Class +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 104 C |1 1 0 | 105 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 106 |<----------------network---------------->|<-----host---->| 108 Although the original intent of having Classes was to allow for flexible 109 addressing, experience showed that the hard boundary of the three 110 Classes actually made the addressing less flexible. For example, if a 111 site connecting to the Internet needed to address 300 hosts, then a 112 Class C network wouldn't be adequate and a Class B would need to be 113 assigned. This resulted in poor utilization of the assigned address 114 space and caused a faster-than-necessary rate of consumption of the 115 available IP address space. 117 Another problem with the scalability of Internet routing under the 118 Classful system had to do with the address allocation policies used. At 119 that time, when a site connected to the Internet, it would go to a cen- 120 tral registry to get a unique IP network and then it would go to an ISP 121 to procure connectivity. What this means is that if an ISP had 1000 122 customers, each of whom had been assigned a Classful network of some 123 type, then that ISP would have to announce each of those 1000 networks 124 to other providers in the Internet. In other words, the Internet's 125 routing system was not taking advantage of the inherent provider/sub- 126 scriber hierarchy and instead was being "flat-routed." 128 3. The Introduction of CIDR 130 In the early 1990s, a number of ISPs began to have operational problems 131 related to the size of a full Internet routing table because of the lim- 132 ited amount of memory available in commercial routers. (A "full routing 133 table" means a routing table which does not contain a default route and 134 instead contains an entry for every active network in the Internet.) 135 Because of these problems, Classless Inter-Domain Routing (CIDR) was 136 created. [3] 138 CIDR removed the idea of Classes from IP. Instead of having networks 139 with an implied number of bits referring to network/host, there are 140 "prefixes" with an associated mask explicitly identifying which bits 141 refer to network/host. For example, the prefix "38.245.76.0" with a 142 mask of "255.255.255.0" has 24 bits of network and 8 bits of host (i.e., 143 it can address the same number of hosts as a Class C network even though 144 the prefix is in the Class A range). The CIDR paradigm prefers the term 145 "prefix" over "network" because it's more clear that no Class is being 146 implied. Another way to write this example prefix is "38.245.76.0/24", 147 meaning that the mask contains 24 1s in the high-order portion of the 148 mask. 150 The strength of CIDR is that the masks can be on arbitrary bit bound- 151 aries and don't have to be on byte boundaries. So for example, going 152 back to the case of the site which needs to address 300 hosts, the site 153 could be allocated a "/23" (i.e., a prefix which has 23 bits for network 154 and 9 bits for host, thus allowing 512 hosts to be addressed with the 155 single prefix). 157 To complete the picture, in order for CIDR to actually help achieve bet- 158 ter scaling of Internet routing, a specific address allocation architec- 159 ture must be used. [4] Rather than the pre-CIDR style where sites 160 would go to a centralized registry to get an address which does not take 161 into account where that site connects to the Internet, CIDR-style 162 address allocation involves registries allocating address space to ISPs 163 who, in turn, sub-allocate it to their customers. So for example, a 164 registry might allocate the prefix 204.71.0.0/16 (called a "CIDR block") 165 to ISP1, and then ISP1 could sub-allocate 204.71.1.0/24 to SmallCus- 166 tomer1, 204.71.2.0/24 to SmallCustomer2, 204.71.128.0/22 to MediumCus- 167 tomer and 204.71.136.0/20 to LargeCustomer. The benefit, then, is that 168 when ISP1 exchanges routing information with other ISPs, it only needs 169 to announce the single prefix 204.71.0.0/16 and not each of the individ- 170 ual prefixes used by its customers. The ability to merge multiple pre- 171 fixes which have some number of leading bits in common is called "aggre- 172 gation." 174 In 1993, the deployment of a routing protocol which supported CIDR 175 (specifically BGP Version 4 [5]) had an immediate and measurably posi- 176 tive effect on route scaling. Immediately after its deployment a full 177 routing table went down in size in absolute numbers (this was possible 178 only because address allocation had already been done for some time in 179 the CIDR style even though the routing hadn't yet taken advantage of it) 180 and, more importantly, the rate of growth was slowed. 182 4. A Note on Renumbering 184 The crux of CIDR is that the Internet's generally hierarchical topology 185 is being reflected in the addressing. As a result, if a site started 186 out as a customer of ISP1 and is thus numbered out of one of ISP1's CIDR 187 blocks, but then that site terminates the relationship with ISP1 and 188 "rehomes" to ISP2, then the site would need to renumber its nodes to be 189 part of one of ISP2's CIDR blocks. The major reason for this is to 190 retain efficiency in the routing system. [6] 192 Renumbering is an unfortunate necessity in the current IPv4 Internet. 193 This is the reason for the recent advance of renumbering technology in 194 IPv4 (e.g., DHCP [7]) as well as the focus of easy renumbering in IPv6. 195 [8] Sites should keep this "unfortunate necessity" in mind when deploy- 196 ing equipment to make sure that their infrastructure can be renumbered 197 easily if that becomes necessary. 199 5. Practical Aggregation 201 As stated earlier, aggregation refers to the combining of multiple con- 202 tiguous prefixes into a single prefix. For example, assume the prefixes 203 209.123.10.0/24 and 209.123.11.0/24. The binary representation for 204 209.123.10.0/24 is: 206 3 3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1 207 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 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 |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| 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 211 |<---- 209 ---->|<---- 123 ---->|<---- 10 ---->|<---- 0 ---->| 213 And the binary representation for 209.123.9.0/24 is 215 3 3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1 216 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 217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 218 |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| 219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 220 |<---- 209 ---->|<---- 123 ---->|<---- 11 ---->|<---- 0 ---->| 222 The important thing to note here is that the two networks can be aggre- 223 gated into the single prefix 209.123.10.0/23 because they have the lead- 224 ing 23 bits in common. 226 The example above is very simple. A real example of a very large degree 227 of aggregation is the prefix 208.0.0.0/12, which covers the 4096 24-bit 228 prefixes 208.0.0.0/24 through 208.15.255.0/24. It's obvious from this 229 example how profound an impact aggregation can have on the size of a 230 routing table and the resources required for the associated storage and 231 computation. 233 It is important to aggregate as much as possible, even in the simple 234 example presented earlier, because small non-optimalities can add up and 235 result in a poorly aggregated global routing system. If you exchange 236 routes with your provider using BGP, then it is your responsibility to 237 do the aggregation configuration. (Note that aggregation can only be 238 done with BGP4, so if you are running an earlier version of BGP, you 239 should upgrade your software; most major router manufacturers have 240 implemented BGP4.) Assuming that your AS number is 5555, your 241 provider's AS number is 2222 and the IP address of your provider's BGP 242 speaker is 1.2.3.4, the Cisco syntax for configuring the aggregation 243 would be: 245 interface Ethernet0 246 ... 247 ip address 209.123.10.1 255.255.255.0 248 ... 249 interface Ethernet1 250 ... 251 ip address 209.123.11.1 255.255.255.0 252 ... 253 router bgp 5555 254 network 209.123.10.0 mask 255.255.254.0 255 neighbor 1.2.3.4 remote-as 2222 256 ... 257 ip route 209.123.10.0 255.255.254.0 Null0 254 259 The "network" line in the BGP section tells the router to announce that 260 network if it has a route to it. The "ip route" statement for 261 209.123.10.0/23 is a static route that creates a "pull-up" route for the 262 aggregate; this gives the router a route to the prefix so that the "net- 263 work" line takes effect and the prefix is announced. The static route 264 for the aggregate is only needed in order for the "network" line to take 265 effect; that static route will never be used for packet forwarding 266 because the static routes for the individual /24 prefixes are more spe- 267 cific and therefore take precedence. This configuration information is 268 required only on the router which speaks BGP with your provider's 269 router. 271 In this example, it is assumed that the router which speaks BGP to the 272 provider has local interfaces numbered out of the address space being 273 aggregated. This is assumed for simplicity of the example; the "net- 274 work" line and pull-up route would be used the same ways to do the 275 aggregation even if the routing for the address space were done stati- 276 cally, based on an IGP, etc. 278 6. References 280 [1] Postel, J., "Internet Protocol", RFC 791, September 1991. 282 [2] Postel, J., Mogul, J.C., "Internet Standard Subnetting Procedure", 283 RFC 950, August 1985. 285 [3] Fuller, V., Li, T., Yu, J., and K. Varadhan, "Classless Inter- 286 Domain Routing (CIDR): an Address Assignment and Aggregation Strategy", 287 RFC 1519, September 1993. 289 [4] Rekhter, Y., Li, T., "An Architecture for IP Address Allocation with 290 CIDR", RFC 1518, September 1993. 292 [5] Rekhter, Y., and Li, T., "A Border Gateway Protocol 4 (BGP-4)", 293 RFC1771, March 1995. 295 [6] Ferguson, P., Berkowitz, H., "Network Renumbering Overview: Why 296 would I want it and what is it anyway?", RFC 2071, January 1997. 298 [7] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 299 1997. 301 [8] Thomson, S., Narten, T., "IPv6 Stateless Address Autoconfiguration", 302 RFC 1971, August 1996. 304 [9] Chen, E., Stewart III, John W., "A Framework for Inter-Domain Route 305 Aggregation", draft-ietf-idr-aggregation-framework-01.txt, July 1997. 306 TBD -- RFC NUMBER 308 7. Authors' Addresses 310 John W. Stewart, III 311 Juniper Networks, Inc. 312 385 Ravendale Drive 313 Mountain View, CA 94043 314 phone: +1 650 526 8000 315 email: jstewart@juniper.net 317 Enke Chen 318 Cisco Systems 319 170 West Tasman Drive 320 San Jose, CA 95134-1706 321 Phone: +1 408 527 4652 322 email: enkechen@cisco.com