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

[Scott Leibrand]

Kevin,

A couple thoughts:

You could try announcing your deaggregates (/36 or whatever), in 
addition to announcing the /32, and *without* no-export set.  This is 
what I envision we'll do when we deploy IPv6.  Most people I've talked 
to agree that, as long as you're announcing the /32, that should be 
allowed, and it's up to everyone to decide whether or not to accept the 
more-specifics.  If you're paying a transit provider to do so, they 
should accept them, and should accept the same more-specifics from their 
peers.  As long as your ISPs (or their transit providers) peer with each 
other, and accept the more-specifics from each other, you should have 
full reachability, and you shouldn't have to transport the packets 
yourself (you're paying your ISPs to do that).

Alternately, you could perhaps give back your /32, and instead get a PI 
/48 from ARIN (under the end user policy) for each site (or perhaps a 
contiguous /44 to get you a /48 per site).  I'm not sure if that policy 
applies in your case, or if that would be a better idea overall in your 
situation than using a /32, but it seems more reasonable than trying to 
get additional /32's or "critical infrastructure" blocks.

-Scott

Kevin Day wrote:
> 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
> 
> 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to the ARIN Public Policy
> Mailing List (PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/ppml
> Please contact the ARIN Member Services Help Desk at info at arin.net if you experience any issues.