Hi, I agree with others that this changes too many things at once and might have unexpected consequences, so I suggest it is split into multiple proposals. i.e. this is to allow guest WiFis, this is to allow hosting, this redefines End Sites, this is to allow larger than /48s, etc. By reading the current and proposed policy I notice some confusing usage of more/less specific, larger or shorter prefixes in the current policy, perhaps this is something to clarify in the future. As I read it, the current version of the proposal complicates the policy instead of clarifying, adds impossible to verify requirements, uses new and undefined terms and has some contradictions, while the clear outcome is making it easier to obtain larger than /48 assignments based on routing requirements instead of address usage. One such contradiction is related to the aggregation as one of the stated purposes of the proposal while the text explicitly allows announcing separate prefixes from the assignment (de-aggregation), and it seems phrased for a very specific and complex use-case. I am surprised by the cases of assigning multiple /48s for the same End Site that would otherwise be aggregated that were mentioned in the thread, is there an example of such case with some more details? I am unable to find any. This should be fixed, however I see no issue with assigning based on usage. A /48 is a one-size-fits-all default for End-Sites (RFC3177/6177), except for *very large subscribers*, a /48 has 256 x /56 or 65536 x /64, and one /64 has *a lot* of addresses available for connecting devices. With the current proposed text I do not foresee a queue of PI holders seeking to aggregate, but a queue of PI holders seeking single larger assignments to de-aggregate. Perhaps some numbers from the NCC would help? Such as how many PI assignments are there (if multiple /48s are in the same ticket this is not necessarily visible in the DB). xxxx /48s PI yyyy /46s PI zzzz multiple /48s PI in the same ticket for use at the same location (that could be aggregated) And maybe some reasons for multiple /48s such as "different End Sites"? Here is a breakdown of what I found debatable or confusing: New 2.6 - Introduces the term "geographical End Site" that is undefined and impossible to verify. Is my building number +/-1 the same geographical End Site? Is the geographical limit set by the range of the WiFi? The NCC service region? - Allows /56 or longer to different entities without being considered a sub-assignment - "using more specific prefixes from a less specific assignment for different parts of the same infra does not constitute a sub-assignment" => This is already covered by the first paragraph, for me it is expected to use more specific prefixes inside your infra, while announcing the aggregate to the Internet, this is what the assignment is for. - "any other use of a prefix ... to connect a separate End Site of another entity to the Internet always constitutes a prohibited sub-assignment" => So it is not allowed to use any prefix up to /128 to connect a separate End Site of another entity to the Internet. But it is allowed to "provide connectivity to another entity", not a device or multiple devices but an "entity". It is not allowed if it is a separate End Site. The proposed 2.9 says that a device placed at a different location (CPE) for the purpose of providing Internet access to a single user is not a different End Site (is the device/CPE something you can touch or is this SDN-way?). So providing Internet access at a different location (in this case not geographical or topological) to a single user is allowed. Is the single user an entity? More confusion adds up since the paragraphs above allow /64 or longer to connect to other ISPs for the purpose of "exchanging traffic and Internet routing information", and /56 or longer to different entities. Is exchanging traffic and Internet routing information not what the Internet is? How is an ISP defined in this context? Since providing Internet to a single user (even at a different location) is allowed but being an ISP is not. Is not providing Internet access what an ISP does? But this can go on up to the meaning of life, the universe and everything and we will only get /42s from that point on. Usually when providing *services*, the ISP assigns the range for the interconnection from their address space, not the End User (PI holder), this change would make the PI holder an ISP while disallowing them to be an ISP at the same time. I am not aware of any implicit need to use LL for interconnectivity, could this be clarified? New 2.9 - Introduces yet another undefined term: the "topological location" 2.9.2 - Different routing policies are defined in a complicated manner as they do not traverse other End Sites of the same assignment holder, unless there is a loss of outbound connectivity where a prefix from the assignment is used (so they do not traverse unless they traverse). This explicitly allows de-aggregating the PI prefix and using the de-aggregated sub-prefixes at different locations. - Adds impossible to verify things such as L2s between End Sites. Trust me, this is L2. - Differentiate between End Sites in PI and allocation cases: providing different definitions of the same term adds confusion while the benefits of defining End Sites differently are not clear. - Clarify that L2, clarify that aggregates or prepends do not merge routing policies: These are impossible to verify claims, RIPE NCC is not the Routing Police or L2 Police. - Make explicit that placing a single device at another geographical location 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. This suggests that using parts of the assignment for providing Internet access to customers at different locations from the End Site is ok, however it is prohibited by the new 2.6. New 5.4 5.4.2 Assignments from IPv6 allocations => In my opinion this paragraph would encourage/permit de-aggregation of assignments from allocations (PA) based on routing requirements. The original version is pretty clear that it refers to assignments "from their LIR or ISP" and there is no room for interpretation if this is referring to PI, so no changes are required to the policy text here. New 7.1 The very short, to the point, minimum assignment size of /48 is replaced by a very long and interpretable text. - Introduces a new term "special purpose PI assignment" that may deviate from generic PI assignment criteria - "to avoid fragmentation" the new text adds routing policies as permitted justification for shorter prefixes and explicitly allows more specific prefixes of PI space (de-aggregation of PI). 7.1.3 adds a reevaluation mechanism for previous assignments in order to provide contiguous address space, however that will be de-aggregated due to routing requirements and/or multiple End Sites. Contiguous address space makes sense for aggregation purposes (single prefix announced). In my opinion this does not resolve the discussions around what constitutes an End Site, and things such as L2 connectivity are impossible to objectively verify by external parties. The current policy does not in fact disagree with RIPE-451 (IPv6 Address Space Policy For IXPs) since that is IXP address space, not IXP PI (even though it is subject to contractual requirements similar to PI). The consideration that a /44 would stop de-aggregation to /48s contradicts the text from the proposed changes - different routing policies are let's say hard to implement if only the aggregate is announced, and, given that PI networks are comparatively small (as the proposed text says) they most likely fit in the /48 default. Radu On 27.08.2024 17:10, Leo Vegoda wrote:
Dear Working Group,
This is a reminder that we need your input on this policy proposal.
If you support the proposal in principle, please say so on this list.
If you disagree with the proposal, please explain the problem you seel.
Many thanks,
Leo Vegoda, for the Address Policy WG co-chairs
On Tue, 13 Aug 2024 at 05:17, Angela Dall'Ara <adallara@ripe.net> wrote:
Dear colleagues,
A new RIPE Policy Proposal, 2024-01, "Revised IPv6 PI Assignment Policy" is now available for discussion.
This proposal aims to define End Sites and requirements for “IPv6 PI Assignments” and “Assignments from IPv6 Allocations”, clarifies permitted use cases and introduces IPv6 PI issuance at the Nibble boundary and new principles for aggregation and registration.
You can find the full proposal at: https://www.ripe.net/community/policies/proposals/2024-01
As per the RIPE Policy Development Process (PDP), the purpose of the Discussion Phase is to discuss the proposal and provide feedback to the proposer. Taking in consideration the holiday period, the Address Policy WG Chairs decided to allow five weeks for this initial phase.
At the end of the Discussion Phase, the proposer, with the agreement of the WG Chairs, will decide how to proceed with the proposal.
The PDP document can be found at: https://www.ripe.net/publications/docs/ripe-781
We encourage you to review this proposal and send your comments to address-policy-wg@ripe.net before 18 September 2024.
Kind regards,
Angela Dall'Ara Policy Officer RIPE NCC
----- 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/
----- 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/