Dear chairs

In my view there is no point in prohibiting transfer as a proxy to prohibiting 
’sales' because people will still carry out those sales and all that will 
happen is that they will not be registered correctly any more.

I also agree with Mike Henderson, with the current role/strategy for RIRs there 
is no need for any more changes to IPv4 policy.

regards
Jay

> On 30/01/2017, at 12:39 AM, Sumon Ahmed Sabir <[email protected]> wrote:
> 
> 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
>                 [email protected]
> 
> 
> 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
> -------------
> *              sig-policy:  APNIC SIG on resource management policy           
> *
> _______________________________________________
> sig-policy mailing list
> [email protected]
> https://mailman.apnic.net/mailman/listinfo/sig-policy


-- 
Jay Daley
Chief Executive
NZRS Ltd
desk: +64 4 931 6977
mobile: +64 21 678840
linkedin: www.linkedin.com/in/jaydaley

*              sig-policy:  APNIC SIG on resource management policy           *
_______________________________________________
sig-policy mailing list
[email protected]
https://mailman.apnic.net/mailman/listinfo/sig-policy

Reply via email to