FW: Updated ARIN allocation information

Mailman List Mirror (Read Only)
21

I almost hesitate to mention this, just in case I put ideas into some
beancounter's head, but it seems to me that the cost model of carrying
packets isn't that different to carrying routes. In both cases, practically
everyone is acting as a middleman, and money flows hither and yon and
(presumably) balances out in the end, with everyone having their costs
covered with a little left over for the shareholders.

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.

- Matt

22

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

23

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

24

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

I almost hesitate to mention this, just in case I put ideas into some
beancounter's head, but it seems to me that the cost model of carrying
packets isn't that different to carrying routes. In both cases, practically
everyone is acting as a middleman, and money flows hither and yon and
(presumably) balances out in the end, with everyone having their costs
covered with a little left over for the shareholders.

Meh, sort of…

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.

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

YMMV.

Owen

25

* Mark Andrews

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.

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

What I fail to understand from this thread is the apparent expectation
that these smaller-than-/24 microscopic delegations from ARIN will be
popular. As I read the policy in question, the requestors may get a /24
instead. That's a pretty miniature block to begin with and trivial to
justify, and given human nature of wanting to grab as much of something
as you can (especially when you in all likelihood cannot get nearly as
much as you actually need), coupled with the fact that a /24 is likely
to be immensely more useful than anything smaller...well, I just don't
see why we shouldn't realistically expect that pretty much all of the
assignments being made from this block will be exactly /24, and that
exceptions that prove the rule will amount for <1% of the total - just
like we've seen happen in the RIPE region.

Oh well. Time will tell, I suppose.

Tore

26

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

27

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

28

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

29

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

30

I get the idea behind it, but it really has no real world usage. I can
still find 15 year old swips from people with /8s who keep getting more
addresses. Break out the audits before their next blocks.

31

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

32

> 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

33

Maybe I need to buy stock in General Mills, I forsee a run on
Betty Crocker cake mixes... :slight_smile:

34

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.

Sure… The Sherman Anti-Trust act. However, in order to bring a successful
action under that act, one must prove that they colluded on the decision, rather
than simply arriving at that decision independently. Since the current status quo
is not carrying longer routes in general, it would be pretty hard to show that they
colluded to avoid changing their policy.

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.

In the current regulatory environment with the current US courts, I’d say it’s
pretty close to a slam dunk. However, IANAL and YMMV definitely applies here.

As a practical matter, it’s also awfully expensive for the little guy to bring enough
lawyers to bear on one of the large providers to stand a chance of not being
simply buried in procedural paperwork and discovery. The little guy would have
to have pretty strong backing or pretty deep pockets to survive the process.

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.

Only if you can prove collusion. For civil matters, it’s just by preponderance of
the evidence, but if the DoJ or some District Attorney or Attorney General decides
to take the matter up as a criminal case, then the burden shifts to beyond a
reasonable doubt.

As much as I wish there were a way to require the big guys to be nice to the
little guys, the reality is that the precedent such a case would set (being able
to require a network to carry arbitrary traffic whether or not doing so is in that
networks own best interest and regardless of the cost/benefit ratio, etc.) is
a very dangerous precedent. Once that one is on the books, imagine how the
big guys could use it to bankrupt the little guys…

The other option, of course, is that the big guys simply start charging the registered
prefix holder for every route they accept. Then, they are free to offer discounts up
to 100% to any providers they choose to offer such discounts to, but the little guys are
still shafted.

Bottom line, the big guys have enough resources and know how to play the
regulatory and litigation games well enough that I just don’t see the little guy
achieving anything but a pyrrhic victory at best.

Owen

35

* 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

36

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

37

Owen -

   To be clear, ARIN is inclined to approve requests whenever it is possible
   to do such in compliance with policy. Given the leeway in the present
   policy text, we're likely to approve any reasonable request which is made
   under this policy, and it would not be difficult to imagine requests for
   /24 being approved as a result. If pooled use/oversubscription or specific
   technologies are required, it would be very helpful to provide additional
   policy text to staff.

Thanks!
/John

John Curran
President and CEO
ARIN

38

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.

39

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

40

ARIN would like to share two items of information that may be of interest
to the community.

First, ARIN has recently begun to issue address space from its last
contiguous /8, 104.0.0.0 /8. The minimum allocation size for this /8
will be a /24. You may wish to adjust any filters you have in place
accordingly.

I was surprised that ARIN started issuing from this /8. I thought it
still had a /9 and a /10 in inventory.

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 see the note at
https://www.arin.net/resources/request/ipv4_countdown.html
that this block is not included in inventory. Thanks for that.

Lee