On Wed, Jan 29, 2014 at 5:16 PM, Seth Mattinen <sethm@rollernet.us> wrote:

On 1/29/14, 14:01, Leslie Nobile wrote:

...

Additionally, ARIN has placed 23.128.0.0/10 in its reserves in accordance with the policy "Dedicated IPv4 block to facilitate IPv6 Deployment" (NRPM 4.10). There have been no allocations made from this block as of yet, however, once we do begin issuing from this block, the minimum allocation size for this /10 will be a /28 and the maximum allocation size will be a /24. You may wish to adjust any filters you have in place accordingly.

I know ARIN doesn't care about routability and all that, but good luck with those /28s.

maybe these weren't meant to be used outside the local ASN? :) I do wonder though what the purpose of this block is? If it's to be used inside the local ASN (as seems to be indicated based upon minimum allocation sizes) then why not use the IETF marked 100.64/10 space instead? Global-uniqueness? ok, sure... There will need to be popcorn though, for this event. -chris

On Thursday, January 30, 2014 07:17:11 AM Mark Andrews wrote:

Or you could just accept that there needs to be more routing slots as the number of businesses on the net increases. I can see some interesting anti-cartel law suits happening if ISP's refuse to accept /28's from this block.

I understand the reasoning behind RIR's (and the community that supports them) not caring about routability, but if there is a lesson we can learn from IPv4, it is that perhaps that divorce is not entirely practical. It might be a good idea to think about how RIR's (and the community that supports them) "could care" about routability, so we don't end up in the same situation with IPv6, whenever that will be, or if any of us will be alive. It's definitely too late to do anything about it for IPv4, which means there will be even more lessons to learn in the coming months/years... I know it is a moving target (advances in FIB memory is not something an RIR [and the community that supports them] can depend on, for example), but I also don't think it makes complete sense for the RIR's (and the community that supports them) to be in a utopia about this - that it will all "just sort itself out". Mark.

* Justin M. Streiner

In the worst case, this would add another 262,144 routes (/10 fully assigned, and all assignments are /28s) to the global IPv4 route view. Realistically, the number will be a good bit smaller than that, but only time will tell for sure exactly how much smaller. Wash/rinse/repeat for any other RIR that adopts a similar policy.

I wouldn't worry if I were you. I'll wager you $100 that pretty much all of the people requesting a block from ARIN under this policy (or any other) is going to go for a /24 (or larger). There is some precedent; RIPE policy has not mandated a minimum assignment size for IPv4 PI, at least not in the last decade, yet the NCC has made almost no assignments smaller than /24. Tore

On Jan 30, 2014, at 12:17 AM, Mark Andrews <marka@isc.org> wrote:

Or you could just accept that there needs to be more routing slots as the number of businesses on the net increases. I can see some interesting anti-cartel law suits happening if ISP's refuse to accept /28's from this block.

i suspect it will be more sean doran style 'pay me for your slot'.

On 1/30/14, 15:58, Mark Andrews wrote:

The moment /24's aren't readily available and they are forced into using this range anyone filtering on /24 in this range is leaving themselves open to lawsuits.

Because why? Cartels? Illuminati? I want to travel by stargate. Who do I sue? ~Seth

On Fri, 31 Jan 2014, Mark Andrews wrote:

In Australia I would sue Telstra, Optus, ... if their customers couldn't reach me due to routes being filtered. I would take this to the ACCC (Australian Competition and Consumer Commission) as a restraint of trade issue.

And if the provider doing the filtering isn't in $your_country? I'm sure a few tech-savvy lawyers are salivating over this one. jms

On Jan 30, 2014, at 10:20 PM, Mark Andrews <marka@isc.org> wrote:

I figure there will be similar problem for other business in other countries and they will fight a similar battles. Eventually the regulators will step in because it is bad for small businesses to be shut out of the Internet.

