[sig-policy] prop-104-v001: Clarifying demonstrated needs requirement in

  • To: SIG policy <sig-policy at apnic dot net>
  • Subject: [sig-policy] prop-104-v001: Clarifying demonstrated needs requirement in IPv4 transfer policy
  • From: Andy Linton <asjl at lpnz dot org>
  • Date: Sun, 29 Jul 2012 18:27:45 -0700
  • Delivered-to: sig-policy at mailman dot apnic dot net
  • List-archive: <http://mailman.apnic.net/mailing-lists/sig-policy>
  • List-help: <mailto:sig-policy-request@lists.apnic.net?subject=help>
  • List-id: APNIC SIG on resource management policy <sig-policy.lists.apnic.net>
  • List-post: <mailto:sig-policy@lists.apnic.net>
  • List-subscribe: <http://mailman.apnic.net/mailman/listinfo/sig-policy>, <mailto:sig-policy-request@lists.apnic.net?subject=subscribe>
  • List-unsubscribe: <http://mailman.apnic.net/mailman/listinfo/sig-policy>, <mailto:sig-policy-request@lists.apnic.net?subject=unsubscribe>
      The proposal "prop-104-v001: Clarifying demonstrated needs requirement
      in IPv4 transfer policy' has been sent to the Policy SIG for review.
      It will be discussed at the Policy SIG at APNIC 34 in Phnom Penh,
      Cambodia, Thursday, 30 August 2012.
      We invite you to review and comment on the proposal on the mailing list
      before the meeting.
      The comment period on the mailing list before an APNIC meeting is an
      important part of the policy development process. We encourage you to
      express your views on the proposal:
                - Do you support or oppose this proposal?
                - Does this proposal solve a problem you are experiencing? If
                  so, tell the community about your situation.
                - Do you see any disadvantages in this proposal?
                - Is there anything in the proposal that is not clear?
                - What changes could be made to this proposal to make it more
      Information about this proposal is available from:
      Andy, Skeeve, Masato
      prop-104-v001: Clarifying demonstrated needs requirement in IPv4
                      transfer policy
      Authors: Shin SHIRAHATA
                <shin at clara dot ad dot jp>
                Norisuke HIRAI
                Akira NAKAGAWA
      1.  Introduction
      This proposal defines the period to be approved of IPv4 transfers for
      recipients under demonstrated needs, in addition to current IPv4 address
      policy for allocation/assignment from APNIC.
      2.  Summary of the current problem
      The current APNIC transfer policy has a requirement for demonstrate a
      need for transferred IPv4 addresses. The period of demonstrated needs
      under the current operational practice is 12 months based on the
      definition in Section 3.2, "Criteria for subsequent LIR delegations" in
      the "Policies for IPv4 address space management in the Asia Pacific
      "Based on these factors, APNIC and NIRs will delegate address space to
      meet the LIR's estimated needs for a period up to one year up to the
      maximum allowed delegation under Section 3."
      and this period was defined before the exhaustion.
      On the other hand, ARIN allows transfers based on demonstrated needs up
      to 24 months. This leads to difference in conditions of the transfer
      between LIRs in the APNIC region and the ARIN region.
      Furthermore, 12 months is also too short for transfers within the APNIC
      region considering many xSPs plan their service and their addressing
      requirements beyond one year.
      3.  Situation in other RIRs
      ARIN has a requirement for the period to be approved of IPv4 transfers
      for recipients under demonstrated needs, up to 24 months. LACNIC has a
      policy that defines to evaluate for 12 months needs. RIPE NCC has 3
      months requirement at this time, and the policy proposal that extend to
      24 months, is under discussion.
      AfriNIC currently does not have an IPv4 address transfers policy.
      ARIN policy has a clear period for justification for IPv4 address
      transfers, and the period is 24 months.
      "Such transferred number resources may only be received under RSA by
      organizations that are within the ARIN region and can demonstrate the
      need for such resources in the amount which they can justify under
      current ARIN policies showing how the addresses will be utilized within
      24 months."
      See Section 8.3, "Transfers to Specified Recipients" in the "ARIN Number
      Resource Policy Manual":
      This change was proposed by "DRAFT POLICY ARIN-2012-1: CLARIFYING
      LACNIC policy defines to evaluate for 12 months needs for the recipient
      of the IPv4 address transfer. However, the transfer will only be
      activate once LACNIC's address pool runs out. (expect for the reserved
      See Section, "Submission of Assignment Information" and Section, "Transfer of IPv4 Blocks within the LACNIC Region" in the
      LACNIC Policy Manual (v1.9):
      In the RIPE region, the period of needs approved for IPv4 address
      transfers will be based on the definition of the current allocation
      policy, which is 3 months.
      Currently, there is no policy which defines the period of needs based
      justification, specifically for IPv4 transfers, separate from allocation
      criteria. See Section 5.0, "Policies and Guidelines for Allocations" in
      the RIPE-553, "IPv4 Address Allocation and Assignment Policies for the
      RIPE NCC Service Region:"
      However, there is a policy proposal under discussions which proposes to
      extend the period of the demonstrated needs in case of IPv4 transfers,
      up to 24 months. See 2012-03, "Intra-RIR Transfer Policy Proposal".
      4.  Details
      This proposal clarifies the requirement on a period approved for the
      transferred resource to recipients of IPv4 transfers based on the
      demonstrated needs, and defines its period as "24 months".
      In case of Inter-RIR transfer, when there is a RIR which defines a
      period longer than 24 months in the future, the longer period adopted by
      the other RIR will be adopted.
      This proposal does not intend to change the requirement for an address
      allocation or assignment.
      5.  Pros/Cons
           - Extended period will allow the larger block size to match a longer
             term needs of the requester. It will help to reduce an IPv4
             address block fragmentation caused by transfer.
           - APNIC member can apply for IPv4 address transfer as a receiver on
             the same condition of demonstrate a need in other RIR in case of
             Inter-RIR transfer. At this time, ARIN is the only RIR that adopts
             Inter-RIR policy in place other than APNIC. Thus, it places APNIC
             policy in line with ARIN on the transfer conditions.
           - It will allow the block size to more closely match the block size
             available for transfer from source
           - It will reduce the risk of underground IPv4 address transfers,
             which do not get registered in APNIC database. There is a
             possibility that the recipients could not obtain justification for
             enough IPv4 address by the current period of demonstrated needs.
           - None
             There may be people who feel 24 months does not lead to efficient
             utilization compared to 12 months.
             However, the objective of needs based justification is not to "cut
             the size of address space to be transfered"; it is to ensure that
             the transfered space will be utilized in realities. 24 months is a
             realistic period to estimate required address space for xSPs.
      6.  Effect on APNIC Members
      It will requires a recipients within the APNIC region must demonstrate
      the need for up to a 24 months use of IPv4 address block.
      If there is a RIR which defines a period longer than 24 months, the
      recipients may use the longer period to demonstrate its demand for an
      Inter-RIR transfer from that RIR.
      7.  Effect on NIRs
      It is the NIR's choice as to whether to adopt this policy.