Orbit

Geoff Huston wrote:

Scott,

Thank you for your comments.

You're welcome: I'm glad my criticism was receptively accepted as constructive.

You phrase in objective text what I would see as some interpretations and perspectives. While it is clear to me that you hold these views and perspectives, it is not clear to me that these are necessarily objective truths.

Of course, my views do reflect my own opinions, interpretations, and perspective. I don't have any religious delusions that such views represent objective truths, but I do hope to encourage you and others to consider this policy proposal from such a perspective.

There is considerable uncertainty on the true capabilities of the routing system and its not entirely clear to me what limitations exist in the routing system as distinct from various impressions of what such limits may be. I would think it less than entirely appropriate to base policy on such perceptions of the nature of the inter-domain routing system and its capabilities, and even less appropriate to phrase current policy on perceptions of what such limits may have been some years ago.

I agree there is much uncertainly in the capabilities of the routing system, both now and in the future. However, I believe that the best course of action in the face of such uncertainty is to leave our options open, as much as possible, to take future action to respond as future capabilities, limits, and requirements become better known.

What appears to me is that we are in a situation where:

We are facing a transition to IPv6 that requires the operation of a dual stack environment where both future and existing deployments require access to both IPv4 and IPv6 address space. We are facing a transition that is complex. This transition probably will take an extended period of time, and probably will take much longer than the anticipated time remaining in the unallocated Ipv4 address space pool. So we can anticipate that new network deployments will take place after this pool exhaustion time, but they will still need IPv4 addresses in order to support dual stack operation as part of the overall IPv6 transition. [references removed]

Agreed.

But the RIRs will be unable to assist them, as their address pools are empty at that time. So, in the absence of alternatives, its likely that we will see various forms of IPv4 address transfer take place in order to meet these continuing demands for address space during this dual stack transition period.

If we continue on our current course, that will likely be true. We are not without policy options, both for preventing the complete exhaustion of the IPv4 free pool and for dealing with a world in which pretty much all IPv4 addresses have already been allocated/assigned. (One such option, of course, is the one we're discussing.)

Now, in terms of registry policy, can either allow such transfers to be recorded in the registry system or we can choose to deny access to the registry system. The registry system underpins the concepts of uniqueness, consistency, coherency, accuracy and integrity of the network's address plan. If the registry cannot fulfil this function then the utility of the entire network is severely undermined. Chaos in addresses is chaos in the network.

The extent to which other policies can be intertwined with this measure of transfer registration is uncertain. The higher the barrier of entry to the registry the higher the temptation to avoid registration altogether, raising the potential risks referred to above.

I think I agree with you on the need to allow such transfers to be recorded in the registry system and try to avoid the potential risks referred to above.

The transfer policy proposal being proposed in the APNIC policy forum is deliberately phrased as one that is simple and direct, and it tries to get to the heart of what needs to be undertaken in terms of roles of the registry in an environment where the associated address allocation function has finished through address pool exhaustion, yet the demand for uniqueness, consistency, coherency, accuracy and integrity in the registry function remains. In such an environment the registry needs to be in a position to accurately reflect the reality of address distribution.

Agreed.

For that reason the policy proposal is quite limited in its scope, as it addresses quite directly the concept of including in the policy framework a capability to admit access to the registry in order to record address transfers.

This is, I think, the heart of our disagreement. I see prop-050 as quite broad in scope, in that it not only allows APNIC to record transfers, but it allows the full and complete deaggregation of allocated and assigned resources. In my opinion, that significantly, and unnecessarily, broadens the scope of the proposal beyond what is reasonable and prudent.

As APNIC manages fewer legacy allocations (such as Class A and Class B netblocks given out before the creation of the RIRs), and has been more successful in bringing such early registrations under the same set of policies as APNIC allocations and assignments, I think APNIC has far fewer fairness issues to deal with than ARIN does in considering a regulated market in IPv4 addresses. Therefore, I would not oppose prop-050 (for the APNIC region) if it were revised along these lines:

Rather than "Only IPv4 address blocks equal to, or larger than, a /24 prefix may be transferred.", require that "Only complete IPv4 allocations may be transferred".

Later on, if demand is sufficiently high, this could be relaxed further to something like "IPv4 address blocks may only be transferred in sizes equal to, or larger than, the minimum allocation size defined for that address range as documented at http://www.apnic.net/db/min-alloc.html".

I believe these relatively minor changes to prop-050 would preserve the benefits of a regulated market in IPv4 addresses without abandoning the goals of aggregation and hierarchical allocation, and would eliminate much of the risk to the routing system of the complete deaggregation of many large APNIC-managed netblocks.

-Scott