Discussion on Options for Revising the IPv6 PI Assignment Policy
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
Hi, inline... On 19. 4. 24 15:41, Tobias Fiebig wrote:
## 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
^^^^ This are the most needed changes that we need to make...
## 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.
You can't verify that, can you? An IPRA can't verify that...
## 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.
This was already written in there, but apparently slightly misinterpreted by IPRAs :) Good to clarify that /48 or /47 or shorter is fine, /49 is not ok...
- Introduced that PI assignments to one end user should be aggregatable to prevent address space fragmentation
For new assignments, yes.
## (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.
I like this :) /48 -> /44 -> /40 -> etc...
- 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.
Makes sense, specially if the proper reservation policy is in place.
## (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.
I like that... this means that if you really can't renumber or that would mean severe interruptions in operations or any other compelling reason - then you are not forced to. However, better provide a good reason and a story backing it up to the IPRA ;)
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 like the above goals. This needs to be done as I received numerous complaints about exactly what we are trying to fix here. Cheers, Jan -- Anything that can be configured can be misconfigured. [RFC5505]
Moin,
## 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.
You can't verify that, can you? An IPRA can't verify that...
The problem is that, at the moment, mentioning that you do have any form of L2 link between sites will lead to those being just one end site. So, for example: You apply for PI for your rack in Country A and your rack in Country B, both multi-homed and 100-1000KM apart from each other. However, you also have a wave between them and put a QDD-400G-ZRP-S into your routers at each site and plug in the cables bringing in your wave; Now, technically, there is an L2 link between those two sites (replace the wave with any form of, e.g., packet-switched L2 transport as well; I acknowledge that the average End User will not spend EUR20k+ on transceivers for their two racks). If you note this in a PI application for two assignments of /48, this will now become one End Site, only qualifying for one /48, unless supported by addressing needs. Indeed, it is impossible for an IPRA to verify that, so you could just "not mention that detail". However, the intention of the change set is also to reduce points where people might feel the need to 'not be exactly accurate in their requests'. ;-)
I like the above goals. This needs to be done as I received numerous complaints about exactly what we are trying to fix here.
Thanks. Good to hear that this goes into a reasonable direction. With best regards, Tobias -- Dr.-Ing. Tobias Fiebig T +31 616 80 98 99 M tobias@fiebig.nl
Le Fri, Apr 19, 2024 at 03:41:03PM +0200, Tobias Fiebig via address-policy-wg a écrit :
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:
Reads reasonable. -- Denis Fondras / Liopen
participants (3)
-
Denis Fondras - Liopen -
Jan Zorz - Go6 -
Tobias Fiebig