Where’s My IPv6 Prefix? Part One

In a previous blog series about interfacing with your ISP, I mentioned tools that Internet Service Providers (ISPs) have, such as looking glasses and route servers, that can be used to verify their policies.  In this blog post, I want to examine some of those tools, but primarily I want to show how prefixes are propagating across the Internet. 

The question of prefix propagation comes up often when discussing how to develop an IPv6 address plan.  What happens if an organization gets Provider Independent (PI) space from a registry and then tries to advertise that prefix, or a smaller portion of that prefix, in a different region?  Will ISPs in that region filter the non-regional prefix?  Will they let the aggregate pass, but not the more specific prefixes?

There has been some guidance on prefix aggregation and de-aggregation published by the Réseaux IP Européens Network Coordination Centre (RIPE).  RIPE-399 and RIPE-532  documents give guidance on how organizations should approach the aggregation and de-aggregation issue.  The guidance in the documents advises using aggregation when and where possible, and using de-aggregation judiciously to solve a specific problem.

The concern over the de-aggregation of prefixes stems from the potential for a huge increase in the number prefixes that have to be carried.  IPv6 moves to a 128 bit address space and opens up the very real possibility of having to carry millions of prefixes.  The current IPv6 Internet routing table is ~10.5K prefixes.  As a comparison, the current IPv4 Internet routing table is ~400K prefixes.  So we have a way to go before the IPv6 table approaches the size of the IPv4 table, but that does not mean we can ignore the problem.  Typically, it is better to work on issues when they are smaller and more easily handled.   

One proposed solution is to get address space from each regional registry where your organization has presence.  I find this solution to be more about moving the issue around versus actually solving it.  In this case you are not necessarily reducing the number of prefixes, you are merely making people get more prefixes that also have to be advertised.  For example, if your organization has sites in Europe, North America, and Asia, then you need to get three prefixes.  You could equally get a single prefix from any one of those registries and break that prefix into three more specific prefixes.

The above solution also relies on the development of a regional prefix aggregation policy.  For a regional prefix aggregation policy to work, you would have to advertise an aggregate for which you may not have more specific prefix information.  You can get into some very tricky routing situations when you advertise an aggregate but do not have all the specifics available.  Routing “black holes” can easily develop in that situation because the aggregate would cover a lot of the space that the organization was not responsible for routing.

There are two aspects to the prefix propagation issue.  One issue deals with PI address space and the other deals with Provider Assigned/Aggregateable (PA) space.  I will talk about the PI space issue in this post and the PA space issue in my next post. 

Let’s look at what happens with Provider Independent (PI) prefixes.   Each regional registry has defined a policy for PI space, and identified an address block to make address assignments to organizations within that region.  With each registry having their own defined PI policy, the concern is that operational policy will also develop around how PI assigned prefixes will propagate across the Internet.  The other concern is that  an organization with a global presence will get a PI prefix from each registry.

To try and address this concern, I can use several tools to track what is happening across the Internet for an organization’s prefixes.  To find an organization that is using PI space, I first use Dan Wing’s website that verifies if sites are using AAAA records for their website.  One of the sites that is using both  PI space, and breaking up that space into more specific announcements, is the web site for Louisiana State University. Using American Registry for Internet Numbers (ARIN)’s whois search tool, LSU has been assigned 2620:105:B000::/40..   I can then check to see what prefixes LSU is advertising by using a route server.  Route severs are routers that Service Providers (SPs) have set up to give a view into how routing is working in their domain.  I have been using the  Border Gateway Protocol Advanced Internet Routing Resources site to help me find route servers.

Using AT&T IP Services route server located in the US, I can see that LSU is advertising the block that it was assigned and also 3 more specific prefixes from that block:

• route-server>sh bgp ipv6 uni | incl 2620:105:B
• *  2620:105:B000::/42
• *  2620:105:B000::/40
• *  2620:105:B040::/44
• *  2620:105:B050::/48

To check what is happening in other regions, I can go to Global Crossing’s European Route Server and have a similar peek into what prefixes have made it to Europe:

• route-server.ams2>sh bgp ipv6 uni | incl 2620:105:B
• *>i2620:105:B000::/42
• * i2620:105:B000::/40
• *>i2620:105:B040::/44
• *>i2620:105:B050::/48 

 
Similarly I can check the South African Internet Exchange Route server:

• tpr-route-server>sh bgp | incl 2620:105:B
• * i2620:105:B000::/42
• * i2620:105:B000::/40
• * i2620:105:B040::/44
• * i2620:105:B050::/48

 
You can also use a “looking glass” to get a view into what’s happening in a SP domain.  When you use a looking glass you are interfacing with a Graphical User Interface (GUI) that will run the command on a router for you.  I use the same site above to help me find available looking glass sites.   In this case, I want to check out how LSU’s PI prefix is propagating in the APNIC region.  To check the propagation, I am using the BroadBand Tower looking glass in Japan.  Because it is done on a per prefix basis, I am just showing the check for the most specific prefix:
 

• BGP routing table entry for 2620:105:b050::/48
• Paths: (3 available, best #3, table Default-IP-Routing-Table)
•    Not advertised to any peer
•    4725 3356 32440 2055
•       2001:278:0:2235::1 from 2001:370:100::12 (211.14.3.252)
•          Origin IGP, metric 300, localpref 90, valid, internal
•          Community: 9607:3252
•          Last update: Tue Sep 11 16:49:35 2012
•  
•    2516 209 32440 2055
•       2001:370:100::13 from 2001:370:100::9 (203.216.201.1)
•          Origin IGP, metric 100, localpref 100, valid, internal
•          Community: 9607:2011
•          Originator: 203.216.201.1, Cluster list: 211.14.3.249
•          Last update: Thu Oct  4 12:05:25 2012
•  
•    2516 209 32440 2055
•       2001:370:100::13 from 2001:370:100::7 (203.216.201.1)
•          Origin IGP, metric 100, localpref 100, valid, internal, best
•          Community: 9607:2011
•          Originator: 203.216.201.1, Cluster list: 211.14.3.249
•          Last update: Thu Oct  4 12:05:25 2012

 
To check what is happening in the LACNIC region, I am using the RNP looking glass in Rio de Janeiro Brazil.  Similar to the other looking glass output, I am specifically checking to see if the most specific prefix has been advertised.  I’ll leave it to the interested readers as homework to verify that I’m also getting the same output for the other prefixes.

• Router: Rio de Janeiro, RJ
Command: show route protocol bgp 2620:105:b050::/48 terse exact

 

• inet6.0: 11043 destinations, 11203 routes (11041 active, 2 holddown, 0 hidden)
• + = Active Route, - = Last Active, * = Both
• A Destination        P Prf   Metric 1   Metric 2  Next hop        AS path
• *2620:105:b050::/48 B 170        125          0 >fe80::8271:1f0b:b8f4:9ae627750 11537 324402055 I

In this post, I have tried to show how providers across the globe are treating regional PI space.  I used some of the publicly available tools to track an ARIN PI prefix and how it propagates across regional registry boundaries.  This example is not meant to be a definitive example or show consistent policy.  It is merely a peek into how a particular prefix has propagated across the globe.  Please use this information as a starting point in your planning and talks with your SP about how IPv6 prefixes are handled.

Stay tuned for my next post where I will be continuing the prefix propagation discussion.