[ppml] Practical alternatives to v6 deaggregation for ISP/NSPs

I've brought this up a long while back, and while we got some  
interesting discussion... I still don't have a solution to this for  
our network. Bringing this up to some other operators with similar  
networks who haven't even begun to deploy v6 has brought out comments  
like "I'm totally screwed if that's the case, that would require  
changing my network and/or business model."

For simplicity, I'll describe the (slightly modified for simplicity's  
sake) case of my own network, and I'd love some suggestions for  
alternatives. I'm pretty much stuck with not being able to deploy v6  
any further until I get some kind of resolution to this, so any advice  
would be appreciated. If policy changes are necessary because  
situations like this weren't known when some of the original v6  
allocation/use policies were created, I'd like to solicit this  
community's opinions before proposing changes.

Some may ask why this is a discussion for ARIN at all. ARIN's policies  
strongly suggest that v6 space isn't to be deaggregated at all:

6.3.8 "In IPv6 address policy, the goal of aggregation is considered  
to be the most important."

6.4.3 "RIRs will apply a minimum size for IPv6 allocations, to  
facilitate prefix-based filtering. The minimum allocation size for  
IPv6 address space is /32."

and most importantly:

6.5.1.1 "advertising that connectivity through its single aggregated  
address allocation"

Based off this (and other RIR's policies) many networks are already  
filtering on RIR assignment boundaries - meaning if you get a /32, you  
won't be heard from a sizable chunk of the internet if you announce  
less than that.


Our network:

Consists of several unconnected geographically separate Points of  
Presence.
Each POP has peering and transit through different upstreams than the  
others. There is no single transit provider that has service in all  
the locations we're in.


What we do now in v4:

We have a /19.
One /24 is reserved for anycast, and announced from all our POPs.
One /23 is announced at each POP.

This works really well for us. Nearly everyone will accept  
announcements down to a /24, and for those that don't we announce the  
full /19 as well.


In v6:

We have a /32.
We cannot deaggregate this at all.

This causes the problem that I can't direct incoming traffic to the  
correct POP.


Possible solution #1 - Deaggregate to our upstreams and let them sort  
it out.

Some people suggested that I announce the full /32, and announce  
deaggregates with no-export set to my upstreams to let them direct  
inbound traffic to the correct POP. If I had all the same transit  
providers at every POP, I could announce the /32 to them and announce  
a /36s per POP. This breaks if you have a transit provider that isn't  
connected to *every* POP I have. As an example, assume I have transit  
provider A at my POP in NYC, and transit provider B at my POP in Los  
Angeles.

To Provider A I announce at our connection in NYC:

2001:1234::/32       (covering prefix for my whole space)
2001:1234:1000::/36  (space I'm using only in NYC)

To Provider B I announce at our connection in Los Angeles:

2001:1234::/32       (covering prefix for my whole space)
2001:1234:2000::/36  (space I'm using only in Los Angeles)

This works until Provider B receives a packet destined for  
2001:1234:1000::/36. They haven't received that /36 route (since it's  
smaller than the /32 RIR boundry, and a network between A and B is  
filtering it out), so they deliver it to me in Los Angeles because of  
the /32. That either causes a routing loop between us, or I'm forced  
to tunnel it back to New York.


Possible solution #2 - Get more address space.

A few suggested that we get more address space. ARIN policy doesn't  
allow us to get any additional space until we've reached a 0.94 HD  
ratio. I'll never reach that amount if I'm only running my network out  
of one POP. I'd also like to deploy v6 everywhere now.

We don't qualify for micro-allocations, despite some suggestions that  
we might be able to. We're not "critical infrastructure" as much as  
I'd like to think we are, and "Internal Infrastructure" micro- 
allocations are intended to be non-routed.

The suggestion that we should start multiple corporations and get a / 
32 for each one is creative, but I don't see that as a fair solution.


Possible solution #3 - Announce the /32 from all of our POPs and haul  
the bits around ourselves

This really doesn't work either. Some of our POPs are really tiny and  
have 1/100th the bandwidth of the others. I'd be required to be able  
to support receiving a lot more inbound at *all* POPs just to handle  
inbound traffic that I'm going to bounce right out.

We'd either have to invest in expensive transport between all of our  
POPs, or waste a lot of bandwidth tunneling things around. If we have  
8 pops, roughly 7/8ths of the packets coming into each one would be  
for the wrong POP and have to be bounced right back out. This would  
make our network fragile (any POP being temporarily unable to talk to  
another one would cause outages), and dramatically increase our costs  
of doing business. It also seems very unnecessary, endpoints like us  
shouldn't really be involved in routing at that level.


While I'm not saying every ASN works like this, a lot of hosting/colo/ 
content companies operate in this manner. Forcing them all to change  
how they do things is going to really increase the struggle-factor of  
getting them on board with v6.

I also have no solution for anycast. I saw talk of a proposal a while  
back for v6 anycast allocations, did that die off?

For those reading this far... If this were your network, what would  
you do if you needed to deploy v6 immediately?

How many people here are strongly opposed to the idea of a TINY amount  
of deaggregation being explicitly allowed, but discouraged? Something  
along the lines of "/32 networks may be deaggregated down to /36  
announcements. Deaggregation may only be done if other methods to  
avoid deaggregation have been considered, etc etc etc" Or allow  
someone who qualifies for a /32 to obtain multiple smaller allocations  
if they choose?

I'm not asking to allow every network to deaggregate their /32 into  
65536 /48s, but rather a small amount of deaggregation ONLY where  
there really are multiple routes to different places.

-- Kevin