RFC 1338

RFC 1338 · Part 1 of 5 🎀

okay bestie, let's get into it 💖 RFC 1338 is called Supernetting: an Address Assignment and Aggregation Strategy, and it's giving full early-90s internet energy 🌸

It's from the Network Working Group and it's dated June 1992. Four authors wrote it: V. Fuller from BARRNet, T. Li from cisco, J. Yu from MERIT, and K. Varadhan from OARnet 🫶 The category is Informational, so it's shared for the community to read, not a standard. Its header doesn't list anything it obsoletes or updates, so no drama there 💅

Status of this Memo ✨

ngl this part is short and sweet 🍓 It's info for the Internet community, and it does not specify an Internet standard. Distribution of this memo is unlimited, so anyone can read it and share it, no limits 🦋

Abstract 🌈

the vibe here is that this memo talks about ways to hand out the existing IP address space 🧚 The goals are to conserve the address space and to stem the explosive growth of routing tables in the default-route-free routers run by transit routing domain providers. Basically, the internet's giant routing tables were growing way too fast, and this is the plan to slow that down 😭🔥

Table of Contents 💅

Here's the full map of what's coming, section by section:

   Acknowledgements .................................................  2
   1.  Problem, goal, and motivation ................................  2
   2.  Scheme plan ..................................................  3
   2.1.  Aggregation and its limitations ............................  3
   2.2.  Distributed network number allocation ......................  5
   3.  Cost-benefit analysis ........................................  6
   3.1.  Present allocation figures .................................  7
   3.2.  Historic growth rates ......................................  8
   3.3.  Detailed analysis ..........................................  8
   3.3.1.  Benefits of new addressing plan ..........................  9
   3.3.2.  Growth rate projections ..................................  9
   4.  Changes to Inter-Domain routing protocols .................... 11
   4.1.  General semantic changes ................................... 11
   4.2.  Rules for route advertisement .............................. 11
   4.3.  How the rules work ......................................... 13
   4.4.  Responsibility for and configuration of aggregation ........ 14
   5.  Example of new allocation and routing ........................ 15
   5.1.  Address allocation ......................................... 15
   5.2.  Routing advertisements ..................................... 17
   6.  Transitioning to a long term solution ........................ 18
   7.  Conclusions .................................................. 18
   8.  Recommendations .............................................. 18
   9.  Bibliography ................................................. 19
   10. Security Considerations ...................................... 19
   11. Authors' Addresses ........................................... 19

Acknowledgements 🫶

The authors wish to express their appreciation to the members of the ROAD group with whom many of the ideas contained in this document were inspired and developed. ✨ Literally the ROAD group was carrying 💅

1. Problem, Goal, and Motivation 🎯

Okay so, the Internet has been growing and evolving like crazy in recent years, and it's become painfully obvious that it's about to hit some serious scaling problems 😭 These include:

1. Exhaustion of the class-B network address space. One fundamental cause of this problem is the lack of a network class of a size which is appropriate for mid-sized organization. class-C, with a maximum of 254 host addresses, is too small, while class-B, which allows up to 65534 addresses, is too large to be widely allocated. 💀
2. Growth of routing tables in Internet routers beyond the ability of current software (and people) to effectively manage. 🙈
3. Eventual exhaustion of the 32-bit IP address space. 🌍

It has become clear that the first two of these problems are likely to become critical within the next one to three years. ⏰ This memo tries to handle these problems by proposing a mechanism to slow the growth of the routing table and the need for allocating new IP network numbers. 🦋 It does not try to solve the third problem, which is more of a long-term situation. Instead, it works on easing enough of the short to mid-term difficulties so the Internet can keep functioning efficiently while progress is made on a longer-term solution. 🧚

The proposed solution is to hierarchically allocate future IP address assignment, by delegating control of segments of the IP address space to the various network service providers. 👑

It is proposed that this scheme of allocating IP addresses be undertaken as soon as possible. 🏃‍♀️ It is also believed that the scheme will suffice as a short term strategy, filling the gap between now and the time when a viable long term plan can be put into place and deployed effectively. It is believed that this scheme would be viable for at least three (3) years, and in that time frame a suitable long term solution would be expected to be deployed. 🌸

