Let's start with a brief summary. Remember that, for most network engineers and architects, the word “site” has very tangible associations with the physical location of certain specific networks: data centers, campuses with LAN networks, remote offices, etc. Since both the size and number of users supported by the networks in each of these locations varies, it is natural to try to categorize them based on these characteristics, for example, small, medium, large, extra-large. It turns out that the scarcity of IPv4 addresses makes this categorization vitally important. The IPv4 prefixes available to assign to a site may be few and limited in size. A small remote office might only need /28 IPv4 addresses, while a campus LAN might need /20. Hopefully our small, medium, large, and extra-large sites could have at least enough consistent size prefixes available for each size category. For example:

Realistically, in most enterprises, the availability of private IP address space (i.e. RFC 1918) is so limited that even this minimal consistency is often impossible. The result is site prefixes of varying lengths that are difficult—if not impossible—to easily summarize for routing or to simplify security access control lists (ACLs). 

In comparison, the abundance of IPv6 allows a site to be assigned a consistently sized IPv6 prefix—a “one-size-fits-all” prefix—(for example, a /48 or larger prefix) regardless of the physical size of the site, the diameter of the networks , the number of users, etc. The uniformity of such assignments to sites makes it much easier to summarize routing and simplify ACLs. This consistency can also further simplify the management and operation of networks, especially considering that the recommended IPv6 prefix size should always be nibble-aligned. The unique part of a network's nibble-aligned prefix can be used to identify the site more easily, which helps in managing or troubleshooting a network.

First, we will show the method of assigning the next available prefix and its limitations. The following graphic shows an initial addressing plan with allocations of one /48 prefix per site. Each site prefix is ​​assigned sequentially from a /44 providing up to 16 sites in total.

Note that, in the example, this total number of available prefixes decreases to 15 because we have omitted the use of the first available prefix of 2001:db8:1000::/48. This is done to align the site number with the prefix numbering (for example, Site 1 = 2001:db8:1001::/48, Site 2 = 2001:db8:1002::/48). This can also help not to confuse two prefixes that, due to rules for compressing IPv6 address notation, may appear identical, but have different CIDR lengths (for example, 2001:db8:1000::/44 and 2001: db8:1000::/48). 

But what should happen when a site grows or changes in a way that requires additional IPv6 space? And how can we plan to provide additional space while maintaining the planning practices that offer the greatest operational benefits? We wouldn't want to have to renumber our site to try to extend the use of the single assigned /48 site prefix, especially when a large enough general distribution should provide enough /48s to allow one or more prefixes to be added to an existing site. But if we don't plan properly, the additional /48s may not be contiguous with the initial distribution of a /48 site prefix. This lack of contiguity is not necessarily the end of the world, but it could lead to more (and earlier) unbundling of the IPv6 address space within the network. Being able to always identify a site by a single prefix that is summarized in the routing table and that has a single security boundary (and an associated ACL entry) has clear operational and administrative benefits.

One way to ensure that contiguous /48 prefixes are available is to reserve them in advance, ideally at the same time as the initial addressing plan is designed. But how many additional /48s should be reserved per site? The lower limit is obviously an additional /48. Any additional /48 prefix reserved up to the first nibble could only be summed along a non-nibble boundary. But any attempt to add additional /48s only when each site needs them and then summarize as much as possible will generate a collection of different prefixes summarized for different sites. These summarized prefixes would not be as readable in a routing table as a single nibble-aligned prefix for each site. 

Let's look at an example. The following graph shows future assignments of /48 prefixes to our original sites based on the next available prefix distribution method . Site 4 is the first to request additional IPv6 space [for example, for an out-of-band (OOB) overlay network] and is assigned the next available prefix of 2001:db8:1004::/48. Some time later, Site 4 adds a data center that will need its own /48 and is assigned the next available prefix of 2001:db8:1005::/48. Site 1 learns about the OOB overlay network that Site 4 deployed and wants to do the same. So it is assigned the next available prefix of 2001:db8:1006::/48. The same happens with Site 3: it is assigned the next available prefix of 2001:db8:1007::/48. Now Site 4 realizes that it has to add another data center, but this time with greater support for multiple clients, so it is assigned the following two available prefixes: 2001:db8:1008::/48 and 2001 :db8:1009::/48. As a result of these asynchronous requests for IPv6 prefixes being satisfied by assigning the next available prefix, the routing table and/or ACL entries are a bit confusing (and will probably become even more confusing when this method is applied again). 

