Re: [v6ops] Deaggregation by large organizations

[Owen DeLong <[e-mail]>]

On Oct 15, 2014, at 05:29 , Iljitsch van Beijnum <[e-mail]> wrote:

> We are all familiar with PA (provider aggregatable) and PI (provider independent) address space. But it turns out a new type of IPv6 address space is starting to show up, which I'll call organization deaggregatable (OD) address space (until someone suggests a better name).
> 
> How it works is like this: a large organization obtains a large block of IPv6 address space, either as a very large PI block or by becoming a local internet registry (LIR) and getting a regular LIR assignment directly from one of the five regional registries. However, rather than advertising that block in BGP as a single prefix, or perhaps a handful of prefixes, like an ISP would, they subdivide this block within the organization and then many subunits advertise subprefixes though different ISPs. The aggregate may or may not be advertised.
> 
> The advantage to the organization is that they have provider independent address space that they'll never have to renumber out of, as well as having a single prefix that identifies all of the organization, which makes filtering easy.
> 
> There seem to be two types of organizations that do this: geographically dispersed ones that advertise subprefixes in different locations, such as multinationals, and organizations with very independent subunits but with more limited geographical scope, such as national governments.
> 
> This practice, especially if/when it becomes more common, presents two challenges:
> 
> 1. Large numbers of prefixes may show up in the global routing table. For instance, there is a number plan for all of the German government, which could potentially inject more than 5000 municipality prefixes into the global IPv6 routing table.

How would this differ from 500 multihomed municipal governments getting PI space?

> 2. Filtering. If people want to avoid large numbers of deaggregates in their routing tables, they may employ some kind of filtering, especially if the deaggregates are very long prefixes. This means that packets are no longer reliably delivered to the place announcing a more specific prefix.

I would think that if/when this becomes an issue, the organizations engaging in the behavior will take the necessary steps to get the traffic they care about.
Seems to me that this is the desirable situation as some form of equilibrium will be reached where organizations limit their deaggregates to something they can get adequately routed and operators will limit their routing tables to something they can handle.

> Ideally, a set of best practices would be developed that strike a good balance between the needs of large organizations and the needs of the global routing system, and allow everyone to predict the consequences of different kinds of behavior and thus avoid unpleasant surprises.

Hard to develop a set of best practices for this that would have any real longevity. The boundary between usable routing table maximum size and oblivion is a moving target. We don't have sufficient experience with this problem in the IPv6 space to really know how far it will extend.

> These are some of the things that could go into such best practices:
> 
> - A well-understood maximum prefix length for IPv6, similar to /24 for IPv4.

I don't think this helps. The /48 seems to pretty much already be there as a de-facto answer to this question. However, 2^45 routes (unicast is a /3) is probably beyond the capability of any router yet available.

> - An understanding of how the service providers that provide connectivity to multiple subunits of a large organization can work together in order to maximize availability and minimize costs for the organization, the service providers and other network operators.

If you can find answers to this question, they would certainly be beneficial to the community, but I think that scope extends well beyond the deaggregation issue described here and that would be only one aspect of such a document.

> - A way to provide a point of last resort where traffic for the aggregate can be sent to if more specifics are filtered.

There are many ways to do this. Ranging from the simple build a network of tunnels between your sites and anchor the aggregate as a less specific from a few key sites to much more elaborate solutions. These solutions seem to me to be reasonably well known to most network engineers. I don't think a document rehashing them in yet another place is of any particular benefit.

> - A set of communities that indicate whether a prefix is a more specific that is covered by an aggregate and/or is safe to filter without loss of connectivity.

This seems like a reasonably good idea... If you write up an ID for v6ops to do this one simple thing, I would support it.

> - A set of communities that indicate geographical origin of prefixes so remote more specific prefixes can be filtered while local prefixes are kept.

Since geography != topology (and dramatically so in some cases), I think this would do more harm than good in many cases.

> - Guidelines for reserving address space in address plans. Is it better to have free space reserved so existing prefixes can grow, or keep reserved space together so tight prefix length filters are possible and reserved space isn't broken up into small pieces?

There are many documents describing various ways to do sparse allocation and allocation by bisection for IPv6. I have written some that have achieved some distribution. RIPE has one or two at least. I don't think having the IETF rewrite yet another one is particularly useful.

> Please note that I'm crosspositing this to v6ops and grow initially. If the chairs have any guidance on which working group is more appropriate for this discussion, please let us know and we can drop the other one.

The one tidbit that strikes me as useful is, IMHO, something that belongs in v6ops. YMMV.

> Last but not least, this treads on RIR policy. But in my opinion, this is foremost a technical matter with global implications and as such is best discussed within the IETF rather than in the five respective policy development forums.

I don't think anything proposed above really treads on RIR policy. It makes recommendations for utilization of address space by end-user organizations, but does not make any attempt to set policy for how those addresses are acquired or what amount of space should be granted in response to such a request.

I'm pretty sure I'm one of the most RIR-oriented people on the planet in any such discussion, so I think you're safe in that regard. (I was, after-all, the leader of the original RIR rebellion against oppressive IETF policies regarding PI for end-users in IPv6).

Owen