Orbit

I agree that this proposal should be addressed globally, but the mechanism for doing so is not clear, and time is "short" because of the runout situation. One possibility would be for it to be adopted regionally though this proposal, and for it to be expanded to other regions in time (using the same address block) - after all, once it's been adopted in one region, there would be nothing to stop it being adopted in others.

The question is whether there are any roadblocks to its adoption as a regional proposal, so following up on a couple of issues that Geoff raised:

1. That a region/RIR can't make locally-based routing system decisions, but that these need to be made instead at an IETF/IANA level. I agree with one of Randy's points on this - the IETF is not an operationally-based organisation (at least any more, if it ever was). For example, I don't believe that RFC1918 is actually a standard, but is rather a Best Common Practice. It is only the community consensus that ensures that those "private" ranges are not routed - through the active setting of routing filters throughout the Internet. [Note that I believe that this is different from the > 240.0.0.0 range, where the reservation was made inside the protocol specification, and consequently there have may have arisen technology blocks in implementations that prevent the practical usage of that range.] I do likewise agree that an RIR itself is not responsible for the public routing system. But if RFC1918 is a consensus-based routing arrangement, then surely a regionally-based consensus is also possible and valid, and an RIR would be a good place to record the address range underlying that consensus.

2. That IANA could not recognise the use of a regionally-reserved range as valid and allocated. To my mind this is the more complicated issue - i.e. what are the conditions that are required to be met by an RIR with respect to the use of IANA allocations? I admit that I am not enough of an expert in IANA articles to be able to comment. Is anyone able to supply appropriate references to any written materials on this? For example, could APNIC notionally allocate it to itself or a nominated steward like an NIR - even to the extent of setting up a black-holed route if that were required - to satisfy any requirements for allocation? (Please note that this is just a hypothetical question, and not a recommendation.) So I believe that a regional consensus to not route a range should be feasible, but the key question is whether APNIC is allowed by its relationship with IANA to reserve a range for such a purpose. (And what could be done to allow it?)

My reason for supporting the conceptual basis of this proposal is that an additional range would significantly ease the complexity of the operations associated with hierarchical addressing domains.

It is often the case with IP that almost any scenario can be made to work if you cobble it together enough, but the reality may be that just because it is possible doesn't make it practical or efficient to do so. I believe that this is a case here - RFC1918-RFC1918 NATing may work in many circumstances, but making it robust enough to survive all real world scenarios is another matter. This is especially true in the ISP-customer relationship, where the details of the local customer arrangements and the capabilities of the customer equipment are unlikely to be within the control of the ISP.

Creating solidly engineered solutions to cover a customer product based on RFC1918-RFC1918 NAT can be very expensive, and - when the benefits are considered across the entire ISP industry - I'd argue that a separate address block would be an improved solution and less costly, even within the context of the looming address runout.

I repeat that I would prefer to see this dealt with at a global level, but if the Asia-Pacific region believes it has a strong requirement for this which is not reflected in the global sphere, then I'd rather have a regionally local arrangement than no arrangement at all.

Regards,

David Woodgate

At 11:30 AM 22/02/2008, Geoff Huston wrote:

...

If this proposal reached consensus it could be presented (introduced?) to the other region and/or IETF/IANA.

I would like to refer to the process used in the implementation of IPv6 documentation prefix. Can someone explain that process?

I'll give it a shot (and make some related observations as well!)

This policy proposal raises the question of the precise nature of this proposal, and in particular whether you are in fact raising a matter for IANA to act upon, in which case this may be more appropirately phrased as a Global Policy Proposal, or indeed whether this is a matter for the RIR policy process to determine or whether this is a matter for an Internet Standards action on the part of the IETF.

The RIRs are the duly recognised address distributors of global unicast address space in their respective regions, and are the recognised body for the development of policies concerning this distribution function in their regions. The RIRs have no authority in terms of the routing system of the public internet, and have maintained the position that while they distribute address blocks they have no role in determining whether any prefix should be routed.

This proposal raises a number of issues, as follows:

One interpretation of this proposal is that it is proposing that APNIC nominate a global unicast address block and inform IANA that this block is not allocated or assigned to any particular individual or entity, but should be regarded as fully allocated in terms of APNIC reporting to IANA on address allocation levels for subsequent address allocations to APNIC from the IANA pool. For IANA to recognise this allocation as part of APNIC's allocated address pool would appear to require a change in IANA's method of measuring allocated address space. In such a case the only way I can see within the framework of the current policies that this could be effected is via a Global Policy, rather than a regional policy for APNIC.

APNIC has no recognised mechanism to unilaterally declare a block of address space as non-routeable in the public Internet. That is a conventionally recognised role of the IANA to undertake, again leading to the observation that at the very least this should be a Global Policy for the IANA.

However, there is an additional observation that all such declarations of address space that are reserved for private use or special purposes have been made to date on the basis of standards action of the IETF and a published RFC with explicit instructions to IANA to amend its registries to reflect the intended reservation.

In response to your specific question the Ipv6 documentation prefix was listed by IANA ultimately in response to an IESG instruction to the IANA as part of the publication of RFC3849.

Accordingly, it is unclear that a Global Policy alone would be sufficient for the purpose of declaring additional private use address space, and it may be the case that IANA would require an IETF action as a precondition for such a registration.

regards,

Geoff (speaking for myself, of course!)

•          sig-policy:  APNIC SIG on resource management 
  

policy * _______________________________________________ sig-policy mailing list sig-policy@lists.apnic.net http://mailman.apnic.net/mailman/listinfo/sig-policy