Dear Colleagues, at RIPE87 in Rome we discussed several pathways forward for the IPv6 address policy in the NCC region. I suggested to take a look at the IPv6 PI policy. Over the past months I have been collecting perspectives and ideas which I aggregated to a suggested set of changes which I would like to start discussing on the ML prior to RIPE88, to see whether these directions work for the community, and how to improve them. Please note that this is not a formal proposal, but a work-in-progress as a basis for further discussion. I am tracking the development of the text in git; Additionally, I also attached the corresponding files. Individual suggestions can be found here; Each .patch contains more detailed reasoning along with the proposed change. https://git.as59645.net/tfiebig/ripe-738-pi-update/src/branch/draft-04/indiv... And the overall diff here: https://git.as59645.net/tfiebig/ripe-738-pi-update/src/branch/draft-04/draft... # The core changes proposed are: ## Section 2.6 - Clarify that a PI assignment holder may host another entities' server in their assignment, also providing them with a /64-/56 - Allow (for servers) static address configuration - Explicitly prohibit use of PI space for subscriber services, while still allowing uses like, e.g., Freifunk ## Section 2.9 - Define meaning of 'End Site' for PA and PI individually to better distinguish between the nuances of the two - Make sure that an L2 link (e.g., direct fibre/wave, packet- switched vlan etc.) does not merge end sites. - Allow announcing more specifics from end sites when the set of end sites received a covering prefix ## Section 5.4. - Make it explicit that this section is about assignments made from an LIR's allocation - Made wording more precise ## Section 7.1 - Clarify for what PI assignments are made (end users using the assignment in their infrastructure, without making sub- assignments) - Clarified that PI assignments have a prefix length of /48 or shorter. - Introduced that PI assignments to one end user should be aggregatable to prevent address space fragmentation ## (NEW) Section 7.1.1 - Introduce PI assignments being made at the nibble boundary; This is to make extendability/reservations/planning easier, i.e., limiting renumbering needs for PI holders if they require more address space. Furthermore, it also allows testing the implications such a move would have on the larger scope of PA. - Ensures that assignments are atomic, i.e., cannot be further split to prevent fragmentation ## (NEW) Section 7.1.2 - Describe that PI assignment holders need to request an extension of their assignment if they need more address space, instead of requesting a new assignment. ## (NEW) Section 7.1.3 - Describe how PI assignments assigned prior to the policy change should be handled. Essentially: - When more space is needed, the assignment holder receives one (new) prefix for their whole addressing need - All other assignments must be returned after a renumbering period - The renumbering period can be extended by providing documentation that renumbering is not feasible. The idea here is that this places resources in a state which does not force assignment holders to immediately perform a (potentially unreasonably costly) renumbering. However, if the space is (eventually) freed it will have to be returned. # Together, these changes should accomplish: - Easier accessibility of PI for small organizations that do not provide address space to third parties, while allowing better aggregation when such an organization would, under the current policy, require multiple assignments - More streamlined / easier to assess assignment procedures - Reducing fragmentation of PI, while also reducing previously accumulated address space fragmentation - Clarification concerning common issues of PI, e.g., a dual-homed end user who wants to co-locate a server for a friend, while providing a static address that is >=/64, i.e., follows IPv6 addressing best practices. - Allowing the use of a /64 per device in, e.g., an organization's WiFi - Making it more explicit that uses that are commonly associated with an IP making assignments from their allocation are not permitted with PI I am looking forward to receiving feedback on the direction, and always appreciate suggestions to change formulations and improve upon the current version to move towards a document that can reach consensus. With best regards, Tobias -- Dr.-Ing. Tobias Fiebig T +31 616 80 98 99 M tobias@fiebig.nl