[address-policy-wg] Discussion on Options for Revising the IPv6 PI Assignment Policy

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]