Re: [sig-policy] report on prop-058: Proposal to create IPv4 shared use

  • To: Geoff Huston <gih at apnic dot net>, sig-policy at lists dot apnic dot net
  • Subject: Re: [sig-policy] report on prop-058: Proposal to create IPv4 shared use address space among LIRs
  • From: David Woodgate <David.Woodgate at telstra dot net>
  • Date: Tue, 26 Feb 2008 11:06:52 +1100
  • Cc: Toshiyuki Hosaka <hosaka at nic dot ad dot jp>
  • Delivered-to: sig-policy at mailman dot apnic dot net
  • In-reply-to: <47BE17AB.4040605 at apnic dot net>
  • List-archive: <>
  • List-help: <>
  • List-id: APNIC SIG on resource management policy <>
  • List-post: <>
  • List-subscribe: <>, <>
  • List-unsubscribe: <>, <>
  • References: <>

    • 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 > 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.


                                                           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.


          Geoff (speaking for myself, of course!)

      *              sig-policy:  APNIC SIG on resource management policy           *
      sig-policy mailing list
      sig-policy at lists dot apnic dot net