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.
More information on the IP address space administered by ARIN can be found on our web site at:
https://www.arin.net/knowledge/ip_blocks.html
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.
More information on this policy can be found on our website here:
https://www.arin.net/policy/nrpm.html#four10
Regards,
Leslie Nobile
Director, Registration Services
American Registry for Internet Numbers (ARIN)
I know ARIN doesn't care about routability and all that, but good luck with those /28s.
~Seth
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
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.
Mark
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.
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.
jms
* 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
Depends on the burn rate on that /10...
jms
As the author of the policy which set this block aside, I speak only from my perspective as the author and not officially on behalf of ARIN or the AC in any way:
The intent is to provide very small allocations/assignments for organizations which need some amount of IPv4 for a best-effort to facilitate networking after IPv4 general runout.
While I recognize that organizations may or may not be able to get these routes accepted, the reality is that IPv4 runout is going to create interesting routing scenarios and other problems. I figured having a predictable prefix where people could at least make a best effort was better than simply allowing chaos through the entire address space.
Indeed, much popcorn will be required. That is why my networks are all IPv6 capable already.
Owen
Seems like the obvious use case is for 6to4 NAT gateways, which would mean that global reachability would be expected.
-Phil
"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
https://www.arin.net/policy/nrpm.html#four10
"4.10 Dedicated IPv4 block to facilitate IPv6 Deployment
When ARIN receives its last /8 IPv4 allocation from IANA, a contiguous
/10 IPv4 block will be set aside and dedicated to facilitate IPv6
deployment. Allocations and assignments from this block must be
justified by immediate IPv6 deployment requirements. Examples of such
needs include: IPv4 addresses for key dual stack DNS servers, and
NAT-PT or NAT464 translators."
This was set aside just in case the IPv4 market doesn't pan out and
you can no longer get BGPable /24's. The presumption is that if we hit
the kind of crunch this block is reserved for, convincing folks to
route /28's will be the least of our problems.
Regards,
Bill Herrin
i suspect it will be more sean doran style 'pay me for your slot'.
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.
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.
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?
Mark
Because why? Cartels? Illuminati? I want to travel by stargate. Who do I sue?
~Seth
> 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?
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
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.
Hopefully most/all eyeball networks will be delivering IPv6
connectivity before allocations like these are needed. Collectively
you only have yourselves to blame if there are needed in earnest.
Mark
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'.
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. Please do so for all nations where
this may be an issue.
Owen
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. 