[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
What is BCP re De-Aggregation: strict filtering /48s out of /32 RIR minimums.
Yes, nice. But... It does not address the case when this is not the ISPs customers but the ISP (read content provider) that operates globally but without a network interconnecting their routers. They then advertise a /24 v4 and /48 v6 at each Internet exchange that they are connected to. That is "fine" for driving router. The "problem" with this design is that they cant announce their /32 as they are not running a iBGP mesh. I have seen a number of content providers doing this by design, and in the context of their business I can understand why and see it makes some sense. The only problem comes with the prefixes ending up under the minimum prefix size for the block they are in.
Now when this is a large content provider and we all want the peering, then we relax the filters, fine, but why one rule for them and another for everyone else in the same /12 block. Would it not make sense for the RIRs to assign a /12 as issuable in /32, /29 to content providers who will specifically deagregate to /48 with no internal network.
That solves the filtering problem, doesn't force these networks to put an iBGP network in place and lets everyone who does run a network "properly" to announce the proper aggregate blocks / covering routes with more specifics if we have to have them for routing purposes.
A separate /12 for the "island" type networks would immediately make this problem disappear.
Am I being overly simplistic?
From: Frank Habicht [mailto:geier at geier.ne.tz]
Sent: 14 November 2012 16:56
To: nanog at nanog.org
Subject: Re: What is BCP re De-Aggregation: strict filtering /48s out of /32 RIR minimums.
On 11/14/2012 6:02 PM, William Herrin wrote:
> and send a polite email to the POC to the effect of, "Please beware
> that because you have not offered a covering route matching your
> allocation, your IPv6 network is not reachable from ours. IPv6 is not
> IPv4: end users requiring /48s for multihoming should get them
> directly from the RIR. For complete Internet connectivity, we strongly
> encourage you to offer a covering route."