Re: [sig-policy] Revised prop-116-v003: Prohibit to transfer IPv4 addres

    • To: "sig-policy at apnic dot net" <sig-policy at apnic dot net>
    • Subject: Re: [sig-policy] Revised prop-116-v003: Prohibit to transfer IPv4 addresses in the final /8 block [SECURITY=UNCLASSIFIED]
    • From: "HENDERSON MIKE, MR" <MICHAEL.HENDERSON@NZDF.mil.nz>
    • Date: Sun, 29 Jan 2017 21:08:29 +0000
    • Accept-language: en-NZ, en-US
    • 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: <https://mailman.apnic.net/mailman/listinfo/sig-policy>, <mailto:sig-policy-request@lists.apnic.net?subject=subscribe>
    • List-unsubscribe: <https://mailman.apnic.net/mailman/options/sig-policy>, <mailto:sig-policy-request@lists.apnic.net?subject=unsubscribe>
    • Thread-index: AdJ6c9acNSvGPNqvSfKomZ/tZAGJhA==
      • Folks,

         

        I have said it before, and I’m afraid I will have to say it again after this, but

        I do not support any further changes to IPv4 policy.

         

        So far as I am concerned, this patient should have “Do Not Resuscitate” marked in big letters on its record card, and probably tattooed across its chest too

         

        The worse the “IPv4 Problem” gets, the more pressure to roll out IPv6 and to address the practical issues with really big scale IPv6 deployments.

         

         

        Regards

         

         

        Mike

         

        From: sig-policy-bounces at lists dot apnic dot net [mailto:sig-policy-bounces at lists dot apnic dot net] On Behalf Of Sumon Ahmed Sabir
        Sent: Monday, 30 January 2017 12:39 a.m.
        To: sig-policy at apnic dot net
        Subject: [sig-policy] Revised prop-116-v003: Prohibit to transfer IPv4 addresses in the final /8 block

         

        Dear SIG members

        A new version of the proposal "prop-116: Prohibit to transfer IPv4
        addresses in the final /8 block" has been sent to the Policy SIG for
        review.

        Information about earlier versions is available from:

        http://www.apnic.net/policy/proposals/prop-116

        You are encouraged to express your views on the proposal:

          - Do you support or oppose the proposal?
          - Is there anything in the proposal that is not clear?
          - What changes could be made to this proposal to make it more effective?

        Please find the text of the proposal below.

        Kind Regards,

        Masato and Sumon






        -------------------------------------------------------

        prop-116-v003: Prohibit to transfer IPv4 addresses in the final /8 block

        -------------------------------------------------------

        Proposer:       Tomohiro Fujisaki
                        
        fujisaki at syce dot net


        1. Problem statement
        --------------------

        There are a lot of transfers of IPv4 address blocks from 103/8
        happening, both within the APNIC region and among RIRs.

        Then number of transfer from 103/8 block are about 200, which is
        about 12% of the total number of transfers. This looks so high
        since APNIC manages about 40/8.

        And based on the information provided by APNIC secretariat, number
        of transfers from the 103/8 block are increasing year by year.

        Updated by APNIC Secretariat on 27 January 2017:

        1) M&A transfers containing 103/8 space

        +------+-----------+-----------+-
        |      |   Total   | Number of |
        | Year | Transfers |   /24s    |
        +------+-----------+-----------+-
        | 2011 |         3 |         12 |
        | 2012 |        10 |         46 |
        | 2013 |        18 |         66 |
        | 2014 |       126 |        498 |
        | 2015 |       147 |        573 |
        | 2016 |        63 |        239 |
        +------+-----------+------------+-

        2) Market transfers containing 103/8 space

        +------+-----------+-----------+
        |      |   Total   | Number of |
        | Year | Transfers |   /24s    |
        +------+-----------+-----------+
        | 2011 |         2 |         2 |
        | 2012 |        21 |        68 |
        | 2013 |        16 |        61 |
        | 2014 |        25 |        95 |
        | 2015 |        67 |       266 |
        | 2016 |       103 |       394 |
        +------+-----------+-----------+

        And also, transfers from the 103/8 block include:
          - Take place within 1 year of distribution, or
          - Multiple blocks to a single organization in case of beyond 1 year.

        Further, there is a case where a single organization have received 12
        blocks transfers from 103 range.

        see:  
        https://www.apnic.net/transfer-resources/transfer-logs

        From these figures, it is quite likely that substantial number of 103/8
        blocks are being used for transfer purpose.

        This conflicts with the concept of distribution of 103/8 block
        (prop-062), which is intended to accommodate minimum IPv4 address blocks
        for new comers.

        °°prop-062: Use of final /8
        °°
        https://www.apnic.net/policy/proposals/prop-062


        2. Objective of policy change
        -----------------------------

        When stated problem is solved, distribution from 103/8 block will be
        consistent with its original purpose, for distribution for new entrants
        to the industry. Without the policy change, substantial portion of 103/8
        blocks will be consumed for transfer purpose.


        3. Situation in other regions
        -----------------------------

        None.


        4. Proposed policy solution
        ---------------------------

        Prohibit transfer IPv4 addresses under /8 address block (103/8) which
        have not passed two years after its allocation/assignment.
        If the address block allocated to a LIR in two years is not needed any
        more, it must return to APNIC to allocate to another organization
        using final /8 policy.

        In the case of transfers due to M&A, merged organization can have
        up to /22 IPv4 address in the 103/8 block in principle. If there
        are technical reasons such as all address is used in separate networks
        and announced from multiple ASes, merged organization can keep them.
        Otherwise, the 103/8 IPv4 address more than /22 must return to APNIC
        to allocate to another organization using final /8 policy.


        5. Advantages / Disadvantages
        -----------------------------

        Advantages:
          - It makes 103/8 blocks available according to the original purpose,
            as distribution for new entrants (rather than being consumed for
            transfer purpose)

          - IPv4 addresses under final /8 are not transferred to outside APNIC.

          - By prohibiting transfer them, it is possible to keep one /22 for
            each LIRs state, which is fair for all LIRs.

        Disadvantages:

        None.


        6. Impact on resource holders
        ------------------------------

          - LIRs cannot transfer address blocks under 103/8. No big impact while
            they use it.

          - Organizations which needs to receive transferred IPv4 can continue
            to do so, outside 103/8 blocks (which should be made available for
            new entrants)


        7. References
        -------------

        The information contained in this Internet Email message is intended for the addressee only and may contain privileged information, but not necessarily the official views or opinions of the New Zealand Defence Force.  If you are not the intended recipient you must not use, disclose, copy or
        distribute this message or the information in it.  If you have received this message in error, please Email or telephone the sender immediately.