[address-policy-wg] 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/individual_changes

And the overall diff here:

https://git.as59645.net/tfiebig/ripe-738-pi-update/src/branch/draft-04/draft_changes/initial_version-to-draft-04

# 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 at fiebig.nl

-------------- next part --------------
A non-text attachment was scrubbed...
Name: draft-04-2_6.patch
Type: text/x-patch
Size: 5562 bytes
Desc: not available
URL: </ripe/mail/archives/address-policy-wg/attachments/20240419/8243fbc6/attachment-0008.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: draft-04-2_9.patch
Type: text/x-patch
Size: 3326 bytes
Desc: not available
URL: </ripe/mail/archives/address-policy-wg/attachments/20240419/8243fbc6/attachment-0009.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: draft-04-5_4_2.patch
Type: text/x-patch
Size: 2996 bytes
Desc: not available
URL: </ripe/mail/archives/address-policy-wg/attachments/20240419/8243fbc6/attachment-0010.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: draft-04-7_1.patch
Type: text/x-patch
Size: 3266 bytes
Desc: not available
URL: </ripe/mail/archives/address-policy-wg/attachments/20240419/8243fbc6/attachment-0011.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: draft-04-7_1_1.patch
Type: text/x-patch
Size: 3453 bytes
Desc: not available
URL: </ripe/mail/archives/address-policy-wg/attachments/20240419/8243fbc6/attachment-0012.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: draft-04-7_1_2.patch
Type: text/x-patch
Size: 2803 bytes
Desc: not available
URL: </ripe/mail/archives/address-policy-wg/attachments/20240419/8243fbc6/attachment-0013.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: draft-04-7_1_3.patch
Type: text/x-patch
Size: 4953 bytes
Desc: not available
URL: </ripe/mail/archives/address-policy-wg/attachments/20240419/8243fbc6/attachment-0014.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: initial_version-to-draft-04
Type: text/x-patch
Size: 11295 bytes
Desc: not available
URL: </ripe/mail/archives/address-policy-wg/attachments/20240419/8243fbc6/attachment-0015.bin>