RFC 2036

Observations on the use of Components of the Class A Address Space within the Internet

📅 published October 1996, from ietf

RFC 2036: Observations on the use of Components of the Class A Address Space within the Internet 🎀

Part 1 of 3 🧚

Network Working Group, written by G. Huston from Telstra Internet 💅

Category: Informational ✨ (this is info-sharing, not a binding standard)

Date: October 1996 🍓

Obsoletes / Updates: nothing. This one doesn't obsolete or update any other RFC, since none are listed 🦋

Status of This Memo 🫶

Okay bestie, this memo is here to provide information for the Internet community. It does not specify an Internet standard of any kind, so think of it as a juicy read, not a rulebook 📚 And the distribution is totally unlimited, so share it with everyone 💜

Abstract ✨

So this doc is basically a commentary on the recommendation that IANA starts allocating the still-unallocated chunks of Class A space to registries 🌸 Those registries then deploy them across the Internet as class-less address blocks. Iconic plan, right? 👑

It looks at what this means for service providers and end clients in that world. The big takeaway is that widespread adoption of class-less routing protocols is required, and it has to happen on a fairly quick timeline for this whole recommendation to actually work 🔥 No cap, that's the main event.

Introduction 🌈

Okay so the Address Lifetime Expectancy (ALE) Working Group of the IETF has been keeping a record of Internet addresses getting handed out from the unallocated address pool 📋 ALE noticed that the current habit of pulling addresses from the Class C space (192/3 address prefix) is going to run out in the near to medium term 😭 That's giving panic energy.

The biggest leftover pool is in the Class A space. Some 25% of Internet addresses (the upper half of the Class A space) are, to date, still unallocated 💖 Main character energy for Class A, honestly.

This document is a commentary on the potential recommendation that the Internet Assigned Numbers Authority (IANA), through delegated registries, starts allocating the presently unallocated components of the Class A address space to registries. The deployment goes through class-less address prefixes that get allocated from there, for use within the Internet 🦋

Deploying those class-less address prefixes from the Class A space is going to need some changes to the routing structure inside the Internet's component network domains. This doc lays out the motivation for those changes, and what they look like, for network domains and network service providers ✨

Current Practice with Address Allocations 💅

Right now, class-less network prefixed address blocks have been handed out in a very conservative way 🎀 They use address allocations that are compatible superblocks of Class C addresses. Meanwhile, addresses inside Class A and Class B networks are still lined up with the class-based prefix structure, so no big changes there yet 🌸

For non-transit network domains in this allocation environment, you have the option to keep using address deployment strategies with fixed subnet address structures inside contiguous areas, paired with Class-full interior routing protocols 🧚 If variable length subnet masks or disconnected subnets show up in the domain's routing structure, interior routing protocols that do subnet-based routing of Class-full networks can still be deployed successfully. The end network can also choose to use an explicit or implicit sink subnet default route 💜

When these non-transit network domains connect to the Internet infrastructure, the boundary exchange between the non-transit network and the network service provider happens one of two ways. Either it's a class-full advertisement of routes, or it's an aggregated address advertisement, where the aggregate is a superblock of the deployed component class-full networks 🫶 (Quick note: "network service provider" is used here as a synonym for a transit network domain, which gives a traffic transit service to other non-transit and peer transit network domains.)

Now the important bit, bestie 🚨 At the boundary points of a non-transit network, the non-transit network's subnet default route (if it's used explicitly) must not be directed to the network service provider's domain. The reason is to avoid a routing loop at the domain boundary point 🙈 Yikes, that would be a disaster.

For network service providers, the interior routing protocol can use either aggregated routing or explicit class-full routing in this environment 🍓 At the network service provider's boundary peering points, the strongly recommended practice is to advertise aggregated routes to transit peers. Those routes can then be further aggregated across the Internet, as long as it stays within the parameters of permissible policies 👑

Implications of Address Allocation from the Class A space 🌸

Network Service Providers Must Use Class-less Routing 💖

Okay so for network service providers in the deployed Internet, this recommendation to deploy prefixes from the Class A address space puts even more pressure on the requirement to uniformly deploy class-less routing protocols 😭 Right now, that's already mandatory for any domain that runs without a default route (ie. the provider carries full Internet routing and effectively calculates the default itself) 🧠 Other providers, though, can currently use an imported default route and stay in a class-full routing configuration. That mode is sub-optimal, because the job of aggregating routes ends up falling on peer network service providers, who do proxy aggregation of contiguous class-full address blocks 🙃

