Building

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

 

Comments

  1. A couple of points here, as far as I understand the policies in effect in the RIPE region:

    1) If you are an LIR in the RIPE region, in other words a member of the RIPE NCC, you can get an IPv6 /29 of PA space just by asking for it. This contains half a million /48s, which you in turn can announce individually from sites wherever you like. Just remember to add the respective route6-objects in the RIPE database, and you’re good to go.

    2) If you are not an RIPE region LIR, you can obtain PI prefixes for each of your sites instead. This will give you a /48 per site, unless you can document need for anything more. The sites themselves do not have to be inside the RIPE region. I don’t actually know if your organisation needs to have a legal entity in the RIPE region in order to apply for IPv6 PI space, but you will need to engage via a “sponsoring” LIR.

    So in summary, you can get all the space you need for your global infrastructure from the RIPE NCC, if you prefer. There is no need to engage with the other RIRs, unless you want to of course (depending on that region’s policies, you might be able to get everything from that region’s RIR instead).

    Tore

    1. Hi Tore

      thanks! for the comprehensive comment.
      Couple of points from my side:

      > 1) If you are an LIR in the RIPE region, in other words a member of the RIPE NCC, you can get an IPv6 /29 of PA space just by asking for it. This contains half a million /48s, which you in
      > turn can announce individually from sites wherever you like. Just remember to add the respective route6-objects in the RIPE database, and you’re good to go.

      I’m aware of the current (potential) /29 allocation policy. As laid out in the first part the presumed setting of the posts was “enterprise org with existent LIR/member status in RIPE space, having received an allocation of a /32 within the last 24 months and now considering applying for additional allocations in ARIN/APNIC space”. The latter not driven by the need for more than a /32 but to cope with uncertainties as for seeing their (“RIPE associated”) prefix[es] actually being propagated and routed in Non-RIPE parts of the world. I’ve seen cases where it was even difficult to get a clear confirmation “we’ll route your _APNIC_ PI space” from major Chinese providers, for example.

      > 2) If you are not an RIPE region LIR, you can obtain PI prefixes for each of your sites instead. This will give you a /48 per site, unless you can document need for anything more. The sites
      > themselves do not have to be inside the RIPE region. I don’t actually know if your organisation needs to have a legal entity in the RIPE region in order to apply for IPv6 PI space, but you
      > will need to engage via a “sponsoring” LIR.

      see above, the presumed setting is not about “end user” PI assignments.

      > So in summary, you can get all the space you need for your global infrastructure from the RIPE NCC, if you prefer.

      Most probably those organizations I depicted would be quite happy if they could just interface with RIPE. alas, there are (still) concerns that e.g. $SOME_PROVIDER_IN_SOUTH_EAST_ASIA might not route their RIPE allocated prefix[es] at all times, even more so if those happened to be /48s…

      thanks again for the clarification,
      have a good one

      Enno

Leave a Reply

Your email address will not be published. Required fields are marked *