[ppml] Arguments against Policy Proposal: IPv4 Soft Landing

[David Conrad]

Alain,

Thanks for the comments.

On May 22, 2007, at 1:19 PM, Durand, Alain wrote:
> 1) This might be just too late to be effective give current projected
> end date
>    In practice, there could be only 1 or 2 steps, no more.

I'm in the process of revising the number of phases, however I still  
am of the opinion that projected end dates are largely exercises in  
deriving random numbers given it is essentially impossible to  
incorporate socio-economic factors that will likely have significant  
impact on consumption rates.  The reason I have chosen to revise the  
number of phases (to 4 from 6) is to simplify the policy somewhat.

> 2) This creates an increase risk of a 'run to the bank' before
>    the current set of policies change

The IPv4 free pool is nearing exhaustion.  Given human nature, a "run  
on the bank" will almost certainly occur regardless of what policies  
are imposed and I'm not sure how "Soft Landing" increases this risk.   
The point of increased requirements such as the 3rd party audit is to  
reduce the likelihood of people simply making up numbers to get  
allocations.  Will such making up of numbers occur?  Sure.  
Suggestions on how to keep people from making a 'run on the bank'  
happily accepted (and may be forwarded to the Nobel Prize committee  
for possible consideration for the award for Economics).

> 3) Increasing allocation efficiency comes with a cost.
>    This will mean smaller and smaller prefixes will have to be routed

Yes.  This will also almost certainly be occurring regardless of what  
policies are imposed.  A natural outcome of IPv4 free pool exhaustion  
is that people will notice they have lots of address space they  
aren't using or could use more efficiently (e.g., MIT) and hence,  
more specifics from the "legacy" allocations will begin to appear.  I  
would argue that "Soft Landing" is unlikely to have a significant  
impact on the number of prefixes or that will appear.

However, folks at router vendors who can reasonably be assumed to  
know what they are talking about have indicated that router  
scalability isn't a concern for 5 to 10 years.  While I am not sure I  
believe them, there is at least some room for argument that the  
routing system can withstand the flood of longer IPv4 prefixes that  
will be coming.

> 4) Efficiency above 80%.
>
>    For an organization that does allocation from fairly large blocks
>    all the way up to end devices , 80% efficiency is already a very
>    high tartget to achieve and it is not feasable to go much above.
>    We may shoot for 81 or 82% with great difficulties, but 90% and
>    above is irrealistic.

I would be interested in understanding this point more, perhaps  
privately.  I do not have enough data to fully appreciate your  
concerns here.  However, the IPv4 free pool is nearing exhaustion so  
it is unlikely that the processes and procedures used when IPv4 was  
plentiful will continue to be appropriate.

> 5) "Recycling of x% of IPv4 address space formerly used for internal
>    infrastructure"
>
>    This may simply not be feasable. A large number of infrastructure
>    devices are not upgradable to IPv6 due to physical constraints
>    (eg: not enough memory). In environments like the one I'm working
>    on, even with the most aggressive IPv6 plans, a very large number
>    of legacy infrastructure devices will never be upgraded to IPv6.
>    The new ones will, not the legacy ones.

In such cases, is there a reason you cannot use RFC 1918 for the  
legacy devices?

>    More generally, I would like to stress that ARIN has no business
>    to mandate that an organization be forced into a hardware change.

Then you have concerns about the liberalization of PI allocation  
policies since they're going to cause ISPs to upgrade their hardware?

I agree the policy cannot mandate a hardware change and, in fact, it  
does not do so.  ARIN may, however, impose policies that may best  
(but not exclusively) be met by upgrading hardware infrastructure.   
The IPv4 free pool is nearing exhaustion, thus new allocations of  
that scarce resource should be reserved for the most critical needs  
and efforts should be undertaken to reuse inefficiently used previous  
allocations where possible.

>  6) "* Documented availability of production IPv6 infrastructure
> services
>      * Documented availability of production IPv6 connectivity  
> service"
>
>     This doesn't mean very much. Anybody can set up a web server
>     with a 6to4 address and claim it satisfy this requirement!

Yes.  Presumably, the mechanisms ARIN staff use to determine  
conformance to this requirement would be able to discern between  
folks who are pretending to meet the requirement and those who do  
meet the requirement.  However, I do not believe the mechanisms  
should be specified in the policy.

>     What you would really want is to say something along the lines
>     of the requester should offer IPv6 service on par with IPv4  
> service

I do not believe ARIN can mandate exactly what services are provided  
or how they are provided.  I personally do not believe there will be  
a one-to-one mapping between IPv4 and IPv6 services.  The best we can  
hope for is that the deployment of _some_ IPv6 services will trigger  
the deployment of sufficient IPv6 infrastructure to allow us to  
migrate in a reasonable fashion.

> Given all the above points, I'm not in favor of this policy.

Understood.  However, given the IPv4 free pool is nearing exhaustion,  
I would be interested in understanding what your view of the  
alternatives are.

Rgds,
-drc