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, the allocation of their address space out of a transit routing domain's space will accomplish this automatically - rather than advertise a separate route for each such client, the transit domain may advertise a single aggregate route which describes all of the destinations connected to it. Unfortunately, not all sites are singly-connected to the network, so some loss of ability to aggregate is realized for the non-trivial 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 any one of those providers. Note that they still may receive their address allocation out of a transit domain's address space (which has other advantages), but their routing information must still be explicitly advertised by most of their service providers (the exception being 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 backup basis). For this reason, the routing cost for these organizations will typically be about the same as it is today.

• Organizations which change service provider but do not renumber. 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 power-of-two block of network numbers to the client (as opposed to multiple, independent 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 but effective use of the plan to aggregate routing information will require changes to some Inter-Domain routing protocols. Likewise, deploying classless 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 and 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.