Note that this plan neither requires nor assumes that already assigned addresses will be reassigned. Though if doing so were possible, it would further reduce routing table sizes. 💖 It is assumed that routing technology will be capable of dealing with the current routing table size and with some reasonably-small rate of growth. The emphasis of this plan is on significantly slowing the rate of this growth. 🐢

This scheme will not affect the deployment of any specific long term plan. Therefore, this document will not discuss any long term plans for routing and address architectures. 🙅‍♀️

2. Scheme Plan 🧩

There are two basic components of this addressing and routing scheme. One is to distribute the allocation of Internet address space, and two is to provide a mechanism for the aggregation of routing information. 🎀

2.1. Aggregation and its limitations 🧠

One major goal of this addressing plan is to allocate Internet address space in such a manner as to allow aggregation of routing information along topological lines. 🗺️ For simple, single-homed clients, allocating their address space out of a service provider's space will accomplish this automatically. Rather than advertise a separate route for each such client, the service provider may advertise a single, aggregate, route which describes all of the destinations contained within it. ✨ Unfortunately, not all sites are singly-connected to the network, so some loss of ability to aggregate is realized for the non simple cases. 😤

There are two situations that cause a loss of aggregation efficiency. 👀

• Organizations which are multi-homed. Because multi-homed organizations must be advertised into the system by each of their service providers, it is often not feasible to aggregate their routing information into the address space of any one of those providers. Note that they still may receive their address allocation out of a service provider's address space (which has other advantages), but their routing information must still be explicitly advertised by most of their service providers. The exception is that if the site's allocation comes out of its least-preferable service provider, then that service provider need not advertise the explicit route. Longest-match will insure that its aggregated route is used to get to the site on a non-primary basis. For this reason, the routing cost for these organizations will typically be about the same as it is today. 🫠
• Organizations which move from one service provider to another. This has the effect of "punching a hole" in the aggregation of the original service provider's advertisement. This plan will handle the situation by requiring the newer service provider to advertise a specific advertisement for the new client, which is preferred by virtue of being the longest match. 🕳️ To maintain efficiency of aggregation, it is recommended that organizations which do change service providers plan to eventually migrate their address assignments from the old provider's space to that of the new provider. To this end, it is recommended that mechanisms to facilitate such migration, including improved protocols and procedures for dynamic host address assignment, be developed. 🚚

Note that some aggregation efficiency gain can still be had for multi-homed sites (and, in general, for any site composed of multiple, logical IP network numbers). By allocating a contiguous block of network numbers to the client (as opposed to multiple, independently represented network numbers), the client's routing information may be aggregated into a single (net, mask) pair. 🧩 Also, since the routing cost associated with assigning a multi-homed site out of a service provider's address space is no greater than the current method of a random allocation by a central authority, it makes sense to allocate all address space out of blocks assigned to service providers. 💅

It is also worthwhile to mention that since aggregation may occur at multiple levels in the system, it may still be possible to aggregate these anomalous routes at higher levels of whatever hierarchy may be present. For example, if a site is multi-homed to two NSFNet regional networks, both of whom obtain their address space from the NSFNet, then aggregation by the NSFNet of routes from the regionals will include all routes to the multi-homed site. 🌈

Finally, it should also be noted that deployment of the new addressing plan described in this document may (and should) begin almost immediately. However, effective use of the plan to aggregate routing information will require changes to some Inter-Domain routing protocols. 🔧 Likewise, deploying the supernet-capable Inter-Domain protocols without deployment of the new address plan will not allow useful aggregation to occur. In other words, the addressing plan and routing protocol changes are both required for supernetting, and its resulting reduction in table growth, to be effective. 🤝 Note, however, that during the period of time between deployment of the addressing plan and deployment of the new protocols, the size of routing tables may temporarily grow very rapidly.

This must be considered when planning the deployment of the two plans. 🚨

Note: in the discussion and examples which follow, the network+mask notation is used to represent routing destinations. This is used for illustration only and does not require that routing protocols use this representation in their updates. 📝

2.2. Distributed allocation of address space 🌐

The basic idea of the plan is to allocate one or more blocks of Class-C network numbers to each network service provider. Organizations using the network service provider for Internet connectivity are allocated bitmask-oriented subsets of the provider's address space as required. 🍓

