Updated ARIN allocation information

Sat Feb 1 11:44:58 UTC 2014

* 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