Mark - ISPS consciously breaking Internet services are bound to attract regulatory attention, but that does not necessarily mean that in the end there will be regulatory action. In the case of peering and route acceptance, it is fairly easy to show that there is a finite amount of routes that a given ISP can accept, and each of these routes has different value (i.e. some have large traffic flows, some are peer traffic engineering, some of required backup routes for shared multihomed corporate customers, etc.) The result is not simple to regulate, because you can't just mandate "accept all routes offered" - some ISPs are already trimming what they accept to accommodate their particular flavor of routing hardware. For last few decades, we've basically been relying on the IP allocation/assignment policies and their minimum block sizes as a proxy for the default "worth accepting" metric, but this may not prevail once there is serious pressure to fragment blocks to obtain better utilization. It would be nice if there was a way to fairly "settle up" for the imputed cost of adding a given route to the routing table, as this would provide some proportionate backpressure on growth, would create incentives for deaggregate cleanup, etc. We don't have such a system, so it falls to each ISP to decide what route is worth accepting based on type and the offering peer's business relationship... FYI, /John Disclaimer: My views alone. Note - I haven't had enable on any backbone routers in this _century_, so feel free to discount/discard if so desired. ;-)

On Fri, Jan 31, 2014 at 4:29 PM, Matt Palmer <mpalmer@hezmatt.org> wrote:

Imagine one of the big players saying, "we're going to charge you $X per route you send to us" (just like transit agreements that state, "we will charge you $X/GB of traffic"), or "your contract allows you to send us N routes" (just like, "your contract allows you to send us N Gb of traffic"). About 15 minutes later everyone else would start doing it, to recoup the costs of sending routes to that provider. Peering would be considered not only if the volume of traffic was mutually advantageous, but also if the routes exchanged were mutually advantageous.

Hi Matt, It doesn't work. Here's why not: First, there's an error in your bytes model. You express it as "your contract allows you to send us N Gb of traffic" but that's not accurate. It's send AND receive Gb of traffic. The two bottoms of the pyramid, sender and recipient both pay. Their fees combine with other fees as their ISP pays the next ISP up until it reaches two ISPs who "peer" with each other. The peers trade bytes which each has been paid by their endpoint to move to and from the other. This model works. We know it works because the Internet currently runs on it. Your route originator pays to have his route introduced into the system, and his ISP pays to have it introduced further up, and so on up to the top of the pyramid where two ISPs peer. Now you have a problem. How does the other side of the pyramid get paid carry the routes on the way back down? There are at least a couple of potential solutions to this problem. One solution is that you auction off the right to announce a covering route for each /8. Then your ISP deals with paying everybody in a reliable set of transit chains that announces your route to that aggregation carrier. The "auction" is sort upside down where instead of paying for the right to announce the covering route a company bids on offering the best price cross reliability guarantee on a RAND basis. Everybody is free to carry your specific route, of course, but those who choose not to will still be fully connected to you via the covering /8 route. Even if the packet starts its trip via the covering route, it won't necessarily reach the aggregator. As soon as it enters any network carrying your specific announcement, the packet veers off towards you. Another solution would be some kind of international route clearinghouse. Everybody operating BGP on the Internet joins the clearinghouse and specifies how much they charge to carry a route. Then for each route you wish to introduce, you pick all the ASes whose price you're willing to pay. You pay the clearinghouse. The clearinghouse does the accounting and provides each AS with their payment and the list of routes they're being paid to accept upon receiving an advertisement. Analysts with the clearinghouse evaluate all the ASes, their geography, size, connectedness and their required payments. They collect ASes into technically useful sets with an aggregate price which buyers can use instead of having to examine each AS for themselves. By design, these sets try to exclude small-time ASes asking for too much money (or any money) to carry your route. Finally, anybody who is not a "tier-1" transit free provider adds a default route to one or several of their upstream transit providers to carry packets for the routes they chose not to accept. So, if the clearinghouse analysts did their jobs well and you bought the route sets which made sense, you remain fully connected. 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

On Fri, Jan 31, 2014 at 03:10:56PM -0800, Owen DeLong wrote:

On Jan 31, 2014, at 1:29 PM, Matt Palmer <mpalmer@hezmatt.org> wrote:

...

Imagine one of the big players saying, "we're going to charge you $X per route you send to us" (just like transit agreements that state, "we will charge you $X/GB of traffic"), or "your contract allows you to send us N routes" (just like, "your contract allows you to send us N Gb of traffic"). About 15 minutes later everyone else would start doing it, to recoup the costs of sending routes to that provider. Peering would be considered not only if the volume of traffic was mutually advantageous, but also if the routes exchanged were mutually advantageous.

That’s the optimistic outcome. The pessimistic outcome is that they get rapidly depeered by everyone unwilling to pay $X/GB and then start losing customers because their customers can no longer reach anyone else’s customers through them.