Note that in contrast to a previously described scheme of subnetting a class-A network number, this plan should not require difficult host changes to work around domain system limitations. Since each sub-allocated piece of the address space looks like a class-C network number, delegation of authority for the IN-ADDR.ARPA domain works much the same as it does today. There will just be a lot of class-C network numbers whose IN-ADDR.ARPA delegations all point to the same servers. The same will be true of the root delegating a large block of class-Cs to the network provider, unless the delegation just happens to fall on a byte boundary. 🥹 It is also the case that this method of aggregating class-C's is somewhat easier to deploy, since it does not require the ability to split a class-A across a routing domain boundary (i.e., non-contiguous subnets). 🎈

It is also worthy to mention that once Inter-Domain protocols which support classless network destinations are widely deployed, the rules described by the "supernetting" plan generalize to permit arbitrary super/subnetting of the remaining class-A and class-B address space. The assumption being that classless Inter-Domain protocols will either allow for non-contiguous subnets to exist in the system, or that all components of a sub-allocated class-A/B will be contained within a single routing domain. 🧠 This will allow this plan to continue to be used in the event that the class-C space is exhausted before implementation of a long-term solution is deployed. There may, however, be further implementation considerations before doing this. ⚠️

Hierarchical sub-allocation of addresses in this manner implies that clients with addresses allocated out of a given service provider are, for routing purposes, part of that service provider and will be routed via its infrastructure. 🏢 This implies that routing information about multi-homed organizations, i.e., organizations connected to more than one network service provider, will still need to be known by higher levels in the hierarchy. 🪜

The advantages of hierarchical assignment in this fashion are:

• a) It is expected to be easier for a relatively small number of service providers to obtain addresses from the central authority, rather than a much larger, and monotonically increasing, number of individual clients. This is not to be considered as a loss of part of the service providers' address space. 💼
• b) Given the current growth of the Internet, a scalable and delegatable method of future allocation of network numbers has to be achieved. 📈

For these reasons, and in the interest of providing a consistent procedure for obtaining Internet addresses, it is recommended that most, if not all, network numbers be distributed through service providers. 💖

3. Cost-benefit analysis 💸

