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] -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/address-policy-wg
