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:

route-server.phx1>sh bgp ipv6 uni | incl 2001:420| incl 2001:420

* i2001:420::/32    2001:450:2001:8018::1
* i2001:420:1::/48  2001:450:2001:8018::1
* i2001:420:4::/48  2001:450:2001:8018::1
* i2001:420:5::/48  2001:450:2001:8018::1
* i2001:420:80::/48 2001:450:2001:8018::1
* i2001:420:81::/48 2001:450:2001:8018::1
* i2001:420:1000::/40
* i2001:420:1100::/41
* i2001:420:2000::/37
* i2001:420:2000::/35
* i2001:420:207F::/48
* i2001:420:4000::/36
* i2001:420:4420::/48
* i2001:420:54BF::/48
* i2001:420:54FE::/48
* i2001:420:C0C0::/46

 
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.

route-server.phx1>sh bgp ipv6 uni 2001:420:4000::/36
BGP routing table entry for 2001:420:4000::/36, version 268453350

Paths: (17 available, best#11, table default)
  Not advertised to any peer
  1239 109, (received & used)   ?  AS 1239 is Sprint
    2001:450:2001:8018::1 from 67.17.81.144 (67.17.81.144)
      Origin IGP, metric 50, localpref 200, valid, internal
      Community: 3549:2351 3549:30840
      Originator: 67.17.82.171, Cluster list: 0.0.0.71
 
route-server.phx1>sh bgp ipv6 uni 2001:420:1000::/40
BGP routing table entry for 2001:420:1000::/40, version 269696093
Paths: (24 available, best#9, table default)
  Not advertised to any peer
  3356 109, (received & used)   ? AS 3356 is Level 3
    2001:450:2001:8018::1 from 67.17.81.144 (67.17.81.144)
      Origin IGP, metric 100, localpref 201, valid, internal
      Community: 3549:2355 3549:30840
      Originator: 67.17.82.9, Cluster list: 0.0.0.71
 
route-server.phx1>sh bgp ipv6 uni 2001:420:54fe::/48
BGP routing table entry for 2001:420:54FE::/48, version 263425868
Paths: (6 available, best#4, table default)
  Not advertised to any peer
  6939 109, (received & used)
    2001:450:2001:8018::1 from 67.17.82.144 (67.17.82.144)
      Origin IGP, metric 100, localpref 200, valid, internal
      Community: 3549:2722 3549:31276
      Originator: 67.17.82.80, Cluster list: 0.0.0.141

 
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.


OpenTransit/France Telecom Route Server
[email protected]> show route protocol bgp 2001:420::/32 all terse
 
inet6.0: 10444 destinations, 54461 routes (10444 active, 0 holddown, 0 hidden)
Restart Complete
+ = Active Route, - = Last Active, * = Both
 
A Destination        P Prf   Metric 1   Metric 2  Next hop        AS path
* 2001:420::/32      B 170       85       100 >2001:688:0:3:4::4 7018 109 I
* 2001:420:1::/48    B 170        85       100 >2001:688:0:3:4::4 6939 109 I
* 2001:420:4::/48    B 170        85       100 >2001:688:0:3:4::4 6939 109 I
* 2001:420:5::/48    B 170        85       100 >2001:688:0:3:4::4 6939 109 I
* 2001:420:80::/48   B 170        85       100  2001:688:0:3:4::4 6939 109 I
* 2001:420:81::/48   B 170        85       100 >2001:688:0:3:4::4 6939 109 I
* 2001:420:1000::/40 B 170        85       100 >2001:688:0:3:4::4 7018 109 I
* 2001:420:1100::/41 B 170        85       100 >2001:688:0:3:4::4 7018 109 I
* 2001:420:2000::/35 B 170        85       100  2001:688:0:3:4::4 3356 109 I
* 2001:420:2000::/37 B 170        85       100  2001:688:0:3:4::4 3356 109 I
* 2001:420:207f::/48 B 170        85       100  2001:688:0:3:4::4 6939 109 I
* 2001:420:4000::/36 B 170        85       100  2001:688:0:3:4::4 1239 109 I
* 2001:420:4420::/48 B 170        85       100 >2001:688:0:3:4::4 6939 109 I
* 2001:420:54bf::/48 B 170        85       100  2001:688:0:3:4::4 6939 109 I
* 2001:420:54fe::/48 B 170        85       100  2001:688:0:3:4::4 6939 109 I
* 2001:420:c0c0::/46 B 170        85       100  2001:688:0:3:4::4 1239 109 I

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:

core1.sin1.he.net> show ipv6 bgp routes detail 2001:420:54fe::/48

Number of BGP Routes matching display condition : 1

       S:SUPPRESSED F:FILTERED s:STALE

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:


Sprint Source Region: Medellin, Colombia (sl-gw10-med)
Performing: Show Route
BGP routing table entry for 2001:420:54FE::/48, version 2421465
Bestpath Modifiers: deterministic-med
Paths: (2 available, best#2, table Global-IPv6-Table)
  Not advertised to any peer
  6939 109
    2600:0:1:1239:144:228:241:41 (metric 851) from 144.228.241.8 (144.228.241.8)
      Origin IGP, metric 4294967294, localpref 90, valid, internal
      Community: 1239:666 1239:667 1239:1000 1239:1007
      Originator: 144.228.241.41, Cluster list: 144.228.241.8, 144.228.241.124
  6939 109
    2600:0:1:1239:144:228:241:41 (metric 851) from 144.228.241.7 (144.228.241.7)
      Origin IGP, metric 4294967294, localpref 90, valid, internal, best
      Community: 1239:666 1239:667 1239:1000 1239:1007
      Originator: 144.228.241.41, Cluster list: 144.228.241.7, 144.228.241.124

 
From the South African IX route server:


tpr-route-server>sh bgp | incl 2001:420:| incl 2001:420:
* i2001:420::/32    ::FFFF:196.43.9.242
*>i2001:420:1::/48  2001:4208:100::12
*>i2001:420:4::/48  2001:4208:100::12
*>i2001:420:5::/48  2001:4208:100::12
*>i2001:420:80::/48 2001:4208:100::12
*>i2001:420:81::/48 2001:4208:100::12
* i2001:420:1000::/40
* i2001:420:1100::/41
* i2001:420:2000::/37
* i2001:420:2000::/35
*>i2001:420:207F::/48
*>i2001:420:4000::/36
*>i2001:420:4420::/48
*>i2001:420:54BF::/48
*>i2001:420:54FE::/48
*>i2001:420:C0C0::/46

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.