With components of the Class A in play, proxy aggregation isn't enough anymore 💀 Say a domain sees a default route and a subnet of a Class A route. In a class-full configuration, the routing structure might not follow the default route to reach other parts of the Class A network that the advertised Class A subnet route doesn't cover 🫠 That's a whole mess.

So for Network Service Providers operating within the Internet domain, deploying components of the Class A space comes with a requirement to deploy class-less routing protocols, even when there's a default route in the picture 🔥 And it's worth noting that this absolute requirement isn't the case at present, so this is a new vibe we're building toward 🌈

Consideration of Non-Transit Network Configurations ✨

okay so first up, the easy one 🌸. If a network domain is totally disconnected, with no links to any peer networking domain, it can keep using class-full interior routing protocols with subnet support. Handing out addresses from prefix blocks in the Class A space is totally doable there, and it doesn't add any extra routing or address deployment restrictions on the network domain. no catch, bestie 💅

now for non-transit network domains that ARE connected to one or more peer network domains 👀. this is where it gets a little more complicated. The vibe is that there are barely any non-transit networks running a fully class-less interior routing protocol right now. Nobody really needed one, since there was never an absolute requirement for it when you were using single class-full network addresses, or block prefixed allocations that are clusters of class-full network addresses. ngl that totally makes sense 🙈

For non-transit network domains with external peer connections to a network service provider, putting a component of the Class A space into the domain is supportable, as long as the domain uses a fully class-less interior routing protocol 🎀.

BUT there's an extra constraint on that external connection, so pay attention 🫶. The non-transit domain either agrees that the network service will do proxy aggregation of the advertised class-less address components, or the network domain is configured to advertise an aggregate route to the provider. In both cases the aggregate route must be either the allocated address block, or a fully contained sub-block. Advertising aggregatable address blocks without proxy aggregation permission, or advertising multiple sub-blocks of the registry allocated address block, is considered overly deleterious to the provider's internetworking environment because of the growth in routing table size 😭.