That doesn't mean someone somewhere wouldn't try it. But I doubt it would be done in such a heavy-handed manner as to incur that sort of reaction. There are a bunch of ways it could be done quietly and without too much fuss. Vague language about "reasonable route volume" would be the easiest to slip under the radar, and if the cost of additional routes is below what your costs of changing providers would be, you'll almost certainly just wear it. Similar language could also be a big stick against excessive deagg, so there's a potential upside there, too. The blow could very easily be softened, too, by offering to pay all your customer for the routes they accept *from* you -- even setting it up so it was revenue neutral (in the beginning, at least...) so people get used to the idea. Hell, I could see it pitched as an up-sell: pay us $$$ and we'll accept your /28, and pass some of that moolah along to others so they'll do it too. Once it's in place for that, just keep shortening the masklen over time for what you can announce for free (presumably as fragmentation due to sale of blocks increases route volume). If Mark Andrews' assertion comes to pass, that legal action is taken against those unwilling to accept longer prefixes, I'd expect this sort of scheme to come to pass *very* quickly. If you're willing to accept routes from all comers, just in exchange for payment to cover costs incurred, then nobody can claim restraint of trade or cartel-like behaviour. If things got really hairy, providers could use their netflow data and some BigData(TM) analytics to work out the "value" vs the "cost" of every route they were carrying, and drop those who didn't make the grade (where you could increase the "value" of your route by paying for it). If there's one thing the commercial Internet has demonstrated, is that there isn't a business model so weird that *someone* won't try it.

The reality probably lies somewhere in between. I suspect whoever chooses to conduct this little experiment first should be prepared for substantial pain.

There's no possible upside unless there's some risk. I'm surprised nobody's tried this already, the more I think about it. Time to raise some VC, perhaps! - Matt -- Of course, I made the mistake of showing [a demo application] off to my boss, who showed it off to his boss, and suddenly I couldn't reboot my desktop box without getting a change control approved. -- Derick Siddoway, in a place that doesn't exist

In message <0A78151E-0FDB-4276-9B14-6A88E2941B2B@istaff.org>, John Curran writes:

On Jan 30, 2014, at 10:20 PM, Mark Andrews <marka@isc.org> wrote:

...

I figure there will be similar problem for other business in other countries and they will fight a similar battles. Eventually the regulators will step in because it is bad for small businesses to be shut out of the Internet.

Mark -

ISPS consciously breaking Internet services are bound to attract regulatory attention, but that does not necessarily mean that in the end there will be regulatory action. In the case of peering and route acceptance, it is fairly easy to show that there is a finite amount of routes that a given ISP can accept, and each of these routes has different value (i.e. some have large traffic flows, some are peer traffic engineering, some of required backup routes for shared multihomed corporate customers, etc.)

The result is not simple to regulate, because you can't just mandate "accept all routes offered" - some ISPs are already trimming what they accept to accommodate their particular flavor of routing hardware.

For last few decades, we've basically been relying on the IP allocation/assignment policies and their minimum block sizes as a proxy for the default "worth accepting" metric, but this may not prevail once there is serious pressure to fragment blocks to obtain better utilization. It would be nice if there was a way to fairly "settle up" for the imputed cost of adding a given route to the routing table, as this would provide some proportionate backpressure on growth, would create incentives for deaggregate cleanup, etc. We don't have such a system, so it falls to each ISP to decide what route is worth accepting based on type and the offering peer's business relationship...

FYI, /John

I understand this but this block changes the status quo. It is a policy changer. AFAIK ARIN hasn't done allocations to the /28 level like this in the past. This is all new territory. Concentrating the allocation is a good thing as it allow selective extentions of the filter lengths. This is about a potential 1.6% global growth of routes. It's not 1500% potential growth that a global /24 -> /28 would give.

Disclaimer: My views alone. Note - I haven't had enable on any backbone routers in this _century_, so feel free to discount/discard if so desired. ;-) -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org

On Fri, Jan 31, 2014 at 6:45 PM, Tore Anderson <tore@fud.no> wrote:

What I fail to understand from this thread is the apparent expectation that these smaller-than-/24 microscopic delegations from ARIN will be popular.

Hi Tore, There is every expectation that they will be unpopular. They're a hedge against the possibility of a grueling last-minute IPv6 conversion following a failed IPv4 market. They're something that can, with difficulty, be made to work. They serve no other purpose. 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

