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