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 [email protected]
commit 89fd996f285f1a72902fc96455723098b455b984 Author: Tobias Fiebig <[email protected]> Date: Fri Apr 19 13:20:58 2024 +0200 Adjusted the notion on sub assignments to allow for prefix delegation as common in IPv6 addressing. Purpose: - Clarify that even assignment holders may, for example, host a customers' server or VM in their network, providing more than a single IPv6 address as common for IPv6 (at least /64). - Explicitly also allows static prefixes for, e.g., servers - Codify that the customer's server or device must be at the assignment holder's end-site and part of their network - This removed the implicit need for addresses used for interconnectivity to be on a shared prefix, i.e., the shared link can be numbered with LL addresses and a /128 (or /64) routed to the LL of the connected server's interface. - This more clearly spells out the delegation of prefixes used in Internet infrastructure, i.e., routable prefixes, already implied in the previous version of the policy. - Explicitly prohibits use of PI for connecting remote end-sites of customers to the Internet, except for p2p links to other ISPs Considerations: - There may be a fear that this leads ISPs to leverage PI to connect residential customers, or to create a hosting business. However, this provision is already hard to control (and even harder to police), making it unlikely that this risk materializes beyond the scale it already has. Furthermore, assignment sizes remain limited by the provisions of "7. IPv6 Provider Independent (PI) Assignments", further reducing this risk. - The use of PI for servers was explicitly listed as an intended use for the last revision of this policy, while the interpretation did not allow for this. - Given best practices, /64 is often considered a reasonable prefix size used for end-devices. - Using PI for connecting access customers is now explicitly prohibited. Changes to darft-00: - Jan noted that the previously suggested wording of 2.6 might imply that one organization may only use an assigned prefix as one, and recommended to explicitly clarify that. A corresponding sentence has been added. Changes to draft-01: - Reduced permissible prefix size to a /56 - Removed reference to 2.9 based on feedback from the NCC, instead used phrasing around infrastructure - Made explicit which connections to other networks can and cannot be addressed with PI, explicitly considering connecting users outside the DFZ to the Internet as a sub-assignment. - Allowed up to /64 for point-to-point links to allow for common addressing plans. Changes to draft-02: - Clarified text (editorial) - Fixed reference to /128 in third paragraph, which previously wrongly mentioned '/128 or longer'. Changes to draft-03: - Further clarified notion of 'customer end-site' - Removed 'non routable' to quantify /56, as this might be misunderstood as 'non GUA'. diff --git a/ripe-738.txt b/ripe-738.txt index 98986c3..9a87f42 100644 --- a/ripe-738.txt +++ b/ripe-738.txt @@ -112,9 +112,14 @@ To “allocate” means to distribute address space to IRs for the purpose of su 2.6. Assign -To “assign” means to delegate address space to an ISP or End User for specific use within the Internet infrastructure they operate. Assignments must only be made for specific purposes documented by specific organisations and are not to be sub-assigned to other parties. +To “assign” means to delegate address space to an ISP or End User for specific use within the Internet infrastructure that ISP or End User operates. Assignments must only be made for specific purposes documented by specific organisations, and an assignment holder is not allowed to create further sub-assignments to another entity from address space partially or fully covering an assignment. -Providing another entity with separate addresses (not prefixes) from a subnet used on a link operated by the assignment holder is not considered a sub-assignment. This includes for example letting visitors connect to the assignment holder's network, connecting a server or appliance to an assignment holder's network and setting up point-to-point links with 3rd parties. +Providing another entity inside the assignment holder's network and located at the same geographical end-site with prefix sizes of /56 or longer, e.g., for letting visitors connect to the assignment holder's network, providing static addresses when connecting a server or appliance to an assignment holder's network, or providing a single service with multiple addresses is not considered a sub-assignment. + +Similarly, using a /64 or longer when setting up point-to-point links with other ISPs for the purpose of exchanging traffic and Internet routing information does not constitute a sub-assignment. +Any other use of a prefix from an assignment up to prefixes of /128 bit, i.e., up to single addresses, to connect an end-site of another entity to the Internet, always constitutes a prohibited sub-assignment. + +Finally, using more specific prefixes from a less-specific assignment for different parts of the same infrastructure within one organziation does not constitute a sub-assignment, if the purpose of the assignment is the operation of that infrastructure. 2.7. Utilisation
commit d03e7806367705ee943d7f73eabc745556b8fb36 Author: Tobias Fiebig <[email protected]> Date: Fri Apr 19 13:26:45 2024 +0200 Added specific end-site difinition for PI Purpose: - Define the meaning of End Site via specific routing policies expressed by how prefixes are propagated in the GRT. - Clarify that an L2 connection between two sites does not make them one site as long as seperate routing policies exist. - Clarify that announcing aggregates or prepended prefixes from other End Sites does not merge routing policies. Changes to draft-00: - Fixed grammar error and made wording for operating systems in a location, now requirering Internet connectivity. Changes to draft-01: - Used more high-level language to describe different routing policies - Clarified that End Sites must be topologically located in the RIPE NCC Service Region Changes to draft-02: - None Changes to draft-03: - Made it explicit that placing a single device at another geographical location (CPE) with the main purpose of providing a single End User with Internet access does not make that location an End Site of an assignment holder. diff --git a/ripe-738.txt b/ripe-738.txt index 98986c3..22a7e38 100644 --- a/ripe-738.txt +++ b/ripe-738.txt @@ -133,12 +133,18 @@ where (in the case of this document) the objects are IPv6 site addresses assigne 2.9. End Site -An End Site is defined as the location of an End User (subscriber) who has a business or legal relationship (same or associated entities) with a service provider that involves: +An End Site for assignments from a provider's allocation is defined as the topological location of an End User (subscriber) in the RIPE NCC Service Region who has a business or legal relationship (same or associated entities) with a service provider that involves: *that service provider assigning address space to the End User location *that service provider providing transit service for the End User location to other sites *that service provider carrying the End User's location traffic *that service provider advertising an aggregate prefix route that contains the End User's location assignment +An End Site for provider independent assignments (PI) directly to an End User from the RIPE NCC via a sponsoring LIR or directly to an LIR is defined as any topological location in the RIPE NCC Service Region where the End User deploys Internet connected devices, which has a different routing policy than other End Sites of that End User. +Furthermore, the following considerations hold: + *different routing policies can be realized, for example, by ensuring that traffic towards this End Site does not travers other End Sites of the assignment holder, unless, e.g., a loss of outbound connectivity occurs at the End Site where a prefix is used + *a Layer 2 connection between two End Sites does not make them one End Site as long as both End Sites have different routing policies + *placing a single device at a location for the main purpose of providing Internet access to a single End User / Customer present at that location does not make that location an End Site of an assignment holder + 3. Goals of IPv6 address space management 3.1. Goals
commit d3de3ebafa98f5e2510307be5e1b7aecb8c77271 Author: Tobias Fiebig <[email protected]> Date: Fri Apr 19 13:29:14 2024 +0200 This change explicates that Section 5.4 pertains to assignments made by LIRs from their allocation to End Users. Purpose: - PI assignments and PA assignments differ in nature. The former is described in Section 7 of this document. However, the unclear wording of, especially, Section 5.4 cause ambiguity which policies apply to PI assignments. - Explicating this now removes that ambiguity Considerations: - The concept of "address usage"/"addressing needs has been inherited from earlier versions of the policy. It might be good to consider addressing this in the future, e.g., in the scope of a more general rewrite of PA policy/the planned nibble boundary change. Changes to draft-00: - Not present Changes to draft-01: - Newly added Changes to draft-02: - Added Considerations Changes to draft-03: - None diff --git a/ripe-738.txt b/ripe-738.txt index 98986c3..13b3bdc 100644 --- a/ripe-738.txt +++ b/ripe-738.txt @@ -251,7 +251,7 @@ If an LIR needs more address space, it must provide documentation justifying its There is no specific policy for an LIR to allocate address space to subordinate ISPs. Each LIR organisation may develop its own policy for subordinate ISPs to encourage optimum utilisation of the total address block allocated to the LIR. However, all /48 assignments to End Sites are required to be registered either by the LIR or its subordinate ISPs in such a way that the RIR/NIR can properly evaluate the HD-Ratio when a subsequent allocation becomes necessary. -5.4. Assignment +5.4. Assignments by LIRs from their allocation LIRs must make IPv6 assignments in accordance with the following provisions. @@ -259,9 +259,9 @@ LIRs must make IPv6 assignments in accordance with the following provisions. End Users are assigned an End Site assignment from their LIR or ISP. The size of the assignment is a local decision for the LIR or ISP to make, using a value of "n" x /64. Section 4.2 of ripe-690 provides guidelines about this. -5.4.2. Assignments shorter than a /48 to a single End Site +5.4.2. Assignments from PA shorter than a /48 -Assignments larger than a /48 (shorter prefix) or additional assignments exceeding a total of a /48 must be based on address usage or because different routing requirements exist for additional assignments. +Assignments made by an LIR from their allocation to an End User larger than a /48 (shorter prefix) or additional assignments exceeding a total of a /48 must be based on address usage, or because routing requirements necessitate a larger assignment. In case of an audit or when making a request for a subsequent allocation, the LIR must be able to present documentation justifying the need for assignments shorter than a /48 to a single End-Site.
commit 5383fcdd19bfec6e37b56cd6a3066c4f51bc1ecb Author: Tobias Fiebig <[email protected]> Date: Fri Apr 19 13:32:37 2024 +0200 This change adds a specific reference to the End Site notion from 2.9. Furthermore, it clarifies how an End User can justify a specific need. Purpose: - Ensure that the current discussion around what constitutes an End Site, especially when L2 interconnectivity exists, is resolved. - Specifying how need can be documented leaves less room for discussions around this point when applying for resources. - Clarify terminology around the 'minimum size' of PI, i.e., that it is /48 or-longer. - Clarify that either addressing needs or the presence of multiple End Sites per 2.9 qualify for shorter prefixes. Considerations: - The concept of "address usage"/"addressing needs has been inherited from earlier versions of the policy. It might be good to consider addressing this in the future, e.g., in the scope of a more general rewrite of PA policy/the planned nibble boundary change. Changes to draft-00: - Jan noted, that the text proposed in draft-00 still left room for interpretation as to how an End User can document a need. This should be resolved by explicitly addressing this question, and noting that an End User is not an End Site, but is instead evaluated accounting for the number of End Sites the End User has. Changes to draft-01: - Clarify text, especially around minimum size - Provide further guidance on the documentation requirements and how these can be evaluated. Changes to draft-02: - Added considerations similar to the ones expressed for 5.4.2 Changes to draft-03: - Made the prefix sizes of PI assignments more explicit diff --git a/ripe-738.txt b/ripe-738.txt index 98986c3..4473c13 100644 --- a/ripe-738.txt +++ b/ripe-738.txt @@ -303,9 +303,11 @@ The PI assignment cannot be further sub-assigned to other organisations. 7.1. IPv6 Provider Independent (PI) Assignment Size -The minimum size of the assignment is a /48. +PI assignments are made to End Users for uses within their infrastructure that do not require sub-assignments according to "2.6. Assign". +PI assignments have a prefix length of /48 or shorter, i.e., cannot be of prefix length /49-/128. -The considerations of "5.4.2. Assignments shorter than a /48 to a single End-Site" must be followed if needed. +To avoid fragmentation, shorter assignments are possible based on addressing need analogous to Section 5.4.2. and for End Users with multiple End Sites according to "2.9 End Site", e.g., when with different routing requirements exist for these End Sites. +When requesting an assignment of a prefix shorter than a /48, or when making a request for a larger or additional assignments, the End User must be able to present documentation justifying the need for assignments shorter than a /48, for example, by providing information on the current and/or planned routing policies in place for each End Site, or by providing documentation on the number of devices to be connected at that End Site. 7.2. IPv6 Provider Independent (PI) Assignments for LIRs
commit 45a6fb901a8b41a7aa8966b09345e3f04c279199 Author: Tobias Fiebig <[email protected]> Date: Fri Apr 19 13:35:21 2024 +0200 This change adds a specific reference to the End Site notion from 2.9. Furthermore, it clarifies how an End User can justify a specific need. Purpose: - Ensure that the current discussion around what constitutes an End Site, especially when L2 interconnectivity exists, is resolved. - Specifying how need can be documented leaves less room for discussions around this point when applying for resources. - Clarify terminology around the 'minimum size' of PI, i.e., that it is /48 or-longer. - Clarify that either addressing needs or the presence of multiple End Sites per 2.9 qualify for shorter prefixes. Changes to draft-00: - Jan noted, that the text proposed in draft-00 still left room for interpretation as to how an End User can document a need. This should be resolved by explicitly addressing this question, and noting that an End User is not an End Site, but is instead evaluated accounting for the number of End Sites the End User has. Changes to draft-01: - Clarify text, especially around minimum size - Provide further guidance on the documentation requirements and how these can be evaluated. Changes to draft-02: - Clarified the last paragraph, i.e., that an assignment may not be split into multiple smaller assignments, while routing more specific prefixes is permissible as long as no sub-assignments take place. Changes to draft-03: - None diff --git a/ripe-738.txt b/ripe-738.txt index 98986c3..f570686 100644 --- a/ripe-738.txt +++ b/ripe-738.txt @@ -307,6 +307,15 @@ The minimum size of the assignment is a /48. The considerations of "5.4.2. Assignments shorter than a /48 to a single End-Site" must be followed if needed. +7.1.1. PI Assignment at the Nibble Boundary + +To aid aggregation as per "3.4. Aggregation" / "3.8. Conflict of Goals" and reduce the need for renumbering in case of futher growth as per "3.7. Minimised Overhead", justified assignments are to be made in nibble boundary steps, i.e., starting with /48, followed by /44, /40 etc. in steps of 4 bit, instead of assigning multiple shorter prefixes. +This means that an End User demonstrating the need for at least two /48s, e.g., due to two End Sites should receive a /44, and an End User demonstrating the need for at least seventeen /48s, e.g., due to seventeen different End Sites should receive a /40 etc. +It is recommended that address space up to the next nibble boundary is reserved if an End User qualifies for a PI assignment of a specific size. + +Registrations for PI assignmets made under this policy are atomic and cannot be split up into smaller prefixes, e.g., a /44 of assigned PI cannot be broken into two or more independent assignments held by the same or different entities. +This does not relate to routing, i.e., one or multiple more specific prefixes from an assignment may be individually routed, as long as no sub-assignment takes place. + 7.2. IPv6 Provider Independent (PI) Assignments for LIRs LIRs can qualify for an IPv6 PI assignment for parts of their own infrastructure that are not used for customer end sites. Where an LIR has an IPv6 allocation, the LIR must demonstrate the unique routing requirements for the PI assignment.
commit 9a2edda792b82379d3f57086914e105812dcdfad Author: Tobias Fiebig <[email protected]> Date: Fri Apr 19 13:38:02 2024 +0200 Make the process for receiving larger assignments clear; Detail how cases where no fitting reservation is in place are to be handled. Purpose: - Clarify what happens if no sufficiently sized reservation is available. - Discourage deaggregation by not allowing the recipt of multiple smaller assignments to satisfy a request for additional assignment size if the requirements are met. Considerations: - The requirement to renumber, i.e., not permitting receipt of multiple, e.g., /48s if a justified /44 request cannot be implemented from a reservation for an existing /48 should discourage deaggregation. Given that PI networks are--comparatively--small, this should be a viable trade-off to prevent further deaggregation. Changes to draft-00: - In the previous version it was not sufficiently clear that this section pertains to End Users which already received an assignment. Changes to draft-01: - Made terminology about extension and return more clear. Changes to draft-02: - None Changes to draft-03: - Small wording changes diff --git a/ripe-738.txt b/ripe-738.txt index 98986c3..9818d9c 100644 --- a/ripe-738.txt +++ b/ripe-738.txt @@ -307,6 +307,13 @@ The minimum size of the assignment is a /48. The considerations of "5.4.2. Assignments shorter than a /48 to a single End-Site" must be followed if needed. +7.1.2. Requesting a Larger Assignment + +If an End User or LIR already holding a PI assignment made under this policy needs a larger Assignment, the End User or LIR must submit a request for a larger assignment and not for one or multiple additional assignments. +This request can be granted, if the criteria for a larger assignment are met as per "7.1. IPv6 Provider Independent (PI) Assignment Size". +When granted, and a reservation for the assignment holder or sufficient unallocated space around the current assignment exists, the assignment must be extended to the next nibble boundary. +If the requested extension to the next nibble boundary cannot be satisfied from an existing reservation or adjacent unallocated space, the End User or LIR receives a new Assignment as per "7.1.1. PI Assignment at the Nibble Boundary" and must return the previous assignment after a six month renumbering period. + 7.2. IPv6 Provider Independent (PI) Assignments for LIRs LIRs can qualify for an IPv6 PI assignment for parts of their own infrastructure that are not used for customer end sites. Where an LIR has an IPv6 allocation, the LIR must demonstrate the unique routing requirements for the PI assignment.
commit c5a439c07084064ef7b0ee9525ca84294861d51b Author: Tobias Fiebig <[email protected]> Date: Fri Apr 19 13:51:57 2024 +0200 Added 7.1.3. detailing handling of existing assignments, recommending aggregation for existing assignment holders. Purpose: - With the current PI assignment practice, de-aggregation took place in the PI space. This provision should provide a lever to force re-aggregation upon rezeizing existing assignments. - This provision also prevents cases where, contrary to options where existing PI holders could automatically enlarge to, e.g., a /44 or the existing reservation size, all of a sudden one End User holds significantly more address space than they need, possibly even increasing GRT size (announcing new covering prefix+keeping old prefix for each PI assignment) - Being able to extend the renumbering period indefinately for PI assigned prior to this policy relaxes burden for renumbering on existing PI holders. Nevertheless, it conserves address space, as these resources are then placed under being mandated to be returned, i.e., are no longer transferrable, encouraging their eventual return. Considerations: - This provision puts some renumbering stress on End Users who received multiple assignments now and need to enlarge their assignment, e.g., if a current holder of two /48 needs a third prefix for a third End Site. However, in the light of the aggregation principle and given the relative size of PI assignments. - It might be reasonable to discuss a larger renumbering period, especially for end-sites currently holding a small IPv6 assignment combined with a large IPv4 assignment. - It might be sensible to integrate this provision into 7.1.2. However, at the moment it is an independent section to provide greater clarity concerning what happens to existing PI assignments which might lack a sufficient reservation to be extended to a /44. Changes to draft-00: - Made it explicit that this provision applies to PI assignments issued before this version of the policy came into effect. Changes to draft-01: - Made the text more explicit about what happens when a new assignment is requested, and when returning previous assignments is required. Changes to draft-02: - None Changes to draft-03: - Adjusted the renumbering period for already held prefixes to not place undue burden on End Users who already hold IPv6 PI based on a suggestion by Jan. diff --git a/ripe-738.txt b/ripe-738.txt index 98986c3..7015d8e 100644 --- a/ripe-738.txt +++ b/ripe-738.txt @@ -307,6 +307,18 @@ The minimum size of the assignment is a /48. The considerations of "5.4.2. Assignments shorter than a /48 to a single End-Site" must be followed if needed. +7.1.3. Existing PI Assignments + +If an End User or LIR, holding one or multiple existing PI assignments, requests an aditional assignment or enlargement of one or multiple of their existing assignment, the request is handled as per "7.1.2. Requesting a Larger Assignment", even if those assignments were made under previous versions of this policy. +This means that their addressing need will be assessed according to "7.1.2. Requesting a Larger Assignment" and they will receive a single assignment corresponding to the result of that evaluation. +If the new assignment can be satisfied by the available reservation or adjacent unallocated space of an existing PI assignment to the assignment holder, this option should be used. +If multiple existing assignments satisfy this requirement, the End User's preference for which assignment to expand should be considered. + +Apart from the newly received or extended PI assignment, all other PI assignments must be returned to the NCC after a period for renumbering as soon as the new PI assignment has been created or an existing one was extended. +The renumbering period for PI assignments previously made under the current version of this policy is six months. +For PI assignments whose requests were evaluated based on a previous version of this policy, the initial renumbering period is twelve months, which can be extended by twelve months every twelve months, if the End User provides the NCC with documentation demonstrating that a renumbering is currently not feasible, e.g., due to high costs or operational complexity. +Even though, technically, the renumbering period can thereby extended indefinately, return of these PI assignments remains mandated. + 7.2. IPv6 Provider Independent (PI) Assignments for LIRs LIRs can qualify for an IPv6 PI assignment for parts of their own infrastructure that are not used for customer end sites. Where an LIR has an IPv6 allocation, the LIR must demonstrate the unique routing requirements for the PI assignment.
diff --git a/ripe-738.txt b/ripe-738.txt index 98986c3..18589f6 100644 --- a/ripe-738.txt +++ b/ripe-738.txt @@ -112,9 +112,14 @@ To “allocate” means to distribute address space to IRs for the purpose of su 2.6. Assign -To “assign” means to delegate address space to an ISP or End User for specific use within the Internet infrastructure they operate. Assignments must only be made for specific purposes documented by specific organisations and are not to be sub-assigned to other parties. +To “assign” means to delegate address space to an ISP or End User for specific use within the Internet infrastructure that ISP or End User operates. Assignments must only be made for specific purposes documented by specific organisations, and an assignment holder is not allowed to create further sub-assignments to another entity from address space partially or fully covering an assignment. -Providing another entity with separate addresses (not prefixes) from a subnet used on a link operated by the assignment holder is not considered a sub-assignment. This includes for example letting visitors connect to the assignment holder's network, connecting a server or appliance to an assignment holder's network and setting up point-to-point links with 3rd parties. +Providing another entity inside the assignment holder's network and located at the same geographical end-site with prefix sizes of /56 or longer, e.g., for letting visitors connect to the assignment holder's network, providing static addresses when connecting a server or appliance to an assignment holder's network, or providing a single service with multiple addresses is not considered a sub-assignment. + +Similarly, using a /64 or longer when setting up point-to-point links with other ISPs for the purpose of exchanging traffic and Internet routing information does not constitute a sub-assignment. +Any other use of a prefix from an assignment up to prefixes of /128 bit, i.e., up to single addresses, to connect an end-site of another entity to the Internet, always constitutes a prohibited sub-assignment. + +Finally, using more specific prefixes from a less-specific assignment for different parts of the same infrastructure within one organziation does not constitute a sub-assignment, if the purpose of the assignment is the operation of that infrastructure. 2.7. Utilisation @@ -133,12 +138,18 @@ where (in the case of this document) the objects are IPv6 site addresses assigne 2.9. End Site -An End Site is defined as the location of an End User (subscriber) who has a business or legal relationship (same or associated entities) with a service provider that involves: +An End Site for assignments from a provider's allocation is defined as the topological location of an End User (subscriber) in the RIPE NCC Service Region who has a business or legal relationship (same or associated entities) with a service provider that involves: *that service provider assigning address space to the End User location *that service provider providing transit service for the End User location to other sites *that service provider carrying the End User's location traffic *that service provider advertising an aggregate prefix route that contains the End User's location assignment +An End Site for provider independent assignments (PI) directly to an End User from the RIPE NCC via a sponsoring LIR or directly to an LIR is defined as any topological location in the RIPE NCC Service Region where the End User deploys Internet connected devices, which has a different routing policy than other End Sites of that End User. +Furthermore, the following considerations hold: + *different routing policies can be realized, for example, by ensuring that traffic towards this End Site does not travers other End Sites of the assignment holder, unless, e.g., a loss of outbound connectivity occurs at the End Site where a prefix is used + *a Layer 2 connection between two End Sites does not make them one End Site as long as both End Sites have different routing policies + *placing a single device at a location for the main purpose of providing Internet access to a single End User / Customer present at that location does not make that location an End Site of an assignment holder + 3. Goals of IPv6 address space management 3.1. Goals @@ -251,7 +262,7 @@ If an LIR needs more address space, it must provide documentation justifying its There is no specific policy for an LIR to allocate address space to subordinate ISPs. Each LIR organisation may develop its own policy for subordinate ISPs to encourage optimum utilisation of the total address block allocated to the LIR. However, all /48 assignments to End Sites are required to be registered either by the LIR or its subordinate ISPs in such a way that the RIR/NIR can properly evaluate the HD-Ratio when a subsequent allocation becomes necessary. -5.4. Assignment +5.4. Assignments by LIRs from their allocation LIRs must make IPv6 assignments in accordance with the following provisions. @@ -259,9 +270,9 @@ LIRs must make IPv6 assignments in accordance with the following provisions. End Users are assigned an End Site assignment from their LIR or ISP. The size of the assignment is a local decision for the LIR or ISP to make, using a value of "n" x /64. Section 4.2 of ripe-690 provides guidelines about this. -5.4.2. Assignments shorter than a /48 to a single End Site +5.4.2. Assignments from PA shorter than a /48 -Assignments larger than a /48 (shorter prefix) or additional assignments exceeding a total of a /48 must be based on address usage or because different routing requirements exist for additional assignments. +Assignments made by an LIR from their allocation to an End User larger than a /48 (shorter prefix) or additional assignments exceeding a total of a /48 must be based on address usage, or because routing requirements necessitate a larger assignment. In case of an audit or when making a request for a subsequent allocation, the LIR must be able to present documentation justifying the need for assignments shorter than a /48 to a single End-Site. @@ -303,9 +314,39 @@ The PI assignment cannot be further sub-assigned to other organisations. 7.1. IPv6 Provider Independent (PI) Assignment Size -The minimum size of the assignment is a /48. +PI assignments are made to End Users for uses within their infrastructure that do not require sub-assignments according to "2.6. Assign". +PI assignments have a prefix length of /48 or shorter, i.e., cannot be of prefix length /49-/128. + +To avoid fragmentation, shorter assignments are possible based on addressing need analogous to Section 5.4.2. and for End Users with multiple End Sites according to "2.9 End Site", e.g., when with different routing requirements exist for these End Sites. +When requesting an assignment of a prefix shorter than a /48, or when making a request for a larger or additional assignments, the End User must be able to present documentation justifying the need for assignments shorter than a /48, for example, by providing information on the current and/or planned routing policies in place for each End Site, or by providing documentation on the number of devices to be connected at that End Site. + +7.1.1. PI Assignment at the Nibble Boundary + +To aid aggregation as per "3.4. Aggregation" / "3.8. Conflict of Goals" and reduce the need for renumbering in case of futher growth as per "3.7. Minimised Overhead", justified assignments are to be made in nibble boundary steps, i.e., starting with /48, followed by /44, /40 etc. in steps of 4 bit, instead of assigning multiple shorter prefixes. +This means that an End User demonstrating the need for at least two /48s, e.g., due to two End Sites should receive a /44, and an End User demonstrating the need for at least seventeen /48s, e.g., due to seventeen different End Sites should receive a /40 etc. +It is recommended that address space up to the next nibble boundary is reserved if an End User qualifies for a PI assignment of a specific size. + +Registrations for PI assignmets made under this policy are atomic and cannot be split up into smaller prefixes, e.g., a /44 of assigned PI cannot be broken into two or more independent assignments held by the same or different entities. +This does not relate to routing, i.e., one or multiple more specific prefixes from an assignment may be individually routed, as long as no sub-assignment takes place. + +7.1.2. Requesting a Larger Assignment + +If an End User or LIR already holding a PI assignment made under this policy needs a larger Assignment, the End User or LIR must submit a request for a larger assignment and not for one or multiple additional assignments. +This request can be granted, if the criteria for a larger assignment are met as per "7.1. IPv6 Provider Independent (PI) Assignment Size". +When granted, and a reservation for the assignment holder or sufficient unallocated space around the current assignment exists, the assignment must be extended to the next nibble boundary. +If the requested extension to the next nibble boundary cannot be satisfied from an existing reservation or adjacent unallocated space, the End User or LIR receives a new Assignment as per "7.1.1. PI Assignment at the Nibble Boundary" and must return the previous assignment after a six month renumbering period. + +7.1.3. Existing PI Assignments + +If an End User or LIR, holding one or multiple existing PI assignments, requests an aditional assignment or enlargement of one or multiple of their existing assignment, the request is handled as per "7.1.2. Requesting a Larger Assignment", even if those assignments were made under previous versions of this policy. +This means that their addressing need will be assessed according to "7.1.2. Requesting a Larger Assignment" and they will receive a single assignment corresponding to the result of that evaluation. +If the new assignment can be satisfied by the available reservation or adjacent unallocated space of an existing PI assignment to the assignment holder, this option should be used. +If multiple existing assignments satisfy this requirement, the End User's preference for which assignment to expand should be considered. -The considerations of "5.4.2. Assignments shorter than a /48 to a single End-Site" must be followed if needed. +Apart from the newly received or extended PI assignment, all other PI assignments must be returned to the NCC after a period for renumbering as soon as the new PI assignment has been created or an existing one was extended. +The renumbering period for PI assignments previously made under the current version of this policy is six months. +For PI assignments whose requests were evaluated based on a previous version of this policy, the initial renumbering period is twelve months, which can be extended by twelve months every twelve months, if the End User provides the NCC with documentation demonstrating that a renumbering is currently not feasible, e.g., due to high costs or operational complexity. +Even though, technically, the renumbering period can thereby extended indefinately, return of these PI assignments remains mandated. 7.2. IPv6 Provider Independent (PI) Assignments for LIRs
-- 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
