[bcop] Deaggregation by large organizations

Let me address a few points that were brought up by different people, mostly on the v6ops and grow lists.

Renumbering:

We had great plans for making renumbering easy in the early days of IPv6. Remember A6 records and bitlabels in the DNS? But none of that went anywhere. The problem isn't so much that we can't push a prefix down the network or update the DNS (although both of these still have challenges associated with them), but that addresses tend to get hardcoded all over the place, starting with firewalls all the way up to homegrown applications. I don't think renumbering addresses this issue, although it could help steer some smaller organizations away from PI.

A prefix length limit for the IPv6 DFZ:

Someone mentioned that this didn't work in IPv6. When Sprint decided to make that /18, that didn't really work. But there's a de facto /24 limit that everyone understands. With IPv6, that would translate into a /48. Obviously no router can hold 2^48 or 2^45 prefixes, so as a backstop against accidental/malicious IPv6 routing table explosion this doesn't help. Even exploding a /28 or so into individual /48s would kill the IPv6 DFZ.

What COULD work is to have prefix length limits depending on the allocation size by the RIRs. Something like:

2100::/16 -> /48
2200::/16 -> /32
2200::/15 -> /29

However, for this to work well the RIRs would have to group allocations of the same size into separate blocks, with the result that it would no longer be possible to reserve space to grow an allocation. (Things like allocating a /48 but reserving a /44 reduce the opportunities for prefix length filtering because now the strictest filter you can make allows 16 x as many prefixes worst case than average case. The worst and average case need to be as close together as possible.)

I'd say that allowing two or three extra bits for traffic engineering for PA blocks would be good. So for the part of the IPv6 space where /29s are allocated, allow /31s or /32s. As traffic engineering incoming traffic by deaggregation requires that different parts of the aggregate all generate similar levels of incoming traffic, this wouldn't usually work for organizations using PI so I'd say don't allow deaggregating below /48.

Geographic communities:

I know this is controversial. "Topology ain't geography". Actually, most of the time there is a significant correlation. If all German cities inject a more specific, do you really need to hear those in Tokyo or Seattle? Just send the traffic to Europe as per the aggregate and let them figure it out there.

Compiling a list of communities that identify regions/countries/cities would allow for experimentation in this place without any downsides that I can see. Don't like this? Filter the communities. There's a handy list that you can copy and paste into your filter.

Injecting an aggregate as a point of last resort:

I think this can be done today and probably is done today. But a document describing how to do it would probably be helpful. I'm thinking along the following lines:

The AoLR (Aggregate of Last Resort) service would entail a service provider announcing the aggregate without necessarily providing connectivity towards all the places announcing more specifics covered by the aggregate. So if ISP A announces the AoLR and ISP B provides connectivity to a more specific, ISP C would send traffic to A as per the aggregate and then A would immediately hand it over to B.

So as part of the AoLR service, a service provider would agree to accept all more specifics that fall under the aggregate (up to an agreed prefix length) from all the networks providing connectivity towards those more specifics. This would be an attractive service for tier-1s to provide, because presumably, they peer with everyone everywhere, so in the case where they receive the traffic over peering and need to deliver it to another service provider over peering, this could probably happen in the same city, so they wouldn't carry the traffic over long distances. But the (sub-)organization(s) in question still gets to buy connectivity from a wider range of smaller service providers.

In practice an organization would contract two or more service providers to provide the AoLR service for redundancy.

Wouldn't they just get PI:

Yes. That's why I think it's important to find a way to give these organizations what they need in a way that keeps the IPv6 DFZ growth on a workable trajectory.

AS numbers:

BGP assumes that an AS always has internal connectivity. This can be accomplished using tunnels, but it's much better to simply have separate AS numbers for each subunit. Would it make sense to allocate ranges of AS numbers to enterprise LIRs? Certainly with 32-bit AS numbers there's no lack of numbers, and this would allow tools to be developed to work on CIDR-like AS number ranges in the future.