Updated ARIN allocation information

Sat Feb 1 13:42:20 UTC 2014

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