Hello, To add some additional background data to this proposal, I’ll point out that ARIN recently adopted a proposal to solve the same problem statement. The language incorporated into the ARIN NRPM can be found here: https://www.arin.net/policy/proposals/2018_4.html <https://www.arin.net/policy/proposals/2018_4.html>
Thanks, -Chris > On Jan 9, 2019, at 8:28 PM, Bertrand Cherrier <b.cherr...@micrologic.nc> > wrote: > > Dear SIG members, > > We wish you all the best for this new year ! > > A new version of the proposal "prop-124: Clarification on IPv6 > Sub-Assignments" > has been sent to the Policy SIG for review. > > Information about earlier versions is available from: > > https://www.apnic.net/community/policy/proposals/prop-124 > <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-v005: Clarification on IPv6 Sub-Assignments > > Proposer: Jordi Palet Martínez > jordi.pa...@theipv6company.com <mailto:jordi.pa...@theipv6company.com> > 1. Problem Statement > > 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 because the usage of NAT. > > 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”. > > This proposal clarifies this situation in this regard and better define > the concept, particularly considering new uses of IPv6 (RFC8273), by means > of new text. > > It also clarifies that the usage of sub-assignments in ISPs, data centers > and similar cases is not allowed. > > 3. Situation in other regions > > This situation, has already been corrected in RIPE, and the policy was > updated in a similar way, even if right now there is a small discrepancy > between the policy text that reached consensus and the RIPE NCC Impact > Analysis. A new policy proposal has been submitted to amend that, and > the text is the same as presented by this proposal at APNIC. Same text > has also been submitted to AfriNIC (already reached consensus), LACNIC > and ARIN. > > 4. Proposed policy solution > > Add a new paragraph after the existing one in 2.2.3. > > Actual 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 address space assignment is only for use by the original holder of said > assignment, as well as for third party devices, as long as they are > operating > within the original holder infrastructure. > > Sub-assignments are not allowed outside that infrastructure (for example > using > sub-assignments for ISP customers), neither for providing addressing > space to > third parties in data-centers (or similar cases). > > 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