Okay so this new way of handing out addresses through service providers can be switched on right away 💅, and from day one it starts spreading out the job of assigning new addresses, which is super centralized right now 🧚. BUT (and it's a big but 😭) before we can actually shrink the globally-known routing destinations, we need an Inter-Domain routing protocol that can handle arbitrary network+mask pairs. Only once that's in place can class-C networks get bundled into bigger blocks that each show up as one single routing table entry ✨.

So literally, the moment this goes in, the new addressing plan won't fix the routing table size problem on its own 💀. Once the new Inter-Domain protocol is deployed though, there's an immediate drop in the number of destinations that clients of the new protocol have to carry 🦋. A detailed breakdown of how big that drop is, plus the permanent slowdown in growth rate, is in the next section 📈.

Also, the current flat address allocation is a huge bureaucratic cost for the central allocation authority, and it should be changed for scaling reasons that have nothing to do with address space exhaustion or routing table overflow 🙈. The mechanism proposed here has a happy side effect: it distributes the allocation procedure, which takes a ton of load off the central authority 🫶.

3.1. Present Allocation Figures

Quick back-of-the-envelope check on "network-contacts.txt" (grab it from the DDN NIC) 🌸. As of 2/25/92, 46 of 126 class-A network numbers were allocated (so 81 are left), and 5467 of 16256 class-B numbers were allocated, leaving 10789. If recent trends hold, the number of allocated class-Bs keeps doubling about once a year. At this rate of growth, all class-Bs will be exhausted within about 15 months 😭.

3.2. Historic growth rates

      MM/YY     ROUTES                        MM/YY     ROUTES
                ADVERTISED                              ADVERTISED
      ------------------------                -----------------------
      Feb-92    4775                          Apr-90    1525
      Jan-92    4526                          Mar-90    1038
      Dec-91    4305                          Feb-90    997
      Nov-91    3751                          Jan-90    927
      Oct-91    3556                          Dec-89    897
      Sep-91    3389                          Nov-89    837
      Aug-91    3258                          Oct-89    809
      Jul-91    3086                          Sep-89    745
      Jun-91    2982                          Aug-89    650
      May-91    2763                          Jul-89    603
      Apr-91    2622                          Jun-89    564
      Mar-91    2501                          May-89    516
      Feb-91    2417                          Apr-89    467
      Jan-91    2338                          Mar-89    410
      Dec-90    2190                          Feb-89    384
      Nov-90    2125                          Jan-89    346
      Oct-90    2063                          Dec-88    334
      Sep-90    1988                          Nov-88    313
      Aug-90    1894                          Oct-88    291
      Jul-90    1727                          Sep-88    244
      Jun-90    1639                          Aug-88    217
      May-90    1580                          Jul-88    173

            Table I : Growth in routing table size, total numbers
                      Source for the routing table size data is MERIT

3.3. Detailed Analysis

There's no technical cost and minimal administrative cost to deploying the new address assignment plan 💖. The admin cost is basically convincing the NIC, the IANA, and the network service providers to agree, which isn't expected to be too hard. Admin cost for the central numbering authorities (the NIC and the IANA) also drops a lot with this plan. To get the aggregation benefits for routing info, though, the common Internet inter-domain routing protocol(s) need to be able to represent routes as arbitrary network+mask fields (instead of today's class-A/B/C distinction) 🧠.

3.3.1. Benefits of the new addressing plan

There are two benefits to be had by deploying this plan 🎀:

• The current class-B depletion problem can be eased by assigning more appropriately sized blocks of class-Cs to mid-sized organizations (in the 200-4000 host range).
• When the improved inter-domain routing protocol is deployed, there should be an immediate decrease in the number of routing table entries, followed by a significant reduction in the rate of routing table growth (for default-free routers) 📉.

3.3.2. Growth rate projections

A default-free routing table (like the ones the routers on the NSFNET backbone keep) has about 4700 entries right now 🌐. That matches the current size of the NSFNET routing database. Historic data shows this number has, on average, doubled every 10 months between 1988 and 1991. Assuming that growth rate keeps going in the foreseeable future (and there's no reason to assume otherwise), we expect a default-free routing table to grow to about 30000 entries in two(2) years 😳. In the analysis below, we assume the growth of the Internet has been, and will keep being, exponential.

It should be stressed that these projections don't account for the current class-B shortage pushing more orgs toward many class-Cs instead of a single class-B 👀. If new organizations that used to get class-Bs now get somewhere between 4 and 16 class-Cs, routing table growth can conservatively be expected to at least double and probably quadruple 🤯. That means a default-free routing table may well exceed 10,000 entries within six months and 20,000 entries in less than a year 😱.

Under the proposed plan, routing table growth in a default-free router is greatly reduced, since most new address assignments come from the large blocks given to the service providers 🍓. For the sake of this analysis, we assume prompt implementation of this proposal and deployment of the revised routing protocols. We also make the initial assumption that any initial block given to a provider is enough to satisfy its needs for two years.

Since multi-homed networks must continue to be explicitly advertised throughout the system under this plan (according to Rule#1 described in section 4.2), the number of multi-homed routes is expected to be the dominant factor in future routing table growth once the supernetting plan is applied 🧩.

Right now, it's estimated there are fewer than 100 multi-homed organizations connected to the Internet 🙋. Each one's network is made up of one or more network numbers. In many cases (and in all future cases under this plan), the network numbers an organization uses are consecutive, which means aggregating them during route advertisement may be possible. So the number of routes advertised for multi-homed networks can be approximated as the total number of multi-homed organizations. Assuming that number doubles every year (which may be an over-estimation, since every connection costs money 💸), the number of routes for multi-homed networks would be expected to grow to approximately 800 in three years.

If we further assume there are about 100 service providers, each one still needs to advertise its block of addresses. But thanks to aggregation, those advertisements get reduced to only 100 additional routes 🎉. We assume that after the initial two years, new service providers, plus additional requests from existing providers, will need an additional 50 routes per year. So the total is 4700 + 800 + 150 = 5650. That works out to an annual growth rate of approximately 6%, which is in clear contrast to the current annual growth of 150% 🚀. This analysis also assumes an immediate deployment with full compliance. Note that this analysis assumes only a single level of route aggregation in the current Internet. Intelligent address allocation should significantly improve on that 💅.

Clearly, this is not a very conservative assumption for the Internet environment, and 100% adoption of this proposal can't be expected either 🙃. Still, with only 90% participation in this proposal by service providers, at the end of the target three years, the global routing table size will be "only" 4700 + 800 + 145 + 7500 = 13145 routes. Without any action, the routing table would grow to approximately 75000 routes during that same time period 😱.

4. Changes to Inter-Domain routing protocols ✨

In order to support supernetting efficiently, some changes clearly need to be made to both the routing protocols themselves and the way routing information is interpreted 🛠️. For "new" inter-domain protocols, the actual protocol syntax changes should be relatively minor. This mechanism will not work with older inter-domain protocols such as EGP2. The only ways to interoperate with old systems using those protocols are either to use existing mechanisms for providing "default" routes, or (b) require that new routers talking to old routers "explode" supernet information into individual network numbers. The first is trivial, while the latter is cumbersome (at best, considering the memory requirements it imposes on the receiver of the exploded information) 🥴. So it's recommended that the first approach be used, meaning older systems continue to use the mechanisms they currently employ for default handling 💜.

Note that a basic assumption of this plan is that organizations which need to import "supernet" information into their routing systems must run IGPs (such as OSPF[RFC1267]) that support classless routes 🌸.

Heads up: systems running older IGPs can still advertise and receive "supernet" information, but they won't be able to propagate that information through their routing domains ⚠️.

4.1. Protocol-independent semantic changes

There are two big changes Inter-Domain routing protocols need before this plan can work 🎀. First, the whole idea of network "class" has to be deprecated, bestie 💅. The plan assumes routing destinations are network+mask pairs, and routing is done on a longest-match basis, so when a destination matches several network+mask pairs, the one with the longest mask wins 👑. Second, current Inter-Domain protocols mostly don't support route aggregation, so the new semantics have to live in the mechanisms routers use to interpret the routing info those protocols hand back 🧚. It gets messy when you're aggregating, dealing with multi-homed sites, or handling destinations that switch service providers 😭. The good news? A few fairly simple rules can handle all of that ✨.

4.2. Rules for route advertisement 📬

1. Routing to all destinations must be done on a longest-match basis only. This means destinations that are multi-homed relative to a routing domain must always be explicitly announced into that routing domain. They cannot be summarized 🙅‍♀️ (and this makes intuitive sense, ngl: if a network is multi-homed, all of its paths into a routing domain that is "higher" in the hierarchy of networks must be known to the "higher" network 💜).
2. A routing domain that performs summarization of multiple routes must discard packets which match the summarization but do not match any of the explicit routes that make up the summarization. This is what stops routing loops when there's less-specific info floating around, like a default route 🔁. Implementation note: one simple way to do this is for the border router to keep a "sink" route for each of its aggregations. By the rule of longest match, all traffic headed for components of the aggregation that aren't explicitly known gets discarded 🗑️.

Okay, here's the tea 🍵. During failures, some traffic meant for a site that takes its address space from one service provider, but is actually only reachable through another one (the case of a site that has changed service providers), can get partially routed. That happens because the traffic follows the path advertised by the aggregated route. Rule #2 stops any real problem by making the advertiser of the aggregated route discard that traffic. But the output of traceroute and similar tools will make it look like the problem is inside the service provider advertising the aggregate, which can be super confusing for network operators 😵‍💫 (see the example in section 5.2 for details). Solutions to this are challenging and not likely to be implementable by current Inter-Domain protocols in the time frame this document suggests 🕰️. This decision may need a second look as Inter-Domain protocols evolve 🦋.

An implementation that follows these rules should also be generalized, so that arbitrary network number and mask are accepted for all routing destinations. The only remaining constraint is that the mask must be left contiguous 🧱. Also, the degenerate route 0.0.0.0 mask 0.0.0.0 is used as a default route and MUST be accepted by all implementations 🫶. To protect against accidental advertisements of this route via the inter-domain protocol, this route should never be advertised unless there is specific configuration information indicating to do so 🚫.

Systems that process route announcements also need to be able to verify that the information they receive is correct 🔍. So implementations of this plan that filter route advertisements must also allow masks in the filter elements. To keep admin simple, it would be useful if filter elements automatically let more specific network numbers and masks pass when they're given for a more general mask 🪄. So filter elements that looked like this:

accept 128.32.0.0
accept 128.120.0.0
accept 134.139.0.0
accept 36.0.0.0

would look something like this:

accept 128.32.0.0 255.255.0.0
accept 128.120.0.0 255.255.0.0
accept 134.139.0.0 255.255.0.0
deny 36.2.0.0 255.255.0.0
accept 36.0.0.0 255.0.0.0

This is basically just making explicit the network mask that was implied by the class-A/B/C classification of network numbers 💖.

4.3. How the rules work 🧠

Rule #1 guarantees the routing algorithm stays consistent across implementations and consistent with other routing protocols, such as OSPF 🤝. Multi-homed networks are always explicitly advertised by every service provider they're routed through, even if they're a specific subset of one service provider's aggregate. (If they aren't, they clearly must be explicitly advertised anyway 📣.) It may seem like the "primary" service provider could advertise the multi-homed site implicitly as part of its aggregate, but the assumption that longest-match routing is always done means that just doesn't work 🙃.

Rule #2 guarantees that no routing loops form because of aggregation 🔒. Picture a mid-level network that has been allocated the 2048 class-C networks starting with 192.24.0.0 (see the example in section 5 for more on this) 🌸. The mid-level advertises 192.24.0.0/255.248.0.0 to a "backbone". Say the "backbone" has been allocated the block 192.0.0.0/255.0.0.0, so it advertises that aggregate route to the mid-level. Now, say the mid-level loses internal connectivity to 192.24.1.0/255.255.255.0, which is part of its aggregate. Traffic from the "backbone" through the mid-level to destination 192.24.1.1 will follow the mid-level's advertised route. When that traffic reaches the mid-level, though, the mid-level must not follow the route 192.0.0.0/255.0.0.0 it learned from the backbone, because that would create a routing loop 🔄🚫. Rule #2 says the mid-level may not follow a less-specific route for a destination that matches one of its own aggregated routes. The "default" route (0.0.0.0/0.0.0.0) is a special case of this rule: a network must not follow the default to destinations that are part of one of its aggregated advertisements 🎀.

4.4. Responsibility for and configuration of aggregation 🗂️

The AS that owns a range of addresses has sole authority over aggregating its address space 👑. In the usual case, the AS installs manual configuration commands in its border routers to aggregate some portion of that space. An AS can also delegate aggregation authority to another AS. In that case, the aggregation happens in the other AS, done by one of its border routers 🤝.

When an inter-domain border router performs route aggregation, it needs to know the range of the block of IP addresses to be aggregated 📏. The basic principle is to aggregate as much as possible, but not to aggregate routes that can't be treated as part of a single unit because of multi-homing, policy, or other constraints 🧩.

There's one mechanism where aggregation is done only from dynamically learned routing information. The danger is that it might not specify a precise enough range, because when a route is missing, it isn't always possible to tell whether it's temporarily unreachable or just doesn't belong in the aggregate 😬. Purely dynamic routing also doesn't allow the flexibility to define what to aggregate within a range. The other mechanism does all aggregation based on ranges of IP address blocks preconfigured in the router. Preconfiguration is recommended, since it's more flexible and allows a precise specification of the range of destinations to aggregate 💯.

Preconfiguration does require some manually-maintained configuration information, but not a lot more than router administrators already maintain today 📝. Compared to what humans already type in and maintain, preconfiguration is just a line or two defining the range of the block of IP addresses to aggregate. As for gathering the info: if the advertising router is doing the aggregation, its administrator knows it because the aggregation ranges are assigned to its domain 🏠. If the receiving domain has been granted the authority and task of aggregating, the info would be known as part of the agreement to delegate aggregation 🤓. Since it's common practice for a network administrator to learn from a neighbor which routes it should be willing to accept, preconfiguring aggregation info doesn't add any extra admin overhead 🥰.

5. Example of new allocation and routing 🦋

5.1. Address allocation 🎀

Consider the block of 2048 class-C network numbers beginning with 192.24.0.0 (0xC0180000 and ending with 192.31.255.0 (0xC01FFF00), allocated to a single network provider called "RA" 🏢. A "supernetted" route to this block of network numbers would be described as 192.24.0.0 with a mask of 255.248.0.0 (0xFFF80000) ✨.

Assume this service provider connects six clients, in this order. The order matters because it shows how temporary "holes" can form in the service provider's address space 🕳️:

"C1" requiring fewer than 2048 addresses (8 class-C networks)

"C2" requiring fewer than 4096 addresses (16 class-C networks)

"C3" requiring fewer than 1024 addresses (4 class-C networks)

"C4" requiring fewer than 1024 addresses (4 class-C networks)

"C5" requiring fewer than 512 addresses (2 class-C networks)

"C6" requiring fewer than 512 addresses (2 class-C networks)

In every case, the number of IP addresses "required" by each client is assumed to allow for significant growth 📈. The service provider allocates its address space like this 🍰:

C1: allocate 192.24.0 through 192.24.7. This block of networks is
    described by the "supernet" route 192.24.0.0 and mask
    255.255.248.0

C2: allocate 192.24.16 through 192.24.31. This block is described
    by the route 192.24.16.0, mask 255.255.240.0

C3: allocate 192.24.8 through 192.24.11. This block is described
    by the route 192.24.8.0, mask 255.255.252.0

C4: allocate 192.24.12 through 192.24.15. This block is described
    by the route 192.24.12.0, mask 255.255.252.0

C5: allocate 192.24.32 and 192.24.33. This block is described by

    the route 192.24.32.0, mask 255.255.254.0

C6: allocate 192.24.34 and 192.24.35. This block is described by
    the route 192.24.34.0, mask 255.255.254.0

Note that if the network provider uses an IGP that can support classless networks, they can (but don't have to) do "supernetting" at the point where they connect to their clients. That means they only need to maintain six distinct routes for the 36 class-C network numbers 🧮. If not, explicit routes to all 36 class-C networks will have to be carried by the IGP 📡.

To make this example more realistic 🌍, assume that C4 and C5 are multi-homed through another service provider, "RB". Also assume there's a client "C7" that was originally connected to "RB" but has moved to "RA" 🚚. For this reason, it has a block of network numbers that are allocated out of "RB"'s block of (the next) 2048 class-C network numbers:

C7: allocate 192.32.0 through 192.32.15 🧚 This block is described by the route 192.32.0, mask 255.255.240.0 💖

Okay so for the multi-homed clients 👑 we're going to assume C4 is advertised as primary via "RA" and secondary via "RB", and C5 is primary via "RB" and secondary via "RA". To connect this whole mess 💅 we'll assume "RA" and "RB" are connected through some common "backbone" provider "BB".

Graphically, this simple topology looks something like this 🦋:

                       C1
192.24.0.0 -- 192.24.7.0 \         _ 192.32.0.0 - 192.32.15.0
192.24.0.0/255.255.248.0  \       /  192.32.0.0/255.255.240.0
                           \     /             C7
                       C2  +----+                                 +----+
192.24.16.0 - 192.24.31.0 \|    |                                 |    |
192.24.16.0/255.255.240.0  |    |  _ 192.24.12.0 - 192.24.15.0 _  |    |
                           |    | /  192.24.12.0/255.255.252.0  \ |    |
                       C3 -|    |/              C4               \|    |
192.24.8.0 - 192.24.11.0   | RA |                                 | RB |
192.24.8.0/255.255.252.0   |    |___ 192.24.32.0 - 192.24.33.0 ___|    |
                          /|    |    192.24.32.0/255.255.254.0    |    |
                       C6  |    |               C5                |    |
192.24.34.0 - 192.24.35.0  |    |                                 |    |
192.24.34.0/255.255.254.0  |    |                                 |    |
                           +----+                                 +----+
                              \\                                     \\
192.24.12.0/255.255.252.0 (C4) ||      192.32.12.0/255.255.252.0 (C4) ||
192.24.32.0/255.255.254.0 (C5) ||      192.32.32.0/255.255.192.0 (C5) ||
192.32.0.0/255.255.240.0  (C7) ||      192.32.0.0/255.248.0.0 (RB)    ||
192.24.0.0/255.248.0.0 (RA)    ||                                     ||
                               VV                                     VV
                     +--------------- BACKBONE PEER  BB ---------------+

5.2. Routing advertisements 📡

Okay so to follow rule #1 🎀, RA needs to advertise the block of addresses it was given, plus C7. And since C4 and C5 are multi-homed, they MUST also be advertised ✨.

Advertisements from "RA" to "BB" will be:

    192.24.12.0/255.255.252.0 primary    (advertises C4)
    192.24.32.0/255.255.254.0 secondary  (advertises C5)
    192.32.0.0/255.255.240.0 primary     (advertises C7)
    192.24.0.0/255.248.0.0 primary       (advertises remainder of RA)

For RB, the advertisements MUST also include C4 and C5 as well as its block of addresses. Further, RB MAY advertise that C7 is unreachable 🌸.

Advertisements from "RB" to "BB" will be:

    192.24.12.0/255.255.252.0 secondary  (advertises C4)
    192.24.32.0/255.255.254.0 primary    (advertises C5)
    192.32.0.0/255.248.0.0 primary       (advertises remainder of RB)

Now the drama 😭 this is the problem the "note" in section 4.2 was talking about. Say RA loses connectivity to C7, the client living in RB's space. In a stateful protocol, RA tells BB that 192.32.0.0/255.255.240.0 is unreachable 💀. When BB flushes that from its routing table, any future traffic sent through it for that destination gets forwarded to RB (where it's dropped according to Rule #2) because of RB's less specific match 192.32.0.0/255.248.0.0. Not an operational disaster, since C7 is unreachable anyway, but it creates extra traffic across "BB" and MAY also prove confusing to a network manager debugging the outage with "traceroute" 🙈. A mechanism to cache that unreachability information would help here, but it's beyond the scope of this document (and such a mechanism is also not implementable in the near-term).

6. Transitioning to a long term solution 🦋

This solution does not change the Internet routing and addressing architectures. So transitioning to a more long term solution is not affected by deploying this plan 💜.

7. Conclusions 👑

We're all aware of the growth in routing complexity and the rapid increase in allocation of network numbers 😩. Given how fast this growth is being observed, we expect to run out in a few short years.

If the inter-domain routing protocol supports carrying network routes with associated masks, all of the major concerns demonstrated in this paper would be eliminated ✨.

One of the things that lets us get the most out of this plan is how many people agree to use it. It's hoped that having the IAB and the Internet society bless this plan would go a long way toward wide deployment, and therefore the benefit of this plan 🫶.

If service providers start charging networks for advertising network numbers, that would be a very great incentive to share the address space, and therefore the associated costs of advertising routes to service providers 💅.

8. Recommendations 🍓

• The NIC SHOULD begin to hand out large blocks of class-C addresses to network service providers. Each block MUST fall on bit boundaries and SHOULD be large enough to serve the provider for two years.
• Further, the NIC SHOULD distribute very large blocks to continental and national network service organizations, so additional levels of aggregation can take place at the major backbone networks.
• Service providers will further allocate power-of-two blocks of class-C addresses from their address space to their subscribers.
• All organizations, including those which are multi-homed, SHOULD obtain address space from their provider (or one of their providers, in the case of the multi-homed). These blocks SHOULD also fall on bit boundaries to permit easy route aggregation.
• To allow effective use of this new addressing plan to reduce propagated routing information, appropriate IETF WGs will specify the modifications needed to Inter-Domain routing protocols. Implementation and deployment of these modifications SHOULD occur as quickly as possible 🚀.

9. Bibliography 📚

• [RFC1247] Moy, J, "The OSPF Specification Version 2", January 1991.

10. Security Considerations 💀

Security issues are not discussed in this memo. 😭 That's the entire security section, bestie, so don't skip past it!

11. Authors' Addresses 🎀

Vince Fuller
BARRNet
Pine Hall 115
Stanford, CA, 94305-4122
email: vaf@Stanford.EDU

Tony Li
cisco Systems, Inc.
1525 O'Brien Drive
Menlo Park, CA 94025
email: tli@cisco.com

Jessica (Jie Yun) Yu
Merit Network, Inc.
1071 Beal Ave.
Ann Arbor, MI 48109
email: jyy@merit.edu

Kannan Varadhan
Internet Engineer, OARnet
1224, Kinnear Road,
Columbus, OH 43212
email: kannan@oar.net