[168626] in North American Network Operators' Group
Re: Updated ARIN allocation information
daemon@ATHENA.MIT.EDU (George William Herbert)
Fri Jan 31 22:10:52 2014
In-Reply-To: <ED4E41F9-7600-4995-A5BC-650B633EF2DD@delong.com>
From: George William Herbert <george.herbert@gmail.com>
Date: Fri, 31 Jan 2014 19:10:18 -0800
To: Owen DeLong <owen@delong.com>
Cc: "nanog@nanog.org List" <nanog@nanog.org>, Tore Anderson <tore@fud.no>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
Without making a policy proposal, (yet), it might make sense to have a sugge=
stion 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 ar=
e physically nearby and could collaborate on a cooperative /24 global announ=
cement 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...
>=20
> When I wrote the policy which created this set-aside space, it was, as Bil=
l has said, intended as a hedge to provide minimal resources for organizatio=
ns that are unable to obtain larger IPv4 blocks through any normal mechanism=
(standard allocation/assignment, transfer, market, etc.) and desperately ne=
ed some space which they can hopefully get routed to support the bare minimu=
m IPv4 connectivity for their IPv6 environment.
>=20
> I expect that if use of these blocks does become necessary, then routing t=
hem will almost certainly be the least of the problems we face in that circu=
mstance.
>=20
> It is my sincere hope that we come to our senses and implement IPv6 suffic=
iently 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 overwhel=
mingly supported this idea at the time and that is why we set aside the bloc=
k in question.
>=20
> In answer to Tore's statement, this block does not apply the standard just=
ification criteria and I think you would actually be quite hard pressed to j=
ustify a /24 from this prefix. In most cases, it is expected that these woul=
d be the IPv4 address pool for the public facing IPv4 side of a NAT64 or 464=
xlat 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 s=
upports several thousand customers in a service provider environment.
>=20
> Owen
>=20
>=20
>> On Jan 31, 2014, at 7:38 PM, Bryan Socha <bryan@serverstack.com> wrote:
>>=20
>> has it be clarified by arin on why they are going to allocate /28s? see=
ms
>> a faster way to waste ipv4 space with unusable ip addresses? The only=
>> thing I can think of is micro allocations for IX points.
>>=20
>> *Bryan Socha*
>> Network Engineer
>> 646.450.0472 | *bryan@serverstack.com <bryan@serverstack.com>*
>>=20
>> *ServerStack* | Scale Big
>>=20
>>=20
>>> On Fri, Jan 31, 2014 at 6:58 PM, William Herrin <bill@herrin.us> wrote:
>>>=20
>>>> 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.
>>>=20
>>> Hi Tore,
>>>=20
>>> 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.
>>>=20
>>> Regards,
>>> Bill Herrin
>>>=20
>>>=20
>>>=20
>>> --
>>> William D. Herrin ................ herrin@dirtside.com bill@herrin.us
>>> 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
>>> Falls Church, VA 22042-3004
>=20