So if it is better to use a single nibble-aligned prefix, which prefix should we use? One way to answer this question would be to think about what might be a reasonable upper limit for the number of additional /48s per site. It should be noted that this would be the upper limit for the largest of our sites (whatever their size, all other sites will receive the same allocation as the largest site). The next largest prefix aligned to nibble is a /44, which provides a total of 16 /48 prefixes: an initial /48 assigned to the site and 15 /48 prefixes that are held in reserve. A /40 would provide 256 /48 prefixes (or 255 spare /48 prefixes). A /36 would provide a reserve of 4095 /48 prefixes.
 
So which of the largest nibble-aligned prefixes should we select for our largest site? The reality is that knowing in advance how much additional prefix space may be necessary and/or useful is difficult, if not impossible. We must keep in mind that the more prefixes we keep in reserve for each site, the greater the consumption of our general distribution. This could reduce the ability to create additional structure on top of our address plan. For example, perhaps we should have enough prefixes to allow regional summarization on a nibble boundary for a prefix that summarizes sites. Or perhaps we need to hold nibble-aligned prefixes in reserve for future use at the top level of the address plan (for example, the first 16 nibble-aligned prefixes derived from the general IPv6 distribution). But for now, let's continue looking at how to best size allocations for our sites.

The following graph shows an alternative, more optimal result based on our previous example. Instead of initially allocating a single /48 per site, a /44 is distributed per site. For this example, it is not planned to add more than 16 total sites in Region 1, so a /40 is distributed from which a /44 prefix is ​​taken per site. Now, when each site needs additional /48 prefixes—whatever the purpose—up to 15 additional prefixes will be available. These additional /48 prefixes per site will always be summarized as a /44 for Region 1, and Region 1 will sum them upstream as a /40.

Keep in mind that the regional assignment of a /40 that we showed above was only to exemplify a nibble-aligned summary of /44 site prefixes. It is based on the assumption that, for the example network, you already find it beneficial to manage the network using a geo-based topology. In contrast, some networks are large enough that a single site can benefit from a /40 allocation, followed by one or more initial /48 allocations. In that case, any desired regional summarization could ideally take place at the next longest nibble boundary of a /36.

Whatever the case, it is clear that using this dispersed distribution method to allocate to sites within the enterprise may require a larger distribution of IPv6. This is especially true when following address planning best practices, which recommend maintaining strict nibble alignment for IPv6 prefix assignments. Many companies that have already received IPv6 distributions may conclude that the size of such allocations will not simultaneously support a sparse distribution for site allocations and/or strict nibble alignment of IPv6 prefixes.

Luckily, getting a larger distribution from any of the five Regional Internet Registries (RIRs) that correspond to your primary operating region is a relatively easy and inexpensive process. Also note that no matter what your on-premises network requirements are for IPv6 address space, you will also need to consider your current and planned cloud deployment needs (perhaps using BYOIPv6). For security reasons (or even just administrative ease), it might be wise to keep one or more address spaces outside of (but perhaps in parallel with) your in-place IPv6 address space . And don't forget to consider future networks that will be added due to potential mergers and acquisitions. While it is always possible to obtain additional IPv6 address space, future distributions will likely not be contiguous with your initial distribution and may increase the risk of having to renumber. This is especially true if you are trying to “make do” with the initial IPv6 distribution you received years ago.

Link: https://blog.lacnic.net/ipv6/los-beneficios-de-asignar-mas-de-un-48-por-sitio