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