Re: [sig-policy] Revised prop-116-v003: Prohibit to transfer IPv4 addres
Thank you for your questions to prop-116.
2017-02-22 12:47 GMT+09:00 Guangliang Pan <gpan at apnic dot net>:
> Questions:
>
> Will M&A be subject to two year limitation as well?
No, M&A will be a special case and not be subject to two year limitation.
> If a member has not received a /22 delegation from the 103/8 block but
> received a /22 IPv4 transfer from the 103/8 block, can this member still
> qualify for a /22 delegation from the 103/8 from APNIC?
No, that member cannot get the address. I believe the 103/8 pool is for new
comers, who have no IPv4 address.
> If we allow transfers based on announced by different ASes, should we
> request them to return the resources if they announce by same AS after
> transfer?
It will be desirable, but keeping track that will be difficult. I think it is
reasonable to check that with their network plan.
> Some of the statements in Advantages/Disadvantages and Impact sessions
> appear to be outdated by the change to a two-year limit.
Thank you for pointing out. I'll check them.
Yours Sincerely,
---
Tomohiro Fujisaki
2017-02-22 12:47 GMT+09:00 Guangliang Pan <gpan at apnic dot net>:
> Dear Tomohiro,
>
>
>
> Thanks for reviewing your policy proposal prop-116. I have some questions
> would like to have your clarifications.
>
>
>
> 4. Proposed policy solution
>
> ---------------------------
>
>
>
> 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.
>
>
>
> Questions:
>
> Will M&A be subject to two year limitation as well?
> If a member has not received a /22 delegation from the 103/8 block but
> received a /22 IPv4 transfer from the 103/8 block, can this member still
> qualify for a /22 delegation from the 103/8 from APNIC?
> If we allow transfers based on announced by different ASes, should we
> request them to return the resources if they announce by same AS after
> transfer?
>
>
>
> Some of the statements in Advantages/Disadvantages and Impact sessions
> appear to be outdated by the change to a two-year limit.
>
>
>
> Best regards,
>
>
>
> Guangliang Pan (Benny)
>
> Registration Services Manager, APNIC
>
> Email: gpan at apnic dot net
>
> SIP: gpan at voip dot apnic dot net
>
> Phone: +61 7 3858 3188
>
> http://www.apnic.net
>
> -----------------------------------------------------------------------------
>
> * You can now call APNIC Helpdesk for free using Skype. For more information
>
> visit: www.apnic.net/helpdesk
>
>
>
>
>
>
>
>
>
> 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: Sunday, 29 January 2017 9:39 PM
> 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
> -------------
>
>
> * sig-policy: APNIC SIG on resource management policy
> *
> _______________________________________________
> sig-policy mailing list
> sig-policy at lists dot apnic dot net
> https://mailman.apnic.net/mailman/listinfo/sig-policy