[168569] in North American Network Operators' Group
Re: Updated ARIN allocation information
daemon@ATHENA.MIT.EDU (Owen DeLong)
Thu Jan 30 10:43:20 2014
In-Reply-To: <CAL9jLabq=CSJSv4hufv+LSJ4d2JBhLQPukDcX3gxtc6-1PZA=A@mail.gmail.com>
From: Owen DeLong <owen@delong.com>
Date: Thu, 30 Jan 2014 10:34:56 -0500
To: Christopher Morrow <morrowc.lists@gmail.com>
Cc: nanog list <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
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 organization=
s which need some amount of IPv4 for a best-effort to facilitate networking a=
fter IPv4 general runout.
While I recognize that organizations may or may not be able to get these rou=
tes 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 allow=
ing chaos through the entire address space.
Indeed, much popcorn will be required. That is why my networks are all IPv6 c=
apable already.
Owen
> On Jan 29, 2014, at 10:22 PM, Christopher Morrow <morrowc.lists@gmail.com>=
wrote:
>=20
>> On Wed, Jan 29, 2014 at 5:16 PM, Seth Mattinen <sethm@rollernet.us> wrote=
:
>>> On 1/29/14, 14:01, Leslie Nobile wrote:
>>>=20
>>> Additionally, ARIN has placed 23.128.0.0/10 in its reserves in accordan=
ce
>>> with the policy "Dedicated IPv4 block to facilitate IPv6 Deployment" (NR=
PM
>>> 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 allocatio=
n
>>> 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.
>>=20
>>=20
>>=20
>> I know ARIN doesn't care about routability and all that, but good luck wi=
th
>> those /28s.
>=20
> 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...
>=20
> There will need to be popcorn though, for this event.
>=20
> -chris