Cisco Logo

Enterprise Networks

My previous post examined how a regional Provider Independent (PI) prefix is propagated across the Internet.  This post discusses the second aspect of the issue: how does Provider Assigned/Aggregateable (PA) space propagate across the Internet?

The second aspect of prefix propagation has to do with organizations that receive a direct assignment that does not fall within the PI block.  These assignments are typically made from the PA space that the registries have.  The intent for PA space is for the owner of that space, which is typically a service provider (SP), to only announce that prefix to other organizations. 

For this case study, I’ll use the 2001:420::/32 prefix that has been assigned to Cisco by American Registry for Internet Numbers (ARIN).  I’ll use the same method to track down how this prefix and other prefixes in this range are propagating.

For the ARIN region, I’m using the Global Crossing route server:

Note here that the 2001:420::/32 prefix has been broken up into 15 component prefixes.  Doing some further digging into the 2001:420::/32 block you can see that Cisco is multi-homed to a couple of different SPs.  Note that I have cut some output to shorten it up for this blog.

Breaking up a large block like a /32 makes some sense if your organization is trying to do some load balancing, provide high availability, or has a global presence.  As mentioned in my previous blog, keep in mind the guidance in RIPE-399 and RIPE-532 and use de-aggregation judiciously and in accordance with what your SPsupports.
If we look into a route server in the RIPE region, we see that all the prefixes have propagated into that region.  Please note that I did clip out some of the command output for brevity, and to highlight that the prefixes are there.

Similarly, I can look into a looking glass in the APNIC region to see what is happening.   From the Hurricane Electric looking glass in Singapore:> show ipv6 bgp routes detail 2001:420:54fe::/48
Number of BGP Routes matching display condition : 1
1       Prefix: 2001:420:54fe::/48,  Status: BI,  Age: 166d22h44m54s
         NEXT_HOP: 2001:470:0:1ee::2, Metric: 1903,  Learned from Peer: 2001:470:0:1b::1 (6939)
          LOCAL_PREF: 140,  MED: 1,  ORIGIN: igp,  Weight: 0
         AS_PATH: 109
            COMMUNITIES: 6939:1000 6939:6000
       Last update to IP routing table: 1d22h19m31s


From the Sprint looking glass in Medellin, Colombia:

From the South African IX route server:

In this blog, I’ve tried to show that in today’s IPv6 Internet, that PA prefixes are propagating across all regions without regard to where the prefix might originate.  The major policy point that defines prefix propagation today is prefix length.  The operational community has settled on the /48 prefix length as the current boundary where filtering policy is applied.  The origination of the prefix does not figure into current filtering policy.  This does not mean that you should go forward and de-aggregate your /40 prefix into 256 /48 prefixes.  But, it does mean that you should analyze the requirements that you have and see where aggregation and de-aggregation is an appropriate solution

A last note here, which should sound similar, I again want to  promote working closely with your SP to ensure that they are capable of supporting your needs.  A quick search on the Web yields two providers who have posted their prefix policies: NTT and Sprint. These policies can certainly change over time and should be closely monitored by both talking with your SP and also using the tools available to look into how SP’s across the globe are implementing their policies.

Comments Are Closed

  1. Return to Countries/Regions
  2. Return to Home
  1. All Enterprise Networks
  2. All Security
  3. Return to Home