If the externally connected non-transit network domain uses class-full interior routing protocols, then deploying Class A address space prefixes means the domain must configure the Class A subnet default route along the same path as the default route to the network service provider. (This is the exact opposite of the routing configuration needed for address prefixes that are either aligned to class-full address boundaries or are super blocks of those class-full address blocks, so it's giving plot twist 🦋.) The network service provider may also receive leaked explicit subnet reachability information in this kind of routing configuration. That could put the job of advertising the correct aggregate address block on the network service provider as a case of proxied aggregation.

Even when explicit subnet default routing is deployed in this model, there's still a risk of unintentional traffic leakage and routing loops 💀. If the network service provider is doing proxy aggregation using the registry allocated address block, then traffic that starts inside the non-transit domain and is (mis)directed to non-deployed components of the address block will loop at the interface between the network domain and the provider. If the network service provider is set up to explicitly route only the address components that are also explicitly routed inside the non-transit domain, that (mis)directed traffic gets passed along the default route through the internetworking environment until it hits a default-less routing point, where it can finally be discarded. So the takeaway is that the non-transit network domain should explicitly configure sink subnet routes for all non-deployed components of the allocated address block 🧚. Conservative operational practice would also be to configure the proxy aggregation done by the network service provider to aggregate according to the registry allocated address block.

There's an additional constraint on a non-transit network domain using class-full interior routing protocols: the domain has no other exterior peer connections to other network domains that deploy class-full routing interior routing protocols 🙅‍♀️.

There's also a further constraint on using interior class-full routing protocols inside a non-transit network domain. If the non-transit network domain has multiple exterior connections to Network Service Providers (ie the network domain is multiply homed across a number of network providers), then each provider may wish to announce components of the same Class A parent. That's why the network domain must use a class-less interior routing protocol when it's multiply homed across network service providers 🌈.

There are also additional constraints on a non-transit network domain that has exterior connections to other peer networks. Even when the network domain uses a class-less interior routing protocol, this requirement for a class-less routing domain is transitive to other connected network domains. A second network domain, externally connected to the class-less routing part of the Class A space, will treat the boundary reachability advertisement as a complete Class A network advertisement if it uses class-full routing. Even if both network domains are connected to the same network provider, the provider's default routing advertisement to the class-full domain will be overridden by the assumed Class A advertisement coming through the domain-to-domain connection. That leads to unintended traffic diversion 😤. The diversion happens because traffic bound for parts of the Class A network that aren't deployed within the first domain will transit the first domain before entering the network service provider's domain.

It's also possible to end up with unintended routing holes 🕳️. Here's an example: two stub clients of different network service providers, X and Y, both use class-less interior routing and are both directly connected to a third network domain, Z. Z uses class-full interior routing and is configured as a transit between X and Y. X's advertisement of a component of a Class A to Z will be assumed by Z to be a complete Class A network, so it gets advertised to Y, overriding the default route Y received from its network service provider. Y will then pass all Class A addressed traffic to Z, and Z will pass it to X. Because X is configured as a non-transit stub network, X must discard all non-locally addressed traffic 🙃.

So the reasonable operational practice is to make sure that if a network domain deploys a component of the Class A address space, the network domain is configured to use class-less interior routing protocols, and the network has a single exterior connection to a class-less network provider domain, with the boundary configured as a class-less routing exchange ✨. Multiply homed network domains do come with a common requirement for class-less routing exchanges and interior class-less routing protocols across all peer connected network domains.

It's possible to propose that multi homed network domains should probably not get subnets of a class A for these reasons 🤔. But with an increasing diversity of network service providers, multi-homed network domains may become more prevalent, and the requirement to move to an interior class-less routing structure as a result of going multi-homed may not be obvious to every network domain 🍓.

Potential Guidelines for Allocation of an Address Prefix from the Class A Address Space 🎀

okay, so to sum up the possible guidelines for allocating from the Class A space, these addresses should only be assigned to network domains which:

  • have no exterior connection (in which case the domain can use either class-full or class-less interior routing protocols without further implication),

or

  • are a component of a private internet domain which uses class-full routing exchanges and no other part of the same Class A is assigned into the domain (this is probably an unlikely scenario given the probable direction to use the Class A space as the major resource for the unallocated pool of addresses for allocation),

or

  • have a single default exterior connection to a class-less routing domain, use class-full routing protocols and explicitly direct a subnet default route to the exterior connection,

or

  • use class-less interior routing protocols and connect only to other network domains which also use class-less interior routing protocols.

Last but not least 🌟, it's a reasonable objective to name a transition objective for the final configuration, which is uniform use of class-less routing domains within the Internet. That would make it possible to deploy components of the Class A space uniformly across the Internet 🌈💜

Okay bestie, so the unallocated Class C pool is getting seriously squeezed 😭, which means the remaining Class A space is about to have its main character moment. Everyone is gonna need it to work with class-less allocation. That only works if there's a widespread rollout of class-less interior routing protocols so the routed Internet keeps running properly ✨. Honestly this is a bigger glow-up than the CIDR rollout that network service providers already did, because now a huge number of network domains that are still on class-full routing need to switch over to Class-less Interior Routing Protocols (CIRP) 💅.

It's a lot of work, ngl. But if we want to keep handing out globally unique Internet addresses to new systems and networks, it's the move 🔥. The routing transition is a big task, so it's gonna take real effort.

Here are some directed activities that could help make the transition smoother 🦋:

  • The network registries start the first class-less allocations out of the unallocated Class A space for entities that either:
    • operate a CIRP environment, and either have no external connectivity, or are singly homed to a network service provider using a CIDR environment, with no other exterior connections,
    • or
    • operate a class-full routing protocol, and either have no external connectivity, or are singly homed to a network service provider using a CIDR environment, with no other exterior connections, and are willing to point the subnet default route towards the network service provider.
  • When deploying the Class A space, vendors' product sets need to let operators explicitly configure whether a router runs in class-less or class-full mode, and the default route has to behave correctly in each case 🎀. Class-full mode also needs explicit configuration for subnet default behaviour, so the operator can choose between following the default route or running a subnet default sink 🧚.
  • There's a similar activity on the host configuration side, but it's more of a long-term project 🌈. The goal is to support an address configuration mode that uses a local network prefix and host address, possibly alongside the current class-full network, subnet and host address configuration mode 💜.
  • Internet Service Providers also need to support full class-less configurations in both interior routing setups and interdomain peering routing exchanges 👑. They should also help client network domains that run a class-less boundary routing exchange configuration, and be able to do proxy aggregation where that's permitted ✨.

Security Considerations 🔐

Okay, this part is serious, so listen up 🫶. Correct configuration of the Internet's routing environment is essential to the secure operation of the Internet. Like, it's the foundation of everything 💀.

The potential use of the Class A space doesn't add any new considerations in this area 💅. So nothing extra to panic about here, just keep the routing config tight.

References 📚

[CIDR] Fuller, V., T. Li, J. Yu, and K. Varadhan, "Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy", RFC 1519, BARRnet, cisco, MERIT, OARnet, September 1993.

Author's Address 💌

Geoff Huston
Telstra Internet
Locked Bag 5744
Canberra  ACT  2601
Australia

phone: +61 6 208 1908
email: gih@telstra.net
📦 where this page comes from