*Dear Colleagues,I am Satoru Tsurumaki from Japan Open Policy Forum.I would like to share key feedback in our community for prop-124,based on a meeting we organised on 22nd Aug to discuss these proposals.Many supporting opinions were expressed on this proposal.However, also many concerning comment was expressed to explain the specific examples.For this matter, the same opinion was given also at JPOPM34. - It is better to stop specific examples because they tend to fall into discussion of adding / not applying / not applicable. - I think that specific examples should be stated in the guidelines rather than policies.* Regards, Satoru Tsurumaki
2018-09-09 18:37 GMT+11:00 Bertrand Cherrier <b.cherr...@micrologic.nc>: > Dear SIG members > > 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 > > 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-v004: Clarification on IPv6 Sub-Assignments > ------------------------------ > > Proposer: Jordi Palet Martínez > 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 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, > 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”. > > https://www.apnic.net/community/policy/resources#2.2.3.- > Assigned-address-space > > This proposal clarifies this situation in this regard and better define the > concept, particularly considering new uses of IPv6 (RFC 8273), by means of > a new paragraph. > 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, LACNIC and ARIN. > 4. Proposed policy solution > > Add a new paragraph after the existing one in 2.2.3 > https://www.apnic.net/community/policy/resources#2.2.3.- > Assigned-address-space > > 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 specific use within the Internet infrastructure they operate. > Assignments must > only be made for specific, documented purposes and may not be sub-assigned. > > Providing addressing space to third party devices including addresses for > point-to-point links and/or non-permanently providing addressing space to > third > parties, for use on a network managed and operated by the assignment > holder, > shall not be considered a sub-assignment. > > The provision of addressing space for permanent or semi-permanent > connectivity, > such as broadband services, is still considered a sub-assignment. > 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. > > Cordialement, > ------------------------------ > > Bertrand Cherrier > Administration Systèmes - R&D > Micro Logic Systems > b.cherr...@micrologic.nc > https://www.mls.nc > Tél : +687 24 99 24 > VoIP : 65 24 99 24 > SAV : +687 36 67 76 (58F/min) > ------------------------------ > > * 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
