Hi all, As I’ve already indicated this morning, a few days ago I already worked a draft for resolving those issues. I commented it in the IETF v6ops list when somebody raised the problem there.
A bit of history. This is not new. The problem was clear when we had the RFC8273 and for this reason, I objected to the previous assignment definition change, and not being acknowledge, I proposed the policy 2018-02 (https://www.ripe.net/community/policies/proposals/2018-02/). So refreshing that now will be in the line of: Summary: This proposal aims to clarify the definition of "Assign" in RIPE-738 (section 2.6). The proposal solves the inconsistencies raised during community discussions on the policy proposal 2016-04, “IPv6 Sub-Assignment Clarification” where the RIPE NCC’s understanding, as explained in the impact analysis, didn’t match with the current policy text. The policy text says “Providing another entity with separate addresses (not prefixes)”, while the impact analysis said “as long as the subnet size does not exceed a /64”. In addition to cases where a /64 is used for a point-to-point link, VPNs and similar, where typically a single address is used on the “customer side” (in addition to the one used at the LIR side), the IETF has several ways to assign unique /64 prefix per interface/host (RFC 8273, RFC 9663) 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). Another case involves a third party contracted by the End User to provide services in their network that require the deployment of other devices, servers, network equipment, etc. For example, a security surveillance system may involve the contractor providing their own cameras, recording system, even their own firewall and/or router for a dedicated VPN. In many cases, this surveillance system would need to use the addressing space of the End User. We need to understand that the concept of BYOD (Bring Your Own Device), even in enterprise networks, universities, etc., doesn't limit the number of addresses that a single device may decide to use. In fact, previous standards already allow this because a single device can get an IPv6 address by means of SLAAC, another with DHCPv6, and one more using privacy addresses. The actual policy text will not allow this, while the RIPE NCC’s understanding seems to support it. Current Policy Text:2.6. Assign To “assign” means to delegate address space to an ISP or End User for specific use within the Internet infrastructure they operate. Assignments must only be made for specific purposes documented by specific organisations and are not to be sub-assigned to other parties. Providing another entity with separate addresses (not prefixes) from a subnet used on a link operated by the assignment holder is not considered a sub-assignment. This includes for example letting visitors connect to the assignment holder's network, connecting a server or appliance to an assignment holder's network and setting up point-to-point links with 3rd parties. New Policy text:2.6. Assign To “assign” means to delegate address space to an ISP or End User for specific use within the Internet infrastructure they operate. Assignments must only be made for specific purposes documented by specific organisations and are not to be sub-assigned to other parties. 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 and is prohibited under this policy. Rationale: a. Arguments Supporting the Proposal This proposal will avoid the above-mentioned discrepancies, align the policy with standards and simplify RIPE NCC clarifications and avoid misunderstandings. The proposal already continue prohibiting the use of PI for ISP services. b. Arguments Opposing the Proposal None foreseen beyond the impact analysis of 2016-04, which is still very relevant here. Inputs welcome! Also if anyone want to join the proposal, etc., etc, please let me know. Regards, Jordi @jordipalet ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.
----- To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/address-policy-wg.ripe.net/ As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at: https://www.ripe.net/membership/mail/mailman-3-migration/
