Moin, thank you all for your feedback on 2024-01. With the discussion slot coming up at RIPE-89, I wanted to share some considerations on how the various suggestions from the ML could be addressed ahead of time, so we can go for a more active on-site discussion.
I put the changes into git again: https://git.as59645.net/tfiebig/ripe-738-pi-update/src/branch/draft-09/draft_changes/draft-08-to-draft-09 Specifically, I saw the following core-points: - Concerns about the interaction with the charging scheme I clarified again, that charging scheme discussions are out of scope, also illustrating the voiced concerns and that--ultimately--the same effect is already present with the current version of the policy. - Concerns regarding various terms and handling of PA vs. PI The purpose for changes to 2.9 and 5.4 have been explained in more detail in the associated considerations. Furthermore, some clarifications have been integrated into the text. I also made clear that the purpose is the defragmentation of the registry. - Concerns voiced regarding evaluation of renumbering requests The policy now clearly discusses how and under which conditions renumbering is necessary, and when which prefixes need to be handed back, including methods to reduce the impact on End Users that may face, e.g., renumbering, i.e., allowing the withdrawel of a request if it would otherwise cause renumbering. I am looking forward to further discussions on the list, as well as to a lively discussion at the upcoming meeting. With best regards, Tobias
diff --git a/ripe-738.txt b/ripe-738.txt index 3807133..9ecd1e4 100644 --- a/ripe-738.txt +++ b/ripe-738.txt @@ -119,7 +119,7 @@ To “allocate” means to distribute address space to IRs for the purpose of su To “assign” means to delegate address space to an ISP or End User for specific use within the Internet infrastructure that they operate. Assignments must only be made for specific purposes documented by specific organisations, and it is not allowed to create further sub-assignments to another entity from address space partially or fully covering an assignment. -Providing connectivity to another entity inside the assignment holder’s network located at the same geographical End Site as the holder’s network with a prefix size of /56 or longer from the assignment is not considered a sub-assignment. This includes letting visitors connect to the assignment holder's network, providing static addresses when connecting a server or appliance to an assignment holder's network, providing a single service with multiple addresses, or 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. +This does not pertain to uses of address space that do not constitute a subassignment: Providing connectivity to another entity inside the assignment holder’s network located at the same geographical End Site as the holder’s network with a prefix size of /56 or longer from the assignment is not considered a sub-assignment. This includes letting visitors connect to the assignment holder's network, providing back-office connectivity for devices deployed or operated by the assignment holder, providing static addresses when connecting a server or appliance to an assignment holder's network, providing a single service with multiple addresses, or 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. Finally, using more specific prefixes from a less-specific assignment for different parts of the same infrastructure within one organisation does not constitute a sub-assignment, if the purpose of the assignment is the operation of that infrastructure. Any other use of a prefix from an assignment up to prefixes of /128 bit to connect a separate End Site of another entity to the Internet always constitutes a prohibited sub-assignment. @@ -138,27 +138,25 @@ Log (maximum number of allocatable objects) where (in the case of this document) the objects are IPv6 site addresses assigned from an IPv6 prefix of a given size. -2.9. End Site +2.9End Site 2.9.1 End Site for Assignments Made from Allocation An End Site for assignments made from an allocation is defined as the topological location of an End User (subscriber) 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 assignment. + *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 assignment 2.9.2 End Site for PI Assignment An End Site for provider independent assignments (PI) is defined as any topological location in the RIPE NCC Service Region where the End User deploys Internet-connected devices and that has a different routing policy than other End Sites of that End User. - Furthermore, the following considerations hold: + *different routing policies can be realised to ensure that traffic towards an End Site does not traverse other End Sites of the assignment holder, unless, for example, there is a loss of outbound connectivity at the End Site where a prefix from the assignment 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 + *a single device (CPE) with the main purpose of providing Internet access to a single End User / Customer from a location does not constitute an End Site of an assignment holder + *Anycast deployments originating a prefix from at least two independent end-sites are counted as a single additional end-site. - *different routing policies can be realised to ensure that traffic towards an End Site does not traverse other End Sites of the assignment holder, unless, for example, there is a loss of outbound connectivity at the End Site where a prefix from the assignment is used. - *a single device with the main purpose of providing Internet access to a single End User / Customer from a location does not constitute an End Site of an assignment holder. - *a single device with the main purpose of providing Internet access to a single End User / Customer from a location does not constitute an End Site of an assignment holder - *multiple sites with the primary purpose of announcing the same prefix from different locations that are not interconnected (i.e. Anycast setups) are counted as a single site. 3. Goals of IPv6 address space management @@ -314,6 +312,8 @@ Anycasting assignments are registered with a status of 'ASSIGNED ANYCAST' in the 7. IPv6 Provider Independent (PI) Assignments +This section states general policy for IPv6 Provider Independent (PI) Assignments. More specific regulations for additional special purpose PI assignments may deviate from the generic PI assignment criteria stated here. + To qualify for IPv6 PI address space, an organisation must meet the requirements of the policies described in the RIPE NCC document entitled “Contractual Requirements for Provider Independent Resources Holders in the RIPE NCC Service Region”. The RIPE NCC will assign the prefix directly to the End User organisations upon a request properly submitted to the RIPE NCC, either directly or through a sponsoring LIR. @@ -324,19 +324,17 @@ The PI assignment cannot be further sub-assigned to other organisations. 7.1. IPv6 Provider Independent (PI) Assignment Size -PI assignments always have a prefix size longer than the minimum allocation size. The longest prefix size for PI assignments is a /48. - -More specific regulations for additional special purpose PI assignments may deviate from generic PI assignment criteria. +The largest PI assignments always have a prefix size longer than the minimum allocation size. Generally, the smallest PI assignments have a maximum prefix size of /48, used in case of a single globally reachable End-Site. Smaller prefixes may be assigned in cases where an end-site does not require global reachability, e.g., making an assignment for addresses used in an Internet exchange's peering LAN. -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 Section 2.9.2 “End Site for PI Assignment,” e.g. when different routing requirements exist for these End Sites. +To avoid fragmentation of the address registry, shorter assignments are possible based on addressing need analogous to Section 5.4.2 and for End Users with multiple End Sites according to Section 2.9.2 “End Site for PI Assignment,” e.g. when different routing requirements exist for these End Sites. When requesting an assignment with a prefix shorter than a /48, an additional assignment, or an extension of an existing assignment to a size larger than a /48, the need must be justified, for example, by documenting the current and/or planned routing policies in place for each End Site or the expected utilisation according to 2.7 within the next 12 months. 7.1.1. PI Assignment at the Nibble Boundary -To aid aggregation and reduce the need for renumbering in case of growth, justified assignments are to be made in nibble boundary steps (i.e. starting with /48, followed by /44, /40, and /36, in steps of 4 bits), instead of assigning multiple shorter prefixes. +To aid aggregated registration and reduce the need for renumbering in case of growth, justified assignments are to be made in nibble boundary steps (i.e. starting with /48, followed by /44, /40, and /36, in steps of 4 bits), 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 End Sites, should receive a /40, etc. -It is recommended that address space up to the next nibble boundary is left unused whenever a PI assignment is issued. +It is recommended that address space up to the next larger assignment size at the nibble boundary is left unused whenever a PI assignment is issued. Registrations for PI assignments made after <DATE OF PROPOSAL IMPLEMENTATION> cannot be split up into smaller prefixes (for example, a /44 assigned PI cannot be broken into two or more independent assignments). More specific prefixes from an assignment may be individually routed, as long as no sub-assignment takes place. @@ -345,20 +343,20 @@ More specific prefixes from an assignment may be individually routed, as long as If an End User or LIR already holding one or multiple PI assignments issued after <DATE OF PROPOSAL IMPLEMENTATION> needs more IPv6 PI address space, they must submit a request for an extension of their current assignment to the next nibble boundary satisfying the new needs. -Such an extension can be granted if the policy requirements are met and if there is sufficient available space contiguous to the existing assignment +Such an extension can be granted if the policy requirements are met and if there is sufficient available space contiguous to the existing assignment. If the requested extension to the next nibble boundary cannot be granted from the existing available 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 within a six-month renumbering period. 7.1.3. Existing PI Assignments -An End User or LIR holding PI assignments issued before <DATE OF PROPOSAL IMPLEMENTATION> will have their addressing needs reevaluated as per 7.1.2 “Requesting a Larger Assignment" when they request an additional or larger assignment, or when they explicitly request a reevaluation of their addressing needs. - +When requesting an additional or larger assignment, an End User or LIR holding PI assignments issued before <DATE OF PROPOSAL IMPLEMENTATION> will have their addressing needs reevaluated as per 7.1.2 “Requesting a Larger Assignment". Such a reevaluation may also be explicitly request. +Similarly, receiving a transfer of a PI assignment also leads to a reevaluation of addressing needs. They will receive a single assignment corresponding to the result of that evaluation. If the new assignment can be issued using or extending the prefix of an existing assignment including any or all of the following: - *Existing PI assignments to the same holder. - *Contiguous available address space. + *Existing PI assignments to the same holder + *Contiguous available address space Then that prefix should be used to make the new assignment. @@ -375,6 +373,18 @@ For PI assignment requests evaluated before <DATE OF PROPOSAL IMPLEMENTATION> th Even though, technically, the renumbering period can thereby be extended indefinitely, return of these PI assignments remains mandated. +If a PI prefix from an assignment evaluated before <DATE OF PROPOSAL IMPLEMENTATION> is received in a transfer, it falls under the same rules. + +An assignment holder may opt, at any time prior to an assignment being updated according to their addressing needs, to withdraw the initial request (transfer, reevaluation, larger assignment) that triggered the reevaluation. +This may only be done once. + +An assignment holder should be made aware of this option if either: + +*The assignment holder holds an assignment evaluated before <DATE OF PROPOSAL IMPLEMENTATION> or is to receive such an assignment in a transfer + *The assessment of addressing needs would lead to a reduction in the assignment size, and/or mandate the return of address space under a given renumbering period + +If the end user opts to do so, all assignments remain in the state prior to the request having been made. + 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.
----- To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/address-policy-wg.ripe.net/ As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at: https://www.ripe.net/membership/mail/mailman-3-migration/
