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."

like that. Frank

On 11/14/2012 8:08 PM, Ben S. Butler wrote:
> Hi,
> 
> 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.
Yep. Ack.
For the filtering policies it'd be nice to use space from a special prefix
- like for PI assignments.
But that will drive "global" routing table size :-(
But that's what content providers who create islands are bound to do - or
is there a way around without real connectivity or tunnels?

And the "polluters" apparently don't have enough incentives or pain to void
islands...

Frank





> 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?
> 
> Ben
> 
> -----Original Message-----
> From: Frank Habicht [mailto:geier@geier.ne.tz] 
> Sent: 14 November 2012 16:56
> To: nanog@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."
> 
> like that.
> Frank
> 
> 
> 
> 

On Nov 14, 2012, at 10:06 AM, William Herrin <bill@herrin.us> wrote:

On Wed, Nov 14, 2012 at 12:08 PM, Ben S. Butler <Ben.Butler@c2internet.net> wrote:

...

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.

Hi Ben,

That case is covered by things like ARIN's multiple discrete networks policy which permit an ISP /32 or end-user /48 for _each_ distinct network. There are plenty of addresses in IPv6. You should be break up a /32 for traffic engineering purposes, not for the sake of handling multiple disconnected sites. And when exercising TE, you can offer a covering route and expect the network as a whole to still function regardless of other folks' suballocation filtering.

Regards, Bill Herrin

I guess I'm confused. I have a /32 that I have broken up into /47's for my discrete POP locations. I don't have a network between them, by design. And, I won't announce the /32 covering route because there is no single POP that can take requests for the entire /32 - think regionalized anycast. So, how is it "worse" to announce the deaggregated /47's versus getting a /32 for every POP? In either case, I'm going to put the same number of routes into the DFZ. Mike

On Nov 14, 2012, at 1:50 PM, William Herrin <bill@herrin.us> wrote:

On Wed, Nov 14, 2012 at 3:10 PM, Michael Smith <mksmith@mac.com> wrote:

...

I guess I'm confused. I have a /32 that I have broken up into /47's for my discrete POP locations. I don't have a network between them, by design. And, I won't announce the /32 covering route because there is no single POP that can take requests for the entire /32 - think regionalized anycast.

So, how is it "worse" to announce the deaggregated /47's versus getting a /32 for every POP? In either case, I'm going to put the same number of routes into the DFZ.

Hi Michael,

If you announce an ISP /32 from each POP (or an end-user /48, /47, etc) then I know that a neutral third party has vetted your proposed network configuration and confirmed that the routes are disaggregated because the network architecture requires it. If you announce a /47 from your ISP space, for all I know you're trying to tweak utilization on your ISP uplinks.

Again, I thought the discussion was about PI, not PA. I don't announce any PA.

In the former case, the protocols are capable of what they're capable of. Discrete multihomed network, discrete announcement. Like it or lump it.

In the latter case, I don't particularly need to burn resources on my router half a world away to facilitate your traffic tweaking. Let the ISPs you're paying for the privilege carry your more-specifics.

You have great confidence in the immutability of design and the description thereof. Mike

Hi, I thought I would share an extract from an email I sent off list to a peer. My mail was a rather ramberly stream of consciousness exploring the issue, which worked its way to a potential solution... Hence why I am sharing an extract from it. I am not sure how practicably implementable it would be with the use of communities and some extra filtering logic implemented by the router software to enable prefix matching on less specific. I include for open discussion, I am sure there are things wrong with this idea, but maybe we can move towards a solution that works for everyone, rather than continuing in a straight line and having a bloated v6 route soup of indistinguishable /48s all over the place. Maybe the below has some legs, I leave it for those clever than me to see if this can be incorporated into an emergent BCP that might address what we should be doing and give everyone clear guidelines and keep everything on track. <snip> As I said its not the content networks I have issue with, it the rest of the access networks and hosting networks that are going to abuse a relaxation policy of "you should only announce /32 and use communities and no export for TE to adjacent ASes, but because there are a lot of island networks that require /48 support yours will also get accepted but please don't do this for TE reasons." What we need is a way to filter that says throw this prefix away if I can see it inside of another prefix. Ie discard this /48 if it is part of a /32 (or bigger) that I also have in my RIB and then insert the /32 into FIB and discard the /48". That would dump off all the TE nonsense, while keeping the island networks /48s. This new functionality could be used in a route map so it could be augmented with community matching or AS filter lists. That would solve the problem, all be it at the cost of the processing overhead to examine each /48 in the table and recurse its route, versus simple application of a filter list based on net block and minimum allocation size. I guess another thing that might work is if we all start passing communities and then we can tag some /48s as I am a TE prefix with a cover route and use a different community to tag I am an island prefix with no cover route, and then we can filter or permit those in a route map as the recipient sees fit and next the route map could filter everything left on RIR minimums for the block. That might work a lot better, if everyone passed communities.... At least people would be incentivised to tag the island routes which would be guaranteed to be permitted, we might have to worry about some people tagging a TE route as an island route. So I guess the logic becomes.... /48 Routes tagged with an island community permit as long as there is not a less specific covering route in the RIB. /48 Routes tagged with a TE community can be permitted or denied as chosen by the recipient end AS but should be carried in the DFZ by transit providers. /48 Routes that are not tagged should be assessed against RIR netblock minimums as being valid or invalid. Future RIR assignments should rigorously explore if the assignment is intended to be going to have an aggregate route or not, so for island networks that will not be aggregated are moved to a separate /12 with a /48 minimum and /40 maximum announced prefix size - rather than carried in the same block as "PA (Aggregated)" / "ISP" blocks that have a /32 minimum. If we do that, it keeps the existing problem the size it is currently and solves it for future assignments, allows the island networks to work, prevents people cheating by trying to sneak a TE route in as an island route when there is covering /32 route, dumps off the rubbish from spurious announcements and hijacking, while allowing PI end user /48s to continue to work... I think that would address the problem. </snip> Thoughts...? Ben -----Original Message----- From: Ben S. Butler Sent: 15 November 2012 00:05 To: 'Michael Smith'; William Herrin Cc: nanog@nanog.org Subject: RE: What is BCP re De-Aggregation: strict filtering /48s out of /32 RIR minimums. Hi, " Again, I thought the discussion was about PI, not PA. I don't announce any PA." My point, which I feel may be getting lost, and for which ARIN may already have policies in place for, is that an IP assignment is made out of a block with a defined minimum assignment size. Now some people simply advertise the assignment that is made to them, some people chose to advertise more specifics with a covering route, I have no problem with any of this. What I am saying, is if people chose to deagregate to create islands, for which I can completely understand the commercial and networking reason and why it is then by extension impossible for them to advertise the covering route. Then in these specific cases of "islands" then these assignments should be made by the RIR from a block with a minimum prefix size of a /48. Then the application is submitted to the RIR it will justify as much space as it justifies, but at this point it should also be established - without any judgment positive or negative - if the intention is to advertise this unagregated or with a route for the aggregate. The RIR would then be empowered to assign the requested amount of address space from a block which can be labelled with a lower minimum prefix size. I am not judging any of these design practices. What I am pointing out is that the designs are being implemented in assignment blocks that do not reflect the recipients implementations intentions and this is neither helpful for them or other AS operators when it comes to filtering. If RIR policies establish this intention at the point of assignment then the "island" case will be catered for and we absolutely do not want to see an aggregate in the route table for assignments from that block. IF it is TE then it can be made from a conventional block with a cover router and more specifics. What I am seeing in the real world is island networks in address space with minimum /32 assigments. It is my choice if I filter your TE, it is a stupid choice if you don't advertise the cover route because you are doing TE. But what we need to facilitate are islands networks which for very sensible technical and commercial reasons are unable to advertise an aggregate. Policies may be in place to provide for this, however, what I am seeing in the route table is telling me that the policies are failing to identify people that want to implement their network in this fashion as they are coming from blocks with /32 min and they are advertising /48s. If these announcements came from and address block to which they were assigned with a minimum of a /48 because of their design intentions then everyone is happy and can announce and filer accordingly and end points are reachable. There is a reason that different blocks have different minimum sizes, I am advocating ensuring that we get assignments aligned with the blocks that are suit the intended implementation. It is not my place to judge your business, nor is it anyone elses to expect the rest of us to accept TE routes without a coverall and expect to be reachable. My 2c Ben -----Original Message----- From: Michael Smith [mailto:mksmith@mac.com] Sent: 14 November 2012 23:32 To: William Herrin Cc: nanog@nanog.org; Michael Smith Subject: Re: What is BCP re De-Aggregation: strict filtering /48s out of /32 RIR minimums. On Nov 14, 2012, at 1:50 PM, William Herrin <bill@herrin.us> wrote:

On Wed, Nov 14, 2012 at 3:10 PM, Michael Smith <mksmith@mac.com> wrote:

...

I guess I'm confused. I have a /32 that I have broken up into /47's for my discrete POP locations. I don't have a network between them, by design. And, I won't announce the /32 covering route because there is no single POP that can take requests for the entire /32 - think regionalized anycast.

So, how is it "worse" to announce the deaggregated /47's versus getting a /32 for every POP? In either case, I'm going to put the same number of routes into the DFZ.

Hi Michael,

If you announce an ISP /32 from each POP (or an end-user /48, /47, etc) then I know that a neutral third party has vetted your proposed network configuration and confirmed that the routes are disaggregated because the network architecture requires it. If you announce a /47 from your ISP space, for all I know you're trying to tweak utilization on your ISP uplinks.

Again, I thought the discussion was about PI, not PA. I don't announce any PA.

In the former case, the protocols are capable of what they're capable of. Discrete multihomed network, discrete announcement. Like it or lump it.

In the latter case, I don't particularly need to burn resources on my router half a world away to facilitate your traffic tweaking. Let the ISPs you're paying for the privilege carry your more-specifics.

You have great confidence in the immutability of design and the description thereof. Mike

Hi, Ok. I am trying to encourage an inclusive exploration of an issue that seems to be emergent. I am trying to get the community to articulate BCP not dictate it. "Would you want this logic to still apply if you have ::/0 in your table anywhere?" Yes obviously limits would apply to the filter on min and max in a recursive filter. "It sounds a little bit like such people may be trying to shift the cost burden around in an odd fashion." I am seeking community input before we manage to screw things up. I do not want a route table with 10M+ prefixes. One of the points of v6 is aggregation, would it not be silly to adopt a liaise a faire view to route pollution and associated security considerations. "But I also want to look like I'm one of the big default-free providers" I struggle to not use direct language here. Firstly I never asserted I was DFZ or want to be, quiet the opposite, seeking clarification of BCP. "default route towards something that *does* know how to get closer to the destination." Filtering exists for internet security not route table size, your default return path trashes that. "you must be trying to play in the DFZ" Lol, understand the issue at hand "I think your use of the term "cheating" here is misapplied." Read my suggestion, if you deliberately falsely tag a route with the wrong community under my proposed model, what would you call it? "You're implying that your network is default free" Nope, I am trying to find a solution that works for everyone that empowers the recipient AS with the choice of what they filter in an informed fashion for mutual benefit. "DFZ provider to have to carry the longer prefixes *except you*" Firstly that was a comment to the sub informed way some people work, however, my point is we have a legacy that can not be solved by new policy. We have to accommodate that legacy and the answer is not to say lets just go with a /48 no questions asked. Networks involve design and engineering, we can accommodate all peoples needs within a structure. "And if you *do* carry ::/0 in your network from an upstream, this is all a moot point; filter away to whatever level your heart desires," You just agreed with me. # We are at the start of a new network, lets learn from the past. My posts are open and non judgemental, please, keep to the issue, if you don't get it yet then clue up. Arms open here, can anyone else see the future cast issue I am tryin to raise if all the aggregate deag without control, we were all worried about PI multihoming a year ago and route table bloat. Lets try to stay on point. Ben

On Wed, Nov 14, 2012 at 6:31 PM, Michael Smith <mksmith@mac.com> wrote:

On Nov 14, 2012, at 1:50 PM, William Herrin <bill@herrin.us> wrote:

...

On Wed, Nov 14, 2012 at 3:10 PM, Michael Smith <mksmith@mac.com> wrote:

...

I guess I'm confused. I have a /32 that I have broken up into /47's for my discrete POP locations. I don't have a network between them, by design. And, I won't announce the /32 covering route because there is no single POP that can take requests for the entire /32 - think regionalized anycast.

So, how is it "worse" to announce the deaggregated /47's versus getting a /32 for every POP? In either case, I'm going to put the same number of routes into the DFZ.

If you announce an ISP /32 from each POP (or an end-user /48, /47, etc) then I know that a neutral third party has vetted your proposed network configuration and confirmed that the routes are disaggregated because the network architecture requires it. If you announce a /47 from your ISP space, for all I know you're trying to tweak utilization on your ISP uplinks.

Again, I thought the discussion was about PI, not PA. I don't announce any PA.

Hi Michael, PI and PA terminology is getting to be as obsolete as Class A, B and C. Your IPv6 addresses fall in to one of three categories: "Allocation" from RIR under ISP rules (/32 or more) "Assignment" from RIR under end-user rules (/48 or more) "Reassignment" from ISP (any size) You will find that you can successfully propagate announcements of allocations in units of /32 or shorter, assignments in units of /48 or shorter and reassignments in units of /32 or shorter. Longer prefix announcements won't be rejected by everybody, but they'll be rejected by enough folks to spoil your day. So, regardless of which of the three types of addresses you work with, you should make sure to get enough so that each of your discrete multihomed networks can announce a prefix as big as or bigger than the minimum. And as a purely pragmatic matter, you should never ever try to number a discrete multihomed IPv6 network using a reassignment. Go get an allocation or assignment (as appropriate) from the RIR instead. Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004