I will attempt to clarify this once more... When I wrote the policy which created this set-aside space, it was, as Bill has said, intended as a hedge to provide minimal resources for organizations that are unable to obtain larger IPv4 blocks through any normal mechanism (standard allocation/assignment, transfer, market, etc.) and desperately need some space which they can hopefully get routed to support the bare minimum IPv4 connectivity for their IPv6 environment. I expect that if use of these blocks does become necessary, then routing them will almost certainly be the least of the problems we face in that circumstance. It is my sincere hope that we come to our senses and implement IPv6 sufficiently that these blocks are never needed. However, as the saying goes, I am hoping for the best and planning for the worst. The ARIN community overwhelmingly supported this idea at the time and that is why we set aside the block in question. In answer to Tore's statement, this block does not apply the standard justification criteria and I think you would actually be quite hard pressed to justify a /24 from this prefix. In most cases, it is expected that these would be the IPv4 address pool for the public facing IPv4 side of a NAT64 or 464xlat service. Most organizations probably only need one or two addresses and so would receive a /28. It is expected that each of these addresses likely supports several thousand customers in a service provider environment. Owen

On Jan 31, 2014, at 7:38 PM, Bryan Socha <bryan@serverstack.com> wrote:

has it be clarified by arin on why they are going to allocate /28s? seems a faster way to waste ipv4 space with unusable ip addresses? The only thing I can think of is micro allocations for IX points.

*Bryan Socha* Network Engineer 646.450.0472 | *bryan@serverstack.com <bryan@serverstack.com>*

*ServerStack* | Scale Big

...

On Fri, Jan 31, 2014 at 6:58 PM, William Herrin <bill@herrin.us> wrote:

...

On Fri, Jan 31, 2014 at 6:45 PM, Tore Anderson <tore@fud.no> wrote: What I fail to understand from this thread is the apparent expectation that these smaller-than-/24 microscopic delegations from ARIN will be popular.

Hi Tore,

There is every expectation that they will be unpopular. They're a hedge against the possibility of a grueling last-minute IPv6 conversion following a failed IPv4 market. They're something that can, with difficulty, be made to work. They serve no other purpose.

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

Without making a policy proposal, (yet), it might make sense to have a suggestion to ARIN that if it *does* end up allocating multiple /28s from one /24 intermediate, that the /24 be regionally reserved so that all sub-blocks are physically nearby and could collaborate on a cooperative /24 global announcement and internal side split-out... -george william herbert george.herbert@gmail.com Sent from Kangphone On Jan 31, 2014, at 5:14 PM, Owen DeLong <owen@delong.com> wrote:

I will attempt to clarify this once more...

When I wrote the policy which created this set-aside space, it was, as Bill has said, intended as a hedge to provide minimal resources for organizations that are unable to obtain larger IPv4 blocks through any normal mechanism (standard allocation/assignment, transfer, market, etc.) and desperately need some space which they can hopefully get routed to support the bare minimum IPv4 connectivity for their IPv6 environment.

I expect that if use of these blocks does become necessary, then routing them will almost certainly be the least of the problems we face in that circumstance.

It is my sincere hope that we come to our senses and implement IPv6 sufficiently that these blocks are never needed. However, as the saying goes, I am hoping for the best and planning for the worst. The ARIN community overwhelmingly supported this idea at the time and that is why we set aside the block in question.

In answer to Tore's statement, this block does not apply the standard justification criteria and I think you would actually be quite hard pressed to justify a /24 from this prefix. In most cases, it is expected that these would be the IPv4 address pool for the public facing IPv4 side of a NAT64 or 464xlat service. Most organizations probably only need one or two addresses and so would receive a /28. It is expected that each of these addresses likely supports several thousand customers in a service provider environment.

Owen

...

On Jan 31, 2014, at 7:38 PM, Bryan Socha <bryan@serverstack.com> wrote:

has it be clarified by arin on why they are going to allocate /28s? seems a faster way to waste ipv4 space with unusable ip addresses? The only thing I can think of is micro allocations for IX points.

*Bryan Socha* Network Engineer 646.450.0472 | *bryan@serverstack.com <bryan@serverstack.com>*

*ServerStack* | Scale Big

...

On Fri, Jan 31, 2014 at 6:58 PM, William Herrin <bill@herrin.us> wrote:

...

On Fri, Jan 31, 2014 at 6:45 PM, Tore Anderson <tore@fud.no> wrote: What I fail to understand from this thread is the apparent expectation that these smaller-than-/24 microscopic delegations from ARIN will be popular.

Hi Tore,

There is every expectation that they will be unpopular. They're a hedge against the possibility of a grueling last-minute IPv6 conversion following a failed IPv4 market. They're something that can, with difficulty, be made to work. They serve no other purpose.

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

While the policy text does not spell out a list of technologies, I believe that the clear intent of the community from the discussions and from the examples given in the policy text was for minimal IPv4 allocations to support the transition process. While no ratio is given in the policy text, I doubt that a “we have 200 customers wanting to do 6RD” would be accepted as justification for a /24. However, I am merely speculating here. I don’t have any direct answers from ARIN staff about how the policy would be interpreted. My statements are strictly my own personal interpretation of the community intent and an expression of my intent as the author of the policy. Owen On Feb 1, 2014, at 3:44 AM, Tore Anderson <tore@fud.no> wrote:

* Owen DeLong

...

In answer to Tore's statement, this block does not apply the standard justification criteria and I think you would actually be quite hard pressed to justify a /24 from this prefix. In most cases, it is expected that these would be the IPv4 address pool for the public facing IPv4 side of a NAT64 or 464xlat service. Most organizations probably only need one or two addresses and so would receive a /28. It is expected that each of these addresses likely supports several thousand customers in a service provider environment.

This latter expectation of over-subscription is not echoed by the policy text itself. One of the valid usage examples mentioned («key dual stack DNS servers») would also be fundamentally incompatible with an requirement of over-subscription. If you look at the common transitional technologies you'll see that not even all of them do support over-subscription. In alphabetical order:

- 6RD: No over-subscription possible, would require at least one IPv4 address per subscriber plus additional addressing required for the transport/access network.

- 6PE/6VPE: No over-subscription possible, the infrastructure must be numbered normally with IPv4.

- DS-Lite (AFTR): Over-subscription possible, but it's entirely reasonable to want to make the ratio as low as possible, in order to provide as many source ports as possible to the subscriber, to ease abuse handling, and so on.

- MAP: Similar to DS-Lite, but is less flexible with regards to over-subscription, as all users in a MAP domain must get the same amount of ports. Thus the maximum over-subscription you can achieve is limited by your most active subscriber in his peak period of use, i.e., if you have a subscriber whose usage peaks to 20k ports, then that MAP domain can only support a 2:1 over-subscription ratio. MAP can also be configured in a not over-subscribed 1:1 mode.

- NAT64: Same as DS-Lite.

- SIIT: No over-subscription possible, as it's by design a 1:1 mapping.

That said, the policy language does say «ARIN staff will use their discretion when evaluating justifications». So I suppose it is theoretically possible that the ARIN staff will do their best Dr. Evil impression, coming up with a big number N, and require requestors to have a N:1 over-subscription ratio to qualify. However, that would be better described as indiscretion, not discretion, IMHO. After all, the RIRs are book-keepers, not network operators; if a network operator makes a reasonable request, it isn't the RIR's place to second-guess their network deployment. If ARIN is doing that, they're overstepping.

So in summary it seems to me that it is pretty easy to make a reasonable request for a /24 under this particular policy, and especially considering the immense routing benefit the /24 will have over all the other possible prefix lengths that can be requested (persuading providers/peers to accept /28s might be done on a small scale, but just won't work if you need global connectivity, and global connectivity is what end users expect), the only realistic outcome I can see is that [almost] all the requestors will go ahead and ask for the /24. We'll just have to wait and see, I guess.

Tore

Tore Anderson wrote: [...]

It's not exactly new. Like I've mentioned earlier in this thread, the RIPE NCC has granted assignments smaller than /24 to requestors since, well, "forever". There are currently 238 such assignments listed in delegated-ripencc-extended-latest.txt. However, these microscopic assignments have proven hugely unpopular, amounting for only a fraction of a percent of the total (there are 27733 assignments equal to or larger than /24 in the same file).

If I remember correctly, while some (most?) people were disappointed by the lack of a minimum size for PI assignments, others valued the ability to register addresses for interfaces that needed to be unique but did not require global connectivity. Regards, Leo

On Fri, Jan 31, 2014 at 05:10:51AM -0800, Owen DeLong wrote:

...

A /8 slot costs as much as a /28 slot to hold process etc. A routing slot is a routing slot. The *only* reason this isn't a legal problems at the moment is people can still get /24s. The moment /24's aren't readily available and they are forced into using this range anyone filtering on /24 in this range is leaving themselves open to lawsuits.

On what basis? How do you have the right to force me to carry your route on my network? Especially in light of the recent strike-down of the net neutrality rules?

...

Now as this range is allocated for transition to IPv6 a defence for edge networks may be "we can reach all their services over IPv6" but that doesn't work for transit providers. Eyeball networks would need to ensure that all their customers had access to IPv6 and even that may not be enough.

Please point to the law which requires a transit provider to provide transit to every tiny corner of every internet.

Speaking only with respect to the US: I am aware of no such law. However, I am aware of a law that makes it unlawful for a bunch of large providers who already have large blocks of space to collude to prevent new entrants into the market by refusing to carry their routes. If the guy with the /28 he can't route alleges that that's what's happening, there are lots of arguments on the other side the ISPs with the filters could make. They've been filtering at /24 for a lot longer than it started to seriosuly harm new entrants into the market ... there was never any formal agreement to filter at /24; it just happened (but everyone ended up filtering at /24 ... that wasn't just coincidence) ... there are real technical reasons for limiting FIB size ... and so on. I don't know who would win the anti-trust lawsuit, but I wouldn't consider it a slam dunk for the ISPs doing the filtering. I don't expect there to actually be such a lawsuit. Among other things, buying a /24 will likely be cheaper than litigating this, so the only way it gets to trial is an organization litigating on principle. And, as I said, I'm not convinced the filtering providers lose if there is one. But anytime the big guys collectively have a policy that keeps out the new entrants, there's anti-trust exposure. -- Brett

On Friday, January 31, 2014 01:58:58 AM Mark Andrews wrote:

This range adds a maximum of 245760 (2^18-2^14) routes to the global routing table. Do you really want to go to court for this many routes?

There is also a reasonable chance that acceptance of /28's could be strict in the beginning. But at some point, I imagine some operators (either due to lack of clue or just laziness) will simply write "everything else up to /28", and then routers on the Internet will start to pick up a lot of the gunk that "up to /24" filters have been keeping at bay. Prefixes longer than /24 (or /48) are especially common at exchange points, either by mistake or design. Mark.

On Jan 29, 2014, at 10:22 PM, Christopher Morrow <morrowc.lists@gmail.com> wrote:

maybe these weren't meant to be used outside the local ASN? :) I do wonder though what the purpose of this block is? If it's to be used inside the local ASN (as seems to be indicated based upon minimum allocation sizes) then why not use the IETF marked 100.64/10 space instead? Global-uniqueness? ok, sure...

Seems like the obvious use case is for 6to4 NAT gateways, which would mean that global reachability would be expected. -Phil

On Wed, 29 Jan 2014 14:16:43 -0800, Seth Mattinen wrote:

On 1/29/14, 14:01, Leslie Nobile wrote:

...

Additionally, ARIN has placed 23.128.0.0/10 in its reserves in accordance with the policy "Dedicated IPv4 block to facilitate IPv6 Deployment" (NRPM 4.10). There have been no allocations made from this block as of yet, however, once we do begin issuing from this block, the minimum allocation size for this /10 will be a /28 and the maximum allocation size will be a /24. You may wish to adjust any filters you have in place accordingly.

I know ARIN doesn't care about routability and all that, but good luck with those /28s.

"This block will be subject to a minimum size allocation of /28 and a maximum size allocation of /24. ARIN should use sparse allocation when possible within that /10 block." Thanks for the initial sparse allocation for some time the /28 will be the only tennant of the covering /24 so they will be able to advertise the /24 aggregate as well as the /28. In time the reachability of the /28s should improve and if some other /28 is allocated inside an already populated /24 then as long as they can both see each other's /28s they can still both advertise the /24 aggregate - or perhaps agree for a common transit provider to do it. As acceptance of the /28s improves further and less traffic flows to the aggregates, perhaps large providers would agree to replace the customer /24 aggregates with a single /10 aggregate to help out the (hopefully few) stragglers who still filter /28s. -Rob