Dear Colleagues,

I am Satoru Tsurumaki from Japan Open Policy Forum Steering Team.
I would like to share a feedback in our community for prop-124,based
on a meeting we organized on 21th Aug to discuss these proposals.

Many participants expressed a neutral for the proposal with reasons
that the problem in the current policy is something vague.

Best Regards,

Satoru Tsurumaki
JPOPF-ST

2019年8月10日(土) 23:33 Sumon Ahmed Sabir <sasa...@gmail.com>:

>
> Dear SIG members
>
> A new version of the proposal "prop-124: Clarification on Sub-Assignments"
> has been sent to the Policy SIG for review.
>
> It will be presented at the Open Policy Meeting at APNIC 48 in
> Chiang Mai, Thailand on Thursday, 12 September 2019.
>
> Information about earlier versions is available from:
> https://www.apnic.net/community/policy/proposals/prop-124
>
> 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,
>
> Sumon, Bertrand, Ching-Heng
> APNIC Policy SIG Chairs
>
>
> ----------------------------------------------------------------------
>
> prop-124-v006: Clarification on Sub-Assignments
>
> ----------------------------------------------------------------------
>
> Proposer: Jordi Palet Martínez
>            jordi.pa...@theipv6company.com
>
>
> 1. Problem Statement
> --------------------
>
> Note that this proposal is ONLY relevant when end-users obtain direct
> assignments
> from APNIC, or when a LIR obtains, also from APNIC, and assignment for
> exclusive
> use within its infrastructure. Consequently this is NOT relevant in case
> of LIR
> allocations.
>
> When the policy was drafted, the concept of assignments/sub-assignments
> did not
> consider a practice very common in IPv4 which is replicated and even
> amplified
> in IPv6: the use of IP addresses for point-to-point links or VPNs.
>
> In IPv4, typically, this is not a problem if NAT is being used, because
> the assigned
> addresses are only for the WAN link, which is part of the infrastructure
> or interconnection.
>
> In the case of IPv6, instead of unique addresses, the use of unique
> prefixes
> (/64) is increasingly common.
>
> Likewise, the policy failed to consider the use of IP addresses in
> hotspots hotspots
> (when is not an ISP, for example, associations or community networks),
> or the use of
> IP addresses by guests or employees in Bring Your Own Device (BYOD) and
> many other
> similar cases.
>
> One more case is when an end-user contracts a third-party to do some
> services in their
> own network and they need to deploy their own devices, even servers,
> network equipment,
> etc. For example, security surveillance services may require that the
> contractor provides
> their own cameras, recording system, even their own firewall and/or
> router for a dedicated
> VPN, etc. Of course, in many cases, this surveillance system may need to
> use the addressing
> space of the end-user.
>
> Finally, the IETF has recently approved the use of a unique /64 prefix
> per interface/host
> (RFC8273) instead of a unique address. This, for example, allows users
> to connect to a hotspot,
> receive a /64 such that they are “isolated” from other users (for
> reasons of security,
> regulatory requirements, etc.) and they can also use multiple virtual
> machines on their
> devices with a unique address for each one (within the same /64).
>
>
> 2. Objective of policy change
> -----------------------------
>
> Section 2.2.3. (Definitions/Assigned Address Space), explicitly
> prohibits such assignments,
> stating that “Assigned ... may not be sub-assigned”.
>
> It also clarifies that the usage of sub-assignments in ISPs, data
> centers and similar cases
> is not allowed, according to the existing practices of APNIC.
>
>
> 3. Situation in other regions
> -----------------------------
>
> This situation, has already been corrected in AFRINIC, ARIN, LACNIC and
> RIPE.
>
>
> 4. Proposed policy solution
> ---------------------------
>
> Current Text
> 2.2.3. Assigned address space
> Assigned address space is address space that is delegated to an LIR, or
> end-user,
> for specific use within the Internet infrastructure they operate.
> Assignments must
> only be made for specific, documented purposes and may not be sub-assigned.
>
>
> New text:
> 2.2.3. Assigned address space
> Assigned address space is address space that is delegated to an LIR, or
> end-user,
> for exclusive use within the infrastructure they operate, as well as for
> interconnection
> purposes.
>
> The assigned address space must only be used by the original recipient
> of the assignment,
> as well as for third party devices provided they are operating within
> said infrastructure.
>
> Therefore, sub-assignments to third parties outside said infrastructure
> (for example
> using sub-assignments for ISP customers), and providing addressing space
> to third
> parties in data-centers (or similar cases), are not allowed.
>
>
> 5. Advantages / Disadvantages
> -----------------------------
>
> Advantages:
> Fulfilling the objective above indicated and making sure to match the
> real situation
> in the market.
>
>
> Disadvantages:
> None foreseen.
>
>
> 6. Impact on resource holders
> -----------------------------
> None.
>
> 7. References
> -------------
> Links to RIPE policy amended and new policy proposal submitted.
>
> *              sig-policy:  APNIC SIG on resource management policy           
> *
> _______________________________________________
> sig-policy mailing list
> sig-policy@lists.apnic.net
> https://mailman.apnic.net/mailman/listinfo/sig-policy
*              sig-policy:  APNIC SIG on resource management policy           *
_______________________________________________
sig-policy mailing list
sig-policy@lists.apnic.net
https://mailman.apnic.net/mailman/listinfo/sig-policy

Reply via email to