IPv6 Address Plan Considerations, Part 2: The “PI Space from (Single|Multiple) RIR(s) Debate”

This is the second part of the – presumably – three-part series on IPv6 address planning which I started here.

Before an enterprise organization (strictly speaking “their internal service provider acting as LIR”, as laid out in the first part) starts assigning prefix[es]/lengths to their networks usually another discussion has to be undertaken & solved: “go with one /32 [PI space] from one RIR or apply for /32s from several RIRs”.

The background of this reflection is mainly them being concerned along the lines: how do we know if $PROVIDER in some part of the world is actually going to route our PI space, in particular if that’s allocated from ‘a foreign RIR’?

While it’s reasonable to ask some questions as for $PROVIDER’s IPv6 capabilities anyway, this might not always be an easy task for organizations with various provider relationships around the world and some trouble might be avoided in advance by choosing the right strategy.

You might be tempted to ask “what’s the benefit of using PI space if such concerns/issues can come up” and that’s a very good and legitimate question. Point is that Regional Internet Registries (RIRs, like RIPE, ARIN, APNIC) and providers are very different (types of) organizations, both of which have their fully own – and potentially very different – agendas.

In my understanding the stance of the main RIRs as for a PI space (allocated to LIRs, I’m not talking about “end user [PI space] assignments” here) can roughly be summarized as follows:

“You (LIRs) can expect your address space to be routed everywhere in the world, as long as

• you have a [global] backbone network that allows you to do all routing considered ‘internal’ as of your allocation within the boundaries of your network. This usually implies either announcing only your full aggregate to the Internet or at least not announcing several individual longer prefixes from different places  (as this might potentially mean that traffic transport/routing [propagation] between those happens “across the Internet”).
• any announcement is not smaller than a /48 (which is self-evident in case the above rule is strictly followed, but will apply independently from that one).”

It should be noted here that my interpretation of things above & in the following might be incomplete or flawed and you might hear/read “other voices”. While I have quite some personal background in the carrier/provider space in the late 90s and early 2000s, things have changed a bit nowadays and in the interim I’m mainly involved on the customer/”end user organization” side of things. What I can state is that the actual processes & procedures from some RIRs are not always very transparent to “end-user type LIRs”. Actually, some of you sharing this feeling might be the very reason for you reading this post right now ;-).

Back to track: the above (presumed RIRs’ stance) still doesn’t buy an enterprise org anything as for guarantees in real-life. Furthermore, for example, the document ripe-589 (RIPE’s “IPv6 Address Allocation and Assignment Policy”, valid as of the time of writing) explicitly states in section 4.2. Routability not guaranteed

“There is no guarantee that any address allocation or assignment will be globally routable.”

While this statement is surely there for a good reason (e.g. to avoid legal discussions), again, it probably doesn’t help $ENTERPRISE to reach a tranquilo state when it comes to the initial question. Hence the main line of thinking of quite some enterprises goes like: “to increase our chances that individual carriers/providers actually route our prefixes, go for additional PI space at the RIRs responsible for address space in those parts of the world which are relevant for our business, and assign prefixes from that space to the sites in that region”.

Or as Ivan the Great Networker stated it some time ago: “Summary: if you’re a global organization with data centers spread across multiple RIR regions, apply for PI address space in every region where you need mission-critical connectivity”.

Still, there’s some points to consider here which I haven’t covered so far: what are the motivations of the providers involved? One might naively ask: isn’t it in their best interest to route their customers’ traffic, in particular in case those are enterprise organizations with respective contract volumes?

Well, maybe. This might apply to their own customers but not to “those customers of other providers who clutter up our BGP tables & TCAMs with their specific announcements”. [and, in the Internet every single provider’s customer is “a customer of another provider, for many of them” ;-)]. One of the direct implications of that – again, very legitimate, see also the respective references in the first post – desire to save TCAM memory can be found in a certain route filtering approach which is sometimes called Gert Doering’s strict filter approach  and which is actually performed by some number of providers out there. It can be summarized as follows: “in case we see routes from address space identifiable as LIR space [the RIRs use certain prefixes for their allocations to LIRs] and the prefix length is longer than $COMMON_AGGREGATE_LIR_SPACE_PREFIX_LENGTH [e.g. /32], then filter those routes as the LIR involved seems to play foul to the first [RIRs’] requirement above”.

This is a prominent example of an organization (CloudFlare) suffering from reduced “Internet visibility” in the past due to announcing more specific routes without the respective aggregate (route).

The document ripe-532 (RIPE Routing Working Group Recommendations on IPv6 Route Aggregation) discusses this topic and its associated potential problems and advocates for a more relaxed handling by the ISPs involved. Furthermore some experiments performed by the RIPE labs back in 2012 seem to indicate that this is not a huge problem in practice (Summary: “Based on this data I’d say that strict IPv6 prefix filtering does matter, but currently only a little bit.”). However there’s a main lesson to be learned here: in the end of the day it all depends on the actual approach of providers, regardless of the statements of administration and policy organizations. So talking to the providers in advance is always a good idea (see the checklist I referenced in the third section of this post).

Now, let’s assume an organization wants to follow the road of “applying for LIR space in different regions”. What does this mean in practice?

Here’s some steps & unordered recommendations we’d like to provide:

a)  do some initial homework (e.g. become a member at APNIC or create online account, POC and ORG ID at ARIN). Of course, you’ve read the respective RIR’s IPv6 guidelines (e.g. this one for ARIN, this one for APNIC) at this point.

b) perform the actual resource request, usually by completing some online form/procedure. Some things to keep in mind here:

• you/your organization’s internal IT service provider (“IT-Sys” as of the first post) act as an ISP now. Hence you should write sth along the lines of “we’re the internal service provider of a global automotive corporation and we provide network services to group members and external customers” instead of “we’re a big automotive enterprise” (then your business would be building cars and not networks…].
• lay out how you’re going to assign a certain number prefixes from your address space to “other organizations” within a certain amount of time (currently 200 assignments within two years at APNIC, 50 within 5 years at ARIN). From my experience it helps to include a list a plants/sites/subsidiaries in this section, together with mentioning significant “future growth due to business expansion and/or industry sector dynamics”). You can (and might be required to) act “generously” here… but it’s IPv6… so everybody expects the future to be wide open anyway…
• Provide some (rough) details as for network connectivity, uplinks etc. in that region. (“IT-Sys operates a MPLS network based on infrastructure of $TIER-1_PROVIDER and we’re multihomed with $TIER-1 and $OTHER-TIER-1. Our main POPs/data centers are located in…”).
• You might include a reference to your current (e.g. RIPE LIR) status, together with AS number and existing allocations (to demonstrate “we know what we’re doing”).

c) With greater IP space comes greater responsibility. You were aware of that, weren’t you? 😉

As discussed above, in some provider circles there’s a certain expectation that once you’ve received a /32 LIR allocation (and hence act “as a provider”) you must announce the full /32 aggregate (and not just some parts of it). So an approach of “apply for a /32, split this according to $ADDRESS_PLAN and – for isolation/security reasons – only announce specific /48s (‘our DMZs’) might cause some issues. I’ve heard you can still do that if you create (additional) appropriate route6 objects, but I’ve yet to be involved/see this (shouldn’t be too difficult anyway).

d) As stated in the first post you must be willing to pay the associated annual fees (see these links for RIPE, ARIN, APNIC). Usually the invoice will be sent to a legal entity located in the respective RIR’s region. There must be somebody there to receive, understand and, most importantly, pay it ;-).

======

Some additional miscellaneous points:

• Keep in mind that having different prefixes from different RIRs somewhat violates the “consistency principle” I introduced in the first post. Carefully weigh this before turning this road.
• We know an organization who, in addition to their APNIC allocation, requested another /32 from the  China Internet Network Information Center (CNNIC) to facilitate in-country routing and provider relationships within China and – as we were told – because CNNIC offered to apply for that one with a quite simplified procedure and at a fairly low cost. You might consider this if you have a strong business presence there.
• From what I hear it’s not easy to get a /32 from AFRINIC or LACNIC but so far I’ve not been personally exposed to applying for an allocation at those.

 

I hope this post could contribute to taking a well-informed decision and to getting an understanding what this means efforts- & steps-wise. Stay tuned for the 3rd part on the actual address planning, to follow in a week or two…

Best

Enno