RFC 1887

An Architecture for IPv6 Unicast Address Allocation

📅 published December 1995, from ietf

RFC 1887 🎀 An Architecture for IPv6 Unicast Address Allocation

okay bestie, let's do the title block first 💅 This is RFC 1887 from the Network Working Group, dated December 1995 🗓️. It's marked Informational, so it provides information for the Internet community and isn't a standard. The authors are Y. Rekhter and T. Li, both from cisco Systems, and they're listed as the Editors ✍️. The title block doesn't say it obsoletes or updates any other RFC.

Status of this Memo 📜

okay so this doc provides information for the Internet community. It doesn't specify an Internet standard of any kind 🙈 And distribution of this memo is unlimited 🌍✨

Abstract ✨

this doc gives an architecture for allocating IPv6 [1] unicast addresses across the Internet 🦋 The overall IPv6 addressing architecture is defined in [2]. It doesn't go into the details of an addressing plan, so no specific layout here 💖

1. Scope 🌍

okay so picture the global internet as a bunch of hosts hooked up through transmission and switching facilities 🖥️ Control over those hosts and facilities isn't homogeneous, it's spread across multiple administrative authorities. Resources under one administration within a contiguous piece of network topology form a domain. For the rest of this paper, domain and routing domain mean the same thing, so no mixing them up 🫶

Domains that share their resources with other domains are called network service providers (or just providers) 💜 Domains that use other domains' resources are called network service subscribers (or just subscribers). And a domain can be a provider and a subscriber at the same time, which is very main character of it 👑

There are two aspects to care about when we talk about IPv6 unicast address allocation. The first is the administrative stuff: the requirements for getting and handing out IPv6 addresses. The second is the technical side, which is mostly about routing, both inside a routing domain (intra-domain routing) and between routing domains (inter-domain routing) 🧚 This paper focuses on the technical issues, bestie.

In the current Internet, lots of routing domains (like corporate and campus networks) connect to transit networks (like regionals) through only one or a small number of carefully controlled access points 🏢 The former act as subscribers, and the latter act as providers 🌈

Addressing solutions that need big changes to, or constraints on, the current topology are not considered 🙅

The architecture and recommendations here are mainly aimed at large-scale division of IPv6 address allocation across the Internet 🍓 The topics covered include:

Benefits of encoding some topological information in IPv6 addresses, which can significantly cut down routing protocol overhead 📉
The expected need for extra levels of hierarchy in Internet addressing to keep up with network growth 📈
The recommended mapping between Internet topological entities (that's service providers and service subscribers) and IPv6 addressing and routing components 🗺️
The recommended split of IPv6 address assignment between service providers (like backbones and regionals) and service subscribers (like sites) 🎀
Allocation of IPv6 addresses by the Internet Registry 📋
Choosing the high-order portion of IPv6 addresses in leaf routing domains that connect to more than one service provider (like a backbone or a regional network) 🔥

It's noted that there are other aspects of IPv6 address allocation, both technical and administrative, that this paper doesn't cover 🙈 The topics not covered, or only mentioned superficially, include:

A specific plan for address assignment 🗂️
Embedding address spaces from other network layer protocols (including IPv4) in the IPv6 address space, plus the addressing architecture for those embedded addresses 🧩
Multicast addressing 📣
Address allocation for mobile hosts 📱
Identifying specific administrative domains in the Internet 🔍
Policy or mechanisms for making registered information known to third parties (like the entity a specific IPv6 address, or a portion of the IPv6 address space, has been allocated to) 🤐
How a routing domain (especially a site) should organize its internal topology or divide up its IPv6 address space. The relationship between topology and addresses is discussed, but the method for deciding on a particular topology or internal addressing plan is not 🏠
Procedures for assigning host IPv6 addresses 💻

2. Background 📚

okay so this section has some background that helps you get why IPv6 address allocation is tricky 🤓 It also gives a brief overview of IPv6 routing, which is lowkey important.

IPv6 splits the routing problem into three parts:

Routing exchanges between end systems and routers 🖥️
Routing exchanges between routers in the same routing domain, and 🔁
Routing among routing domains 🌐

3. IPv6 Addresses and Routing 🦋

for this paper, an IPv6 address prefix is an IPv6 address plus some indication of the leftmost contiguous significant bits within that address portion 💖 Throughout the paper, prefixes are written as X/Y. Here X is a prefix of an IPv6 address with a length greater than or equal to the one given by Y, and Y is the (decimal) number of leftmost contiguous significant bits in that address. In the notation, X (the prefix of an IPv6 address [2]) has its trailing insignificant digits removed. So an IPv6 prefix might look like 43DC:0A21:76/40 ✨

when you're setting an administrative policy for IPv6 address assignment, it's super important to understand the technical consequences 🧠 The whole point of hierarchical routing is to get some level of routing data abstraction, or summarization. That cuts down on the CPU, memory, and transmission bandwidth that routing eats up 🔥

Routing data abstraction can apply to lots of different kinds of routing information, but this paper focuses on one type: reachability information 🎯 Reachability information describes the set of reachable destinations. Abstracting reachability information means IPv6 addresses should be assigned according to topological routing structures. In practice though, administrative assignment follows organizational or political boundaries 😭 Those may not line up with topological boundaries, so the two requirements can collide. It's necessary to find a balance between these two needs ⚖️

Reachability information abstraction happens at the boundary between hierarchically arranged topological routing structures. An element lower in the hierarchy reports summary reachability information to its parent(s) 🧚

At routing domain boundaries, IPv6 address information gets exchanged with other routing domains, either statically or dynamically 🤝 If the IPv6 addresses within a routing domain are all drawn from non-contiguous IPv6 address spaces (so no abstraction is possible), then the address information exchanged at the boundary is an enumerated list of all the IPv6 addresses 📜

But if the routing domain draws IPv6 addresses for all its hosts from a single IPv6 address prefix, the boundary routing information can be summarized into that one prefix 🎀 That's a huge data reduction and allows better scaling, compared to the uncoordinated addressing we just talked about 🚀

If routing domains are interconnected in a more-or-less random (aka non-hierarchical) way, it's pretty likely that no further abstraction of routing data can happen 😬 Since the routing domains have no defined hierarchical relationship, administrators can't assign IPv6 addresses within the domains out of some common prefix for data abstraction. The result would be flat inter-domain routing, where every routing domain needs explicit knowledge of every other routing domain it routes to 🕸️ This can work well in small and medium sized internets. But it does not scale to very large internets 💀 For example, we expect IPv6 to grow to hundreds of thousands of routing domains in North America alone 🌎 That calls for a greater degree of reachability information abstraction than can be achieved at the routing domain level 🫶

In the Internet, it should be possible to significantly constrain the volume and complexity of routing information by taking advantage of the existing hierarchical interconnectivity. This is discussed further in Section 5 ✨ So there's an opportunity for a group of routing domains to each be assigned an address prefix from a shorter prefix that belongs to another routing domain, whose job is to interconnect the group 👑 Each member of the group now has its own (somewhat longer) prefix, and it assigns its addresses from that prefix 🎀

The most straightforward case is when a set of routing domains are all attached to a single service provider domain (e.g., a regional network), and they use that provider for all external (inter-domain) traffic 💅 A short prefix can be given to the provider, which then hands out slightly longer prefixes (based on the provider's prefix) to each routing domain it interconnects 🌸 That lets the provider, when it tells other routing domains which addresses it can reach, squish the reachability info for a large number of routing domains into a single prefix 🪄 This approach can cut routing information down a ton, which can greatly improve the scalability of inter-domain routing 📈

This is recursive, so it can be carried through several iterations 🔁 Routing domains at any level in the hierarchy can use their prefix as the basis for later suballocations, as long as the IPv6 addresses stay within the overall length and structure constraints 🧩

Here's the thing: the number of nodes at each lower level of a hierarchy tends to grow exponentially 🚀 So the biggest gains in reachability information abstraction (which help all the higher levels of the hierarchy) happen when the aggregation is near the leaves. The gains drop off significantly at each higher level 📉 That's the law of diminishing returns, and it suggests that at some point, data abstraction stops being worth it 🙃 Figuring out where that point is takes careful thought about how many routing domains are expected at each level of the hierarchy over a given period of time. That gets compared to how many routing domains and address prefixes can be conveniently and efficiently handled by dynamic inter-domain routing protocols 🧠💜

3.1 Efficiency versus Decentralized Control. 🌟

okay so bestie, if the Internet wants to support decentralized address administration 🎀, there's a whole balancing act 🤹‍♀️ between what IPv6 addresses need to do for efficient routing and what everyone needs for running their own address stuff. no cap, any coherent addressing plan at any level of the Internet has to think through the alternatives super carefully 💅

here's an example to make it click ✨. say the IPv6 prefix 43/8 is the chunk of IPv6 address space set aside for North America 🌎. all the addresses inside that prefix can be handed out along topological boundaries, which is how you get that juicy data abstraction 🧠. inside 43/8, addresses could be given out per-provider, by geography, or by some other topologically meaningful thing. for this example, we're going with per-provider 🫶. so subscribers in North America use addresses from the space underneath their service provider's address space. and inside any one routing domain, the addresses for subnetworks and hosts come out of the unique IPv6 prefix assigned to that domain, following that domain's own addressing plan 📋.

4. IPv6 Address Administration and Routing in the Internet ✨

okay so Internet routing pieces are basically a hierarchy 🪜. you've got service providers (backbones, regional networks) and service subscribers (sites or campuses), and they mostly stack up nice and neat. so a natural move is to map providers and subscribers straight onto IPv6 routing domains 🧩.

alternatively, a subscriber (like a site) can choose to operate as part of a domain formed by a service provider 🤝. we figure a lot of sites, maybe most, will prefer to be part of their provider's routing domain and swap routing info directly with the provider 💬. the site still gets a prefix from the provider's address space, and the provider advertises its own prefix into inter-domain routing 📣.

given that mapping, where should address administration and allocation happen so you get both administrative decentralization AND data abstraction? 🤔 these are the options:

At some part within a routing domain,
At the leaf routing domain,
At the transit routing domain (TRD), and
At some other, more general boundaries, such as at the continental boundary.

a part within a routing domain is any arbitrary connected set of subnetworks 🧃. if a domain has multiple subnetworks, routers hook them together 🔗. leaf routing domains are sites, and their main job is intra-domain routing 🏠. transit routing domains are deployed to carry transit (i.e., inter-domain) traffic, and backbones and providers are TRDs 🚚. more general boundaries are just topologically significant collections of TRDs 🗺️.

the biggest burden for reachability info is at the top of the routing hierarchy, where it piles up 📚. in the Internet, providers have to manage reachability info for every subscriber directly connected to them. traffic going to other providers generally gets routed to the backbones (which act as providers too), and backbones have to be aware of the reachability info for all attached providers and their subscribers 😭.

in general, abstracting routing info at a level gets more valuable the higher up you go 📈. there's not much direct benefit for the administration doing the abstracting, since it still has to maintain routing info individually on each attached topological routing structure 🙃.

for example, say a site is deciding whether to grab an IPv6 prefix straight from the North America space or from its service provider's space 🤷‍♀️. if you only look at self-interest, the site and the attached provider don't have much reason to pick one approach over the other. the site has to use one prefix or another, and where the prefix came from barely changes routing efficiency inside the site 🏡. the provider still has to keep info about each attached site in order to route, no matter how the site prefixes are related 💁‍♀️.

BUT there's a difference when the provider distributes routing info to other providers (backbones or TRDs) 😤. in the first case, the provider can't aggregate the site's address into its own prefix. the address has to be explicitly listed in routing exchanges, which is extra work for the other providers who have to exchange and maintain that info 💀.

in the second case, each other provider (backbone or TRD) just sees a single address prefix for the provider, and that prefix covers the new site 🥳. no extra routing info is needed to identify the new site's prefix. so the advantages mostly go to the other providers who keep routing info about this site and provider 🫶.

one could apply a supplier/consumer model here: the higher level (say, a backbone) is the supplier of routing services, and the lower level (say, a TRD) is the consumer 🛍️. the price charged for services is based on the cost of providing them, and the overhead of managing a big table of addresses for routing to an attached topological entity adds to that cost 💸.

at present, though, the Internet is not a market economy 🙅‍♀️. efficient operation is based on cooperation 🤝. the recommendations below are simple and tractable ways of managing the IPv6 address space that benefit the entire community 🌈.

4.1. Administration of IPv6 addresses within a domain.

if individual hosts grab their IPv6 addresses from a myriad of unrelated IPv6 address spaces 😵, there's effectively no data abstraction beyond what's already built into existing intra-domain routing protocols. for example, say a routing domain uses three independent prefixes, assigned from three different IPv6 address spaces tied to three different attached providers.

this hurts inter-domain routing, especially for the other domains that need to maintain routes to this domain 😩. there's no common prefix that can represent these addresses, so no summarization can happen at the routing domain boundary. when this domain advertises addresses to other routing domains, it has to use an enumerated list of the three individual prefixes.

the number of IPv6 prefixes that leaf routing domains would advertise is on the order of the number of prefixes assigned to the domain. the number a provider's routing domain would advertise is approximately the number of prefixes attached to its client leaf routing domains, and for a backbone that gets summed across all attached providers 📊. this is just barely acceptable in the current Internet, and it's totally intractable for the IPv6 Internet 🚫. a greater degree of hierarchical information reduction is necessary to keep the Internet growing 🌱.

4.2. Administration at the Leaf Routing Domain

as we said before, the greatest degree of data abstraction comes at the lowest levels of the hierarchy 🪜. giving each leaf routing domain (aka a site) a contiguous block of addresses from its provider's address block gives the biggest single increase in abstraction 🚀. from outside the leaf routing domain, the set of all reachable addresses in the domain can be represented by a single prefix, and all destinations reachable within the provider's prefix can be represented by a single prefix too 🌸.

for example, consider a single campus that's a leaf routing domain and would currently need 4 different IPv6 prefixes 😵‍💫. instead, it can get a single prefix that provides the same number of destination addresses 🎯. and since that prefix is a subset of the provider's prefix, it adds zero extra burden to the higher levels of the routing hierarchy 💖.

hosts and routing domains are super close 👯. the routing domain is the only path between a host and the rest of the internetwork, so it makes sense for that relationship to extend to a common IPv6 addressing space too 🫂. so the hosts within a leaf routing domain should take their IPv6 addresses from the prefix assigned to that leaf routing domain 🏠.

4.3. Administration at the Transit Routing Domain

there are two kinds of transit routing domains: direct providers and indirect providers ✌️. most subscribers of a direct provider are domains that act solely as service subscribers (they carry no transit traffic) 🙅. most subscribers of an indirect provider are domains that are themselves service providers 🔁. in present terminology, a backbone is an indirect provider, while an NSFnet regional is an example of a direct provider 🌐. each case gets its own section below 👇.

4.3.1. Direct Service Providers 🎀

in a provider-based addressing plan, direct service providers should use their IPv6 address space to assign IPv6 addresses from a unique prefix to the leaf routing domains they serve 📦. the benefits from data abstraction are greater than in the leaf routing domain case, and this extra degree of data abstraction may be necessary in the short term ⏳.

let's say a direct provider serves 100 clients 🧑‍💻. if each client takes its addresses from 4 independent address spaces, the total number of entries needed to handle routing to these clients is 400 (100 clients times 4 providers) 😱. if each client takes its addresses from a single address space, the total is only 100 entries 🙌. and if all the clients take their addresses from the same address space, the total is only 1 entry ✨.

we expect that in the near term, the number of routing domains in the Internet will grow to the point where routing on the basis of a flat field of routing domains is infeasible 📈. so it'll be essential to provide a greater degree of information abstraction with IPv6 💫.

direct providers may give part of their address space (prefixes) to leaf domains, based on an address prefix given to the provider 🎁. this means direct providers advertise a small fraction of the number of address prefixes they'd otherwise need if they enumerated the individual prefixes of every leaf routing domain 📉. given the expected scale of global internetworking, that's a significant savings 💰.

the efficiencies gained in inter-domain routing clearly warrant the adoption of IPv6 address prefixes derived from the IPv6 address space of the providers 🏆.

Okay so the mechanics here are actually super simple, bestie 🎀 Each direct provider gets a unique small set of IPv6 address prefixes, and its attached leaf routing domains can carve out slightly longer prefixes from that. Like, NIST is a leaf routing domain whose inter-domain link is via SURANet. If SURANet is assigned a unique IPv6 address prefix 43DC:0A21/32, NIST could use a unique IPv6 prefix of 43DC:0A21:7652:34/56. 💅

Okay, what if a direct service provider is hooked up to another provider (direct or indirect, your pick 👑) at multiple attachment points? In some cases it's a total power move for the direct provider to control how traffic headed for a particular subscriber gets tied to those attachment points 😤 The way to do it is to first split all the subscribers into groups, so traffic going to every subscriber in a group flows through one particular attachment point. Once the groups are sorted, the provider's address space gets subdivided along those group boundaries. A leaf routing domain that's cool with taking prefixes from its direct provider gets a prefix from the subdivision tied to its group. 🧚

At the attachment point (between the direct and indirect providers), the direct provider advertises two kinds of prefixes: the big one covering its whole address space, and one or more longer ones for each subdivision. The longer ones match the big one, just more specific 🔍 Because routers use the "longest match" forwarding algorithm (e.g., a router inside the indirect provider), traffic going to those longer prefixes gets forced through the attachment point where they were advertised to the indirect provider. Main character routing, no cap 💜

For example, assume that SURANet is connected to another regional provider, NEARNet, at two attachment points, A1 and A2. SURANet is assigned a unique IPv6 address prefix 43DC:0A21/32. To control the traffic flow headed for a particular subscriber within SURANet, SURANet may subdivide its address space into two groups, 43DC:0A21:8/34 and 43DC:0A21:C/34. The former group may be used for sites attached to SURANet that are closer (as determined by the topology within SURANet) to A1, while the latter group may be used for sites that are closer to A2. The SURANet router at A1 advertises both 43DC:0A21/32 and 43DC:0A21:8/34 address prefixes to the router in NEARNet. Likewise, the SURANet router at A2 advertises both 43DC:0A21/32 and 43DC:0A21:C/34 address prefixes to the router in NEARNet. So traffic flowing through NEARNet to destinations matching the 43DC:0A21:8/34 prefix would enter SURANet at A1, while traffic to destinations matching 43DC:0A21:C/34 would enter SURANet at A2. ✨

Note that the direct provider's advertisement of routing information for each subdivision must be done with care, so it doesn't end up causing a global distribution of separate reachability info for each subdivision, unless that distribution is warranted for some other purpose (e.g., supporting certain aspects of policy-based routing). Be careful, bestie 🥹

4.3.2 Indirect Providers (Backbones) 🦋

ngl, there isn't a strong case right now for direct providers to grab their address space out of the IPv6 space of an indirect provider (like a backbone) 🙅 The routing data abstraction win is pretty small. Today there are tens of direct providers, and an order of magnitude increase wouldn't be an undue burden on the backbones. Also, it's expected that over time, direct providers will interconnect more directly, leaf routing domains will attach straight to the backbones, and international links will attach straight to the providers. Once that happens, the line between direct and indirect providers might get kinda blurry 🌫️

Another thing that makes this a no-go 🚫 is that backbones and their attached providers are seen as independent of each other. A provider can buy long-haul service from one or more backbones, or switch backbones if somewhere else offers a more cost-effective deal 💸 Deriving IPv6 addresses from a backbone prefix just doesn't fit that kind of relationship. It's giving independent contractor energy, not family 💅

4.4 Multi-homed Routing Domains 🌸

So Section 4.3 gave us ways to hand out IPv6 addresses based on whether you're connected through a direct or indirect provider 🧠 For routing domains attached to just one TRD, that means a huge amount of info can get squished down. Those domains can pick their addresses from a space the direct provider delegates to them, so when the provider announces what it can reach to other providers, one prefix can cover a whole pile of IPv6 addresses across multiple routing domains. Compression queen 👑

BUT 😭 routing domains attached to multiple providers come with extra considerations. Multi-homed routing domains could be single-site campuses and companies hooked up to multiple backbones, big orgs attached to different providers at different spots in the same country, or multinational orgs attached to backbones in a bunch of countries worldwide 🌍 Multi-homed means there are a bunch of possible ways to deal with them, and we're about to see some of them.

4.4.1 Solution 1 🎀

One possible solution is for each multi-homed organization to obtain its IPv6 address space independently of the providers it's attached to 🙌 That lets the organization base all of its IPv6 assignments on one prefix, so every IPv6 address reachable inside it can be summarized under a single prefix. The catch? That IPv6 address has no relationship to any particular TRD's addresses, so the TRDs this organization connects to will need to advertise its prefix to other providers. And other providers (potentially worldwide) will need to keep an explicit entry for that organization in their routing tables 😬

Let's say MBII, a very large North American company, has a fully interconnected internal network and is assigned a single prefix as part of the North American prefix. Outside North America, routing tables would probably keep just one entry for all North American Destinations ✈️ But inside North America, every provider needs its own separate address entry for MBII 📇 If MBII is actually international, then every provider worldwide might need a separate entry for MBII, even backbones MBII isn't attached to 😵 Clearly, that's probably fine if there are only a few multi-homed routing domains like this. But if every organization picked this kind of address assignment, the routers in backbones would be stuck with an unacceptable load 🥵 This solution may not scale to internets with many hundreds of thousands of multi-homed organizations. 💀

4.4.2 Solution 2 🦋

okay so the second option is that each multi-homed org gets its own separate IPv6 address space for every connection it has to a TRD 🎀. Then it hands out a single prefix to some subset of its domain(s) based on whichever interconnection point is closest 🧚. Like, say MBII has two providers in the U.S. (one on the east coast and one on the west coast), plus three connections to national backbones in Europe, and one in the far east 🌏. Then MBII may make use of six different address prefixes 💅. Each part of MBII gets one address prefix based on the nearest connection ✨.

For external routing of traffic from outside MBII to a destination inside MBII, this approach works similarly to treating MBII as six separate organizations 👑. For internal routing, or for routing traffic from inside MBII to a destination outside MBII, it works the same as the first solution 💖.

If we assume that incoming traffic (coming from outside MBII, with a destination within MBII) is always going to enter via the nearest point to the destination 🎯, then each TRD that has a connection to MBII needs to announce to the other TRDs that it can reach only those parts of MBII whose address is taken from its own address space. This means no additional routing information needs to be exchanged between TRDs 🙌. So the inter-domain routing tables that TRDs maintain get a much lighter load compared to the first solution. That's why this solution scales better to extremely large internets containing very large numbers of multi-homed organizations 🌈.

bestie, this next part is the big catch 😭

One problem with the second solution is that backup routes to multi-homed organizations are not automatically maintained 🥲. With the first solution, each TRD announcing its ability to reach MBII also specifies that it can reach all of the hosts within MBII. With the second solution, each TRD announces that it can reach all of the hosts based on its own address prefix, which only includes some of the hosts within MBII. So if the connection between MBII and one particular TRD were severed, the hosts within MBII with addresses based on that TRD would become unreachable via inter-domain routing 💀. The impact can be reduced somewhat by maintaining additional information within routing tables, but this reduces the scaling advantage of the second approach 🙈.

The second solution also requires that when external connectivity changes, internal addresses also change 🔄.

Also, note that this approach and the previous one will tend to cause packets to take different routes 🗺️. With the first approach, packets from outside MBII destined for within MBII will tend to enter via the point closest to the source. That tends to maximize the load on the networks internal to MBII 📈. With the second solution, packets from outside destined for within MBII will tend to enter via the point closest to the destination. That tends to minimize the load on the networks within MBII, and maximize the load on the TRDs 🧃.

These solutions also have different effects on policies 🏳️. For example, suppose that country X' has a law that traffic from a source within country X to a destination within country X must at all times stay entirely within the country. With the first solution, it is not possible to determine from the destination address whether or not the destination is within the country 🫠. With the second solution, a separate address may be assigned to those hosts which are within country X', thereby allowing routing policies to be followed ✨.

Similarly, suppose that `Little Small Company' (LSC) has a policy that its packets may never be sent to a destination that is within MBII. With either solution, the routers within LSC may be configured to discard any traffic that has a destination within MBII's address space. However, with the first solution this requires one entry. With the second, it requires many entries and may be impossible as a practical matter 🤯.

4.4.3 Solution 3 🌸

There are other possible solutions as well 🧚‍♀️. A third approach is to assign each multi-homed organization a single address prefix, based on one of its connections to a TRD. Other TRDs to which the multi-homed organization is attached maintain a routing table entry for the organization, but they're super selective about which other TRDs get told about this route 🤫. This approach produces a single `default' routing entry which all TRDs will know how to reach (since presumably all TRDs will maintain routes to each other), while providing more direct routing in some cases 🚀.

There is at least one situation where this third approach is particularly appropriate 🍓. Suppose a special interest group of organizations has deployed their own provider. For example, let's suppose the U.S. National Widget Manufacturers and Researchers have set up a U.S.-wide provider, which is used by corporations that manufacture widgets and certain universities known for their widget research 🧸. We can expect the various organizations in the widget group to run their internal networks as separate routing domains, and most of them will also be attached to other TRDs (since most of the organizations involved in widget manufacture and research will also be involved in other activities 🙃). We can therefore expect that many or most of the organizations in the widget group are dual-homed, with one attachment for widget-associated communications and the other for other types of communications. Let's also assume that the total number of organizations in the widget group is small enough that it's reasonable to maintain a routing table with one entry per organization, but that they're distributed throughout a larger internet with many millions of (mostly not widget-associated) routing domains 🌍.

With the third approach, each multi-homed organization in the widget group would make use of an address assignment based on its other attachment(s) to TRDs (the attachments not associated with the widget group) 💼. The widget provider would need to maintain routes to the routing domains associated with the various member organizations 🛤️. Similarly, all members of the widget group would need to maintain a table of routes to the other members via the widget provider 🤝. However, since the widget provider does not inform other general worldwide TRDs of what addresses it can reach (because the provider is not intended for use by other outside organizations), the relatively large set of routing prefixes only needs to be maintained in a limited number of places 🔒. The addresses assigned to the various member organizations would provide a `default route' via each member's other attachments to TRDs 🛣️, while allowing communications within the widget group to use the preferred path 🏆.

4.4.4 Solution 4 🧩

A fourth solution involves assignment of a particular address prefix for routing domains which are attached to precisely two (or more) specific routing domains 👯. For example, suppose there are two providers SouthNorthNet' and NorthSouthNet' which have a very large number of customers in common (i.e., there are a large number of routing domains which are attached to both). Rather than getting two address prefixes, these organizations could obtain three prefixes 🎁. Those routing domains which are attached to NorthSouthNet but not attached to SouthNorthNet obtain an address assignment based on one of the prefixes. Those routing domains which are attached to SouthNorthNet but not to NorthSouthNet would obtain an address based on the second prefix. Finally, those routing domains which are multi-homed to both of these networks would obtain an address based on the third prefix. Each of these two TRDs would then advertise two prefixes to other TRDs: one prefix for leaf routing domains attached to it only, and one prefix for leaf routing domains attached to both 📣.

This fourth solution is likely to be important when use of public data networks becomes more common 📶. In particular, it is likely that at some point in the future a substantial percentage of all routing domains will be attached to public data networks 🌐. In this case, nearly all government-sponsored networks (such as some current regionals) may have a set of customers which overlaps substantially with the public networks 🫶.

4.4.5 Summary 📚

There are therefore a number of possible solutions to the problem of assigning IPv6 addresses to multi-homed routing domains 🫧. Each of these solutions has very different advantages and disadvantages. Each solution places a different real (i.e., financial) cost on the multi-homed organizations, and on the TRDs (including those to which the multi-homed organizations are not attached) 💸.

In addition, most of the solutions described also highlight the need for each TRD to develop a policy on whether and under what conditions to accept addresses that are not based on its own address prefix, and how such non-local addresses will be treated 📝. For example, a somewhat conservative policy might be that non-local IPv6 address prefixes will be accepted from any attached leaf routing domain, but not advertised to other TRDs 🧐. In a less conservative policy, a TRD might accept such non-local prefixes and agree to exchange them with a defined set of other TRDs. This set could be an a priori group of TRDs that have something in common, such as geographical location, or the result of an agreement specific to the requesting leaf routing domain 🤙. Various policies involve real costs to TRDs, which may be reflected in those policies 💰.

4.5 Private Links 🔐

The discussion up to this point concentrates on the relationship between IPv6 addresses and routing between various routing domains over transit routing domains 🚉, where each transit routing domain interconnects a large number of routing domains and offers a more-or-less public service 🌆.

However, there may also exist a number of links which interconnect two routing domains in such a way that usage of these links may be limited to carrying traffic only between the two routing domains 🫣. We'll refer to such links as "private" 💜.

For example, let's suppose that the XYZ corporation does a lot of business with MBII 💼. In this case, XYZ and MBII may contract with a carrier to provide a private link between the two corporations. This link may only be used for packets whose source is within one of the two corporations, and whose destination is within the other of the two corporations 🫂. Finally, suppose that the point-to-point link is connected between a single router (router X) within XYZ corporation and a single router (router M) within MBII. It is therefore necessary to configure router X to know which addresses can be reached over this link (specifically, all addresses reachable in MBII) 🛠️. Similarly, it is necessary to configure router M to know which addresses can be reached over this link (specifically, all addresses reachable in XYZ Corporation) 💅.

The big takeaway here is that the extra connectivity from private links can just be ignored for IPv6 address allocation 💅 and it doesn't cause routing problems at a larger scale ✨. Why? The routing info for those links never gets propagated around the internet, so it doesn't need to be squished into a TRD's prefix 🦋.

Picture this: XYZ corp has a single connection to a regional 🌸, so it uses IPv6 address space from the block given to that regional. MBII is an international corp with connections to six different providers 🌍, and it went with the second solution from Section 4.4, so it got six separate allocations. Result: every address reachable in XYZ can be described by a single address prefix 💖, which means router M only needs one prefix configured to represent the addresses reachable over this link. Every address reachable in MBII can be described by six address prefixes, so router X needs six prefixes configured to cover the addresses reachable over the link 🎀.

Sometimes those private links are allowed to forward traffic for a small number of other routing domains, like closely affiliated orgs 🤝. That bumps up the config needs a little, but as long as the number of orgs using the link is pretty small, it's still not a big deal 🙈.

The routing-and-addressing relationship we talked about elsewhere is about scaling problems caused by big, basically public transit routing domains that interconnect a ton of routing domains 🌐. But for address allocation, private links that only interconnect a few private routing domains don't cause problems and can be ignored 🫶. For example, a single leaf routing domain with one connection to a `public' provider (like the Alternet) plus a bunch of private links to other leaf routing domains can be treated as if it were single-homed to that provider for address allocation. We expect this is also another way of dealing with multi-homed domains 💜.

4.6. Zero-Homed Routing Domains 🧚

Right now a LOT of orgs have internal communications networks that aren't connected to any service providers 🏠. They might still have private links with other orgs, though. These orgs don't take part in global routing, but they're totally happy being able to reach the orgs they have private links with 💅. These are called zero-homed routing domains 🌙.

Zero-homed domains are basically the degenerate case of routing domains with private links (from the section above), and they don't pose a problem for inter-domain routing 🦋. The routing info swapped over private links barely gets distributed, usually only to the routing domain at the other end of the link. So there are no address abstraction requirements beyond the ones already inherent in the address prefixes exchanged across the private link ✨.

BUT it's important that zero-homed routing domains use valid globally unique IPv6 addresses 🚨. Say a zero-homed domain is connected through a private link to a routing domain, and that routing domain is part of an internet that subscribes to the global IPv6 addressing plan. That routing domain must be able to tell the zero-homed domain's IPv6 addresses apart from any other IPv6 addresses it may need to route to 😭. The only way to guarantee that is if the zero-homed domain uses globally unique IPv6 addresses 💖.

Globally unique addresses are necessary to tell destinations apart on the Internet, but they may not be sufficient to guarantee global connectivity 🌍. If a zero-homed domain gets connected to the Internet, the block of addresses used inside the domain may not be related to the block allocated to the domain's direct provider. To keep the gains from hierarchical routing and address assignment, the zero-homed domain should, in that situation, change the addresses assigned to the systems within the domain 🔥.

4.7. Continental aggregation 🌎

Another level of hierarchy can be used in this addressing scheme to further cut down the routing info needed for global routing 🗺️. Continental aggregation works because continental boundaries are natural barriers to topological connection and administrative boundaries 🧱, which makes them a natural spot for another level of aggregating inter-domain routing info 💅. To make it work, each continent needs its own appropriate contiguous block of addresses, and providers (both direct and indirect) within that continent allocate their addresses from that space 🌸. There are lots of exceptions where a service provider (direct or indirect) spans a continental division 🙃. Those can be handled similarly to multi-homed routing domains, as we covered above 💜.

The benefit is that it helps absorb the entropy introduced within continental routing, caused by cases where an org has to use an address prefix that must be advertised beyond its direct provider 🌀. In those cases, if the address comes from the continental prefix, the extra cost of the route isn't propagated past the point where continental aggregation takes place ✨.

Here's the twist 🤓: the aggregation of continental routing info may not be done on the continent the prefix is allocated to. The cost of inter-continental links (and especially trans-oceanic links) is very high 💸. If aggregation is performed on the 'near' side of the link, then routing info about unreachable destinations within that continent can only reside on that continent 🏝️. Alternatively, if continental aggregation is done on the 'far' side of an inter-continental link, the 'far' end can perform the aggregation and inject it into continental routing 🚀. This means destinations that are part of the continental aggregation, but have no corresponding more specific prefix, can be rejected before leaving the continent they originated on 🙅.

For example, suppose Europe is assigned 46/8, so European routing also contains the longer prefixes 46DC:0A01/32 and 46DC:0A02/32 🇪🇺. All of the longer European prefixes may be advertised across a trans-Atlantic link to North America. The router in North America then aggregates these routes and only advertises 46/8 into North American routing 🗽. Packets destined for 46DC:0A01:1234:5678:ABCD:8765:4321:AABB would traverse North American routing, but would hit the North American router that performed the European aggregation. If the prefix 46DC:0A01/32 is unreachable, that router drops the packet and sends an unreachable message without using the trans-Atlantic link ✈️.

4.8. Private (Local Use) Addresses 🙈

Lots of domains have hosts that, for one reason or another, won't require globally unique IPv6 addresses 🏡. A domain that decides to use IPv6 addresses out of the private address space can do so without address allocation from any authority 💅. The flip side is that the private address prefix doesn't need to be advertised throughout the public part of the Internet ✨.

To use private address space, a domain needs to figure out which hosts won't need network layer connectivity outside the domain in the foreseeable future 🔍. Those are called private hosts, and they may use the private addresses described above if it's topologically convenient 🧩. Private hosts can communicate with all other hosts inside the domain, both public and private. However, they can't have IPv6 connectivity to any external host 🚫. While they don't have external network layer connectivity, a private host can still reach external services through application layer relays 🫶. Public hosts don't have connectivity to private hosts outside their own domain 🔒.

Since private addresses have no global meaning, reachability information associated with the private address space shall not be propagated on inter-domain links, and packets with private source or destination addresses should not be forwarded across such links 🚧. Routers in domains not using private address space, especially those of Internet service providers, are expected to be configured to reject (filter out) routing information that carries reachability information associated with private addresses 🙅. If such a router receives such information, the rejection shall not be treated as a routing protocol error 💅.

Indirect references to private addresses should also be contained within the enterprise that uses them 🔐. The prominent example is DNS Resource Records (RRs) 🧾. A possible approach to avoid leaking DNS RRs is to run two nameservers: one external server authoritative for all globally unique IP addresses of the enterprise, and one internal nameserver authoritative for all IP addresses of the enterprise, both public and private 🧠. To ensure consistency, both servers should be configured from the same data, though the external nameserver only receives a filtered version 🪞. The resolvers on all internal hosts, both public and private, query only the internal nameserver 🏠. The external server resolves queries from resolvers outside the enterprise and is linked into the global DNS 🌐. The internal server forwards all queries for information outside the enterprise to the external nameserver, so all internal hosts can still access the global DNS 🚪. This ensures that information about private hosts never reaches resolvers and nameservers outside the enterprise 💜.

4.9. Interaction with Policy Routing 🎀

We assume that any inter-domain routing protocol will have difficulty trying to aggregate multiple destinations with dissimilar policies 😵. At the same time, the ability to aggregate routing info without violating routing policies is essential 🔑. So we suggest that address allocation authorities attempt to allocate addresses so that aggregates of destinations with similar policies can be easily formed 💖.

5. Recommendations 👑

We expect the current exponential growth of the Internet will continue or accelerate for the foreseeable future 📈. We also expect a rapid internationalization of the Internet 🌏. Routing's ability to scale depends on data abstraction based on hierarchical IPv6 addresses, so it's essential to choose a hierarchical structure for IPv6 addresses with great care 💎.

Great attention must be paid to the definition of addressing structures to balance the conflicting goals of: 🧘

Route optimality
Routing algorithm efficiency
Ease and administrative efficiency of address registration
Considerations for what addresses are assigned by what addressing authority 📋

It's in everyone's best interest to keep operations costs as low as possible where we can 💸. For IPv6 address allocation, that means routing data abstraction has to be encouraged, bestie 🫶

For abstraction to even be possible, IPv6 addresses have to be assigned in a way that matches the actual physical topology of the Internet. So if organizational and administrative boundaries don't line up with real network topology, assigning addresses based on those org boundaries is not recommended 🙅‍♀️

The intra-domain routing protocols let information abstraction stay inside a domain 🧚. For zero-homed and single-homed routing domains (the ones expected to stay zero-homed or single-homed), we recommend that the IPv6 addresses assigned inside a single routing domain use a single address prefix assigned to that domain. This lets the set of all IPv6 addresses reachable inside a single domain be fully described by one prefix 💅

We anticipate that the total number of routing domains on a worldwide Internet will be great enough that additional levels of hierarchical data abstraction beyond the routing domain level will be necessary 🌍

Network topology usually has a close relationship with national boundaries 🗺️. The degree of connectivity is often greater within one country than between countries. So it's appropriate to make specific recommendations based on national boundaries, with the understanding that there may be specific situations where these general recommendations need to be modified 🤷‍♀️

Also, from experience with IPv4, we feel continental aggregation is beneficial and should be supported where possible as a way to limit the unwarranted spread of routing exceptions 🌈

5.1. Recommendations for an address allocation plan ✨

We anticipate that public interconnectivity between private routing domains will be provided by a diverse set of TRDs, including (but not necessarily limited to):

Backbone networks;
A number of regional or national networks; and,
A number of commercial Public Data Networks.

These networks won't be interconnected in a strictly hierarchical manner. For example, there's expected to be direct connectivity between regionals, and all of these types of networks may have direct international connections 🕸️. These TRDs will be used to interconnect a wide variety of routing domains, each of which may comprise a single corporation, part of a corporation, a university campus, a government agency, or other organizational unit 🏫

In addition, some private corporations may be expected to make use of dedicated private TRDs for communication within their own corporation 🏢

We anticipate that the great majority of routing domains will be attached to only one of the TRDs. This permits hierarchical address aggregation based on TRD, so we strongly recommend that addresses be assigned hierarchically, based on address prefixes assigned to individual TRDs 💖

To support continental aggregation of routes, we recommend that all addresses for TRDs which are wholly within a continent be taken from the continental prefix 🌸

For the proposed address allocation scheme, this implies that portions of IPv6 address space should be assigned to each TRD (explicitly including the backbones and regionals). For those leaf routing domains connected to a single TRD, they should be assigned a prefix value from the address space assigned to that TRD 🎀

For routing domains which are not attached to any publicly available TRD, there isn't the same urgent need for hierarchical address aggregation. So we don't make any additional recommendations for such `isolated' routing domains. Where such domains are connected to other domains by private point-to-point links, and those links are used solely for routing between the two domains they interconnect, no additional technical problems relating to address abbreviation are caused by such a link, and no specific additional recommendations are necessary. We do recommend that, since such domains may wish to use a private address space, the addressing plan specify a specific prefix for private addressing 🔒

Further, to allow aggregation of IPv6 addresses at national and continental boundaries into as few prefixes as possible, we further recommend that IPv6 addresses allocated to routing domains should be assigned based on each routing domain's connectivity to national and continental Internet backbones 👑

5.2. Recommendations for Multi-Homed Routing Domains 🦋

Some routing domains will be attached to multiple TRDs within the same country, or to TRDs within multiple different countries. We refer to these as `multi-homed' routing domains. Clearly, the strict hierarchical model discussed above doesn't neatly handle these routing domains 🌀

There are several possible ways these multi-homed routing domains may be handled, as described in Section 4.4. Each of these methods varies with respect to the amount of information that must be maintained for inter-domain routing, and also with respect to the inter-domain routes. The organization that bears the brunt of this cost also varies with the possible solutions. For example, the solutions vary with respect to:

Resources used within routers within the TRDs;
Administrative cost on TRD personnel; and,
Difficulty of configuration of policy-based inter-domain routing information within leaf routing domains.

The solution used may also affect the actual routes packets follow, and may affect the availability of backup routes when the primary route fails 🛟

For these reasons, it's not possible to mandate a single solution for all situations. Instead, economic considerations will require a variety of solutions for different routing domains, service providers, and backbones 💅

6. Security Considerations 🙈

Security issues are not discussed in this document. Not this one, bestie 💀

7. Acknowledgments 💜

This document is largely based on RFC 1518. The section on Private Addresses borrowed heavily from RFC 1597.

We'd like to thank Havard Eidnes, Bill Manning, and Roger Fajman for their review and constructive comments 🫶

REFERENCES 🎀

[1] Deering, S., and R. Hinden, Editors, "Internet Protocol, Version 6 (IPv6) Specification", RFC 1883, Xerox PARC, Ipsilon Networks, December 1995.
[2] Hinden, R., and S. Deering, Editors, "IP Version 6 Addressing Architecture", RFC 1884, Ipsilon Networks, Xerox PARC, December 1995.

AUTHORS' ADDRESSES 🧚

Yakov Rekhter
cisco Systems, Inc.
470 Tasman Dr.
San Jose, CA 95134

Phone: (914) 528-0090
EMail: yakov@cisco.com

Tony Li
cisco Systems, Inc.
470 Tasman Dr.
San Jose, CA 95134

Phone: (408) 526-8186
EMail: tli@cisco.com

📦 where this page comes from

ietf: rfc1887 1995-12
💖 girlified by claude-haiku-5-5 on 2026-10-15: a language model's rewrite of the original, under its terms