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]