2024-01 New Policy Proposal (Revised IPv6 PI Assignment Policy)
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
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/
On 27. 8. 24 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.
Hi, Reading the new policy proposal - I can see that Tobias addressed most (if not all) suggestions and comments that I remember being mentioned in this discussion. This proposal is fixing an actual issue and is very much needed - so I think that it's good to go and should be implemented ASAP. Thank you Tobias, chairs and the WG. Cheers, Jan
Hi all, Overall this policy proposal looks good, and addresses some long standing gripes I've had with the IPv6 PI policy. I do have a few comments, points for clarification, etc.: The new text for 2.6 seems to not allow assignment of a /64 to an appliance connected to the End User's network. As a VPS provider (and as many other VPS providers do) I allocate a /64 to every VPS that the customer is free to use however they want within the VPS. The policy says that the purpose is to allow this (imo correctly so) but on the most pedantic reading the policy itself doesn't seem to allow that. Tiny nit: 2.6 should make an explicit reference to "best practices" being IETF BCP157, just for clarity for the uninformed reader. 2.9 seems fine, no comments on that. Same for 5.4 I think 7.1 should be explicit that prefixes shorter than a /48 can be assigned to one End Site, as this has been a major pain point in the past. The nibble boundary assignment mechanism is neat, I like it! Does "All previously issued PI assignments must be returned to the RIPE NCC after renumbering once the new PI assignment has been issued or an existing one was extended" mean to imply that an End User will only ever receive 1 PI assignment under this new policy but that it can be expanded as much as is needed to accommodate addressing needs? If so this should be more explicit. I support this policy and look forward to its refinement and implementation. Q Misell ------------------------------ Any statements contained in this email are personal to the author and are not necessarily the statements of the company unless specifically stated. AS207960 Cyfyngedig, having a registered office at 13 Pen-y-lan Terrace, Caerdydd, Cymru, CF23 9EU, trading as Glauca Digital, is a company registered in Wales under № 12417574 <https://find-and-update.company-information.service.gov.uk/company/12417574>, LEI 875500FXNCJPAPF3PD10. ICO register №: ZA782876 <https://ico.org.uk/ESDWebPages/Entry/ZA782876>. UK VAT №: GB378323867. EU VAT №: EU372013983. Turkish VAT №: 0861333524. South Korean VAT №: 522-80-03080. AS207960 Ewrop OÜ, having a registered office at Lääne-Viru maakond, Tapa vald, Porkuni küla, Lossi tn 1, 46001, trading as Glauca Digital, is a company registered in Estonia under № 16755226. Estonian VAT №: EE102625532. Glauca Digital and the Glauca logo are registered trademarks in the UK, under № UK00003718474 and № UK00003718468, respectively. On Tue, 27 Aug 2024 at 17:10, Leo Vegoda <leo@vegoda.org> 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://e.as207960.net/w4bdyj/7ZF5x0uZtU4p2saY
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://e.as207960.net/w4bdyj/4dlSCCuRbRTh3q1O
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://e.as207960.net/w4bdyj/S1EdjQ92BN9Yx60e
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://e.as207960.net/w4bdyj/A0BlHC1spGWb2Wj1
To unsubscribe from this mailing list or change your subscription options, please visit: https://e.as207960.net/w4bdyj/0EPY1z0BjXgNTchu 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://e.as207960.net/w4bdyj/qpeptz7nlPfus60x
Moin,
The new text for 2.6 seems to not allow assignment of a /64 to an appliance connected to the End User's network. As a VPS provider (and as many other VPS providers do) I allocate a /64 to every VPS that the customer is free to use however they want within the VPS. The policy says that the purpose is to allow this (imo correctly so) but on the most pedantic reading the policy itself doesn't seem to allow that.
Using, most likely, PA at the moment, I guess. ;-) Despite, the policy states: 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, This is, explicitly, the case you mentioned, no?
Tiny nit: 2.6 should make an explicit reference to "best practices" being IETF BCP157, just for clarity for the uninformed reader.
Can be fixed.
I think 7.1 should be explicit that prefixes shorter than a /48 can be assigned to one End Site, as this has been a major pain point in the past.
The general rule of thumb is one /48 per end-site, unless addressing (2.7) or routing reasons require more. The point of pain from the past was actually the phrasing in 2.6, where an oxford comma was missing, restricting it to addressing needs only in practice.
The nibble boundary assignment mechanism is neat, I like it!
Thanks.
Does "All previously issued PI assignments must be returned to the RIPE NCC after renumbering once the new PI assignment has been issued or an existing one was extended" mean to imply that an End User will only ever receive 1 PI assignment under this new policy but that it can be expanded as much as is needed to accommodate addressing needs? If so this should be more explicit.
The end-user will, in general, only hold _one_ PI assignment covering their needs at a time. Exceptions are: - A more specific policy permits more Assignments, e.g., if the IXP PI policy would explicitly note PI prefixes to be additionally assigned, due to the override of more specific policy (2nd par 7.1; Also there to resolve the issue that, at the moment, the IXP policy is incompatible with the general policy, as it allows /64 assignments) - The end-user had received PI before the updated policy came into effect and keeps (justified!) extending the renumbering period; Still, _return_ is mandated, as this means the resources can no longer be transferred (to counter hoarding). - For the period of time during renumbering, given the prior resources have not been assigned prior to the new version of the policy being implemented. Furthermore, held PI can only be extended if unused space allows so, see 7.1.2. Otherwise, a new assignment satisfying the addressing needs will be made (with, recommended at least, an additional nibble left unused for subsequent growth), and the EU has to renumber. Finally, the maximum size of PI is locked at 'a nibble less than the smallest allocation', i.e., there cannot be a PI assignment larger than a /36.
I support this policy and look forward to its refinement and implementation.
Thank you, appreciated. With best regards, Tobias
This is, explicitly, the case you mentioned, no?
On second reading, yes it is.
The point of pain from the past was actually the phrasing in 2.6
I don't see the problematic phrasing in the old version of 2.6. Can you point it out please?
The end-user will, in general, only hold one PI assignment covering their needs at a time.
Perhaps the policy could be reworded to make this clearer. ------------------------------ Any statements contained in this email are personal to the author and are not necessarily the statements of the company unless specifically stated. AS207960 Cyfyngedig, having a registered office at 13 Pen-y-lan Terrace, Caerdydd, Cymru, CF23 9EU, trading as Glauca Digital, is a company registered in Wales under № 12417574 <https://find-and-update.company-information.service.gov.uk/company/12417574>, LEI 875500FXNCJPAPF3PD10. ICO register №: ZA782876 <https://ico.org.uk/ESDWebPages/Entry/ZA782876>. UK VAT №: GB378323867. EU VAT №: EU372013983. Turkish VAT №: 0861333524. South Korean VAT №: 522-80-03080. AS207960 Ewrop OÜ, having a registered office at Lääne-Viru maakond, Tapa vald, Porkuni küla, Lossi tn 1, 46001, trading as Glauca Digital, is a company registered in Estonia under № 16755226. Estonian VAT №: EE102625532. Glauca Digital and the Glauca logo are registered trademarks in the UK, under № UK00003718474 and № UK00003718468, respectively. On Thu, 29 Aug 2024 at 11:01, Tobias Fiebig via address-policy-wg < address-policy-wg@ripe.net> wrote:
Moin,
The new text for 2.6 seems to not allow assignment of a /64 to an appliance connected to the End User's network. As a VPS provider (and as many other VPS providers do) I allocate a /64 to every VPS that the customer is free to use however they want within the VPS. The policy says that the purpose is to allow this (imo correctly so) but on the most pedantic reading the policy itself doesn't seem to allow that.
Using, most likely, PA at the moment, I guess. ;-)
Despite, the policy states:
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,
This is, explicitly, the case you mentioned, no?
Tiny nit: 2.6 should make an explicit reference to "best practices" being IETF BCP157, just for clarity for the uninformed reader.
Can be fixed.
I think 7.1 should be explicit that prefixes shorter than a /48 can be assigned to one End Site, as this has been a major pain point in the past.
The general rule of thumb is one /48 per end-site, unless addressing (2.7) or routing reasons require more. The point of pain from the past was actually the phrasing in 2.6, where an oxford comma was missing, restricting it to addressing needs only in practice.
The nibble boundary assignment mechanism is neat, I like it!
Thanks.
Does "All previously issued PI assignments must be returned to the RIPE NCC after renumbering once the new PI assignment has been issued or an existing one was extended" mean to imply that an End User will only ever receive 1 PI assignment under this new policy but that it can be expanded as much as is needed to accommodate addressing needs? If so this should be more explicit.
The end-user will, in general, only hold _one_ PI assignment covering their needs at a time. Exceptions are:
- A more specific policy permits more Assignments, e.g., if the IXP PI policy would explicitly note PI prefixes to be additionally assigned, due to the override of more specific policy (2nd par 7.1; Also there to resolve the issue that, at the moment, the IXP policy is incompatible with the general policy, as it allows /64 assignments) - The end-user had received PI before the updated policy came into effect and keeps (justified!) extending the renumbering period; Still, _return_ is mandated, as this means the resources can no longer be transferred (to counter hoarding). - For the period of time during renumbering, given the prior resources have not been assigned prior to the new version of the policy being implemented.
Furthermore, held PI can only be extended if unused space allows so, see 7.1.2. Otherwise, a new assignment satisfying the addressing needs will be made (with, recommended at least, an additional nibble left unused for subsequent growth), and the EU has to renumber.
Finally, the maximum size of PI is locked at 'a nibble less than the smallest allocation', i.e., there cannot be a PI assignment larger than a /36.
I support this policy and look forward to its refinement and implementation.
Thank you, appreciated.
With best regards, Tobias ----- To unsubscribe from this mailing list or change your subscription options, please visit: https://e.as207960.net/w4bdyj/ZRhbv0gIFFblAIZg 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://e.as207960.net/w4bdyj/OCe9syVNvTrY5YAF
Moin,
The point of pain from the past was actually the phrasing in 2.6
I don't see the problematic phrasing in the old version of 2.6. Can you point it out please?
Ah, my mistake; Actually it was in 5.4.2 of the old text: "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." Which was interpreted to parse to: Assignments # That are either [larger than a /48 (shorter prefix)] # Implicit Exclusive OR or [additional assignments exceeding a total of a /48] # If address usage requires larger network [must be based on address usage] # Inclusive OR or ( # Different routing requirements exist [because different routing requirements exist] # Implicit conditional; i.e., AND it is about # _additional_ assignments, not a shorter # prefix. [for additional assignments.] ) This means that the _only_ way to justify anything larger than a /48 for a single end-site (even considering 'large', i.e., L2 connected ones) can only be justified via address usage/addressing needs. Assuming a /64 per device, this would mean at least (2**16) + 1 devices (i had a corresponding ticket; See the AP-WG ML archives.)
The end-user will, in general, only hold one PI assignment covering their needs at a time.
Perhaps the policy could be reworded to make this clearer.
Yeah, we can see what can be changed textually; Do you have any suggestions? With best regards, Tobias
Yeah, we can see what can be changed textually; Do you have any suggestions?
I would replace "More specific regulations for additional special purpose PI assignments may deviate from generic PI assignment criteria." with: After <DATE OF PROPOSAL IMPLEMENTATION>, unless otherwise excepted, an End User may only have one PI assignment. Exceptions to this include, but are not limited to: - IXP PI assignments - Assignments made before the implementation of this protocol and not yet returned under 7.1.3 - During renumbering Other policies may make other exceptions to this general rule. ------------------------------ Any statements contained in this email are personal to the author and are not necessarily the statements of the company unless specifically stated. AS207960 Cyfyngedig, having a registered office at 13 Pen-y-lan Terrace, Caerdydd, Cymru, CF23 9EU, trading as Glauca Digital, is a company registered in Wales under № 12417574 <https://find-and-update.company-information.service.gov.uk/company/12417574>, LEI 875500FXNCJPAPF3PD10. ICO register №: ZA782876 <https://ico.org.uk/ESDWebPages/Entry/ZA782876>. UK VAT №: GB378323867. EU VAT №: EU372013983. Turkish VAT №: 0861333524. South Korean VAT №: 522-80-03080. AS207960 Ewrop OÜ, having a registered office at Lääne-Viru maakond, Tapa vald, Porkuni küla, Lossi tn 1, 46001, trading as Glauca Digital, is a company registered in Estonia under № 16755226. Estonian VAT №: EE102625532. Glauca Digital and the Glauca logo are registered trademarks in the UK, under № UK00003718474 and № UK00003718468, respectively. On Thu, 29 Aug 2024 at 12:42, Tobias Fiebig <tobias@fiebig.nl> wrote:
Moin,
The point of pain from the past was actually the phrasing in 2.6
I don't see the problematic phrasing in the old version of 2.6. Can you point it out please?
Ah, my mistake; Actually it was in 5.4.2 of the old text:
"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."
Which was interpreted to parse to:
Assignments # That are either
[larger than a /48 (shorter prefix)]
# Implicit Exclusive OR or
[additional assignments exceeding a total of a /48]
# If address usage requires larger network [must be based on address usage]
# Inclusive OR or
( # Different routing requirements exist [because different routing requirements exist]
# Implicit conditional; i.e., AND it is about # _additional_ assignments, not a shorter # prefix.
[for additional assignments.]
)
This means that the _only_ way to justify anything larger than a /48 for a single end-site (even considering 'large', i.e., L2 connected ones) can only be justified via address usage/addressing needs. Assuming a /64 per device, this would mean at least (2**16) + 1 devices (i had a corresponding ticket; See the AP-WG ML archives.)
The end-user will, in general, only hold one PI assignment covering their needs at a time.
Perhaps the policy could be reworded to make this clearer.
Yeah, we can see what can be changed textually; Do you have any suggestions?
With best regards, Tobias
Moin,
I would replace "More specific regulations for additional special purpose PI assignments may deviate from generic PI assignment criteria." with: After <DATE OF PROPOSAL IMPLEMENTATION>, unless otherwise excepted, an End User may only have one PI assignment. Exceptions to this include, but are not limited to: - IXP PI assignments - Assignments made before the implementation of this protocol and not yet returned under 7.1.3 - During renumbering Other policies may make other exceptions to this general rule.
This, sadly, has a lot of issues (which we (PO+me) partially stumbled through already (multiple times; Sorry again Angela. I really appreciate the time you spend on this.)) while revising the draft document for initial publication. - It now works on an explicit principle making a normative statement, while _also_ allowing generic exceptions (twice, actually). - It makes one specific exception, while missing, e.g., ANYCAST PI, opening the challenge of having to be exhaustive. - It requires a _general_ reevaluation of _all_ assignments prior to the policy becoming into effect; However, a user currently legitimately holding two PIs being totally happy with them should not have any changes forced upon them. Seeking explicit generality here would be, i fear, a source for more confusion and undesired side effects. But i'd be happy to hear other opinions. With best regards, Tobias
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/
Moin,
I agree with others that this changes too many things at once and might have unexpected consequences,
I would argue that this is not necessarily the essence of the prior discussion.
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.
While I do see the appeal in such an atomic approach, I would argue that the cross dependency of specific changes makes the presented set of changes the minimum consistent one. Furthermore, the step size in the examples provided is, indeed, extremely atomic, close to effectively grinding any change to a halt.
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.
It is. Yet, below, you argue against one such specific change which, in the past in the interpretation of the policy by the NCC, was indeed interpreted in an unexpected way.
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,
I would argue that, partially, that is based on an intentional reading of the policy proposal which I find myself partially challenged to purely attribute to confusing language. Please see more specific comments below.
while the clear outcome is making it easier to obtain larger than /48 assignments based on routing requirements instead of address usage.
This is indeed one of the stated purposes of the policy change.
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.
Aggregation of address assignment, not the GRT. Someone once said that the NCC is not the routing police.
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. See above; In that context, see for example Jori's message.
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.
This point mixes 'end site' with 'end user holding multiple end sites'; In fact, the proposed change effectively reinforces a /48 _per end site_.
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.
If these assignment holders qualify for a single larger assignment, they will currently already hold (or would be allowed to hold) one /48 per each of these end-sites. As such, there would not be a change in relation to the deaggregation of the GRT, with the difference of the database an assignment plan actually aggregating.
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). It is, because each /48 will be its own DB object.
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"?
While I agree that, in general, this information would be useful, it works on a selected premise of aggregating the GRT, not assigned space.
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? It remains more defined than current terminology. Furthermore, it is definitely clear what is _not_ the same geographical end-site.
- Allows /56 or longer to different entities without being considered a sub-assignment This, again, is a stated purpose, as a static use of, even, a static /128, to connect, e.g., a server to a network is--per the last impact assessment of the policy change that introduced the explicit permission to use addresses for connecting servers or appliances--is not permitted.
- "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.
Still, at the moment, this is not permitted by the policy. In fact, if you'd want to use one /48 per end-site for an infrastructure, even if both end-sites had the same routing policy, you would be forced to use two /48s that are _not_ in the same /47. Been there, done that, argued for weeks.
- "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.
Correct. Server in your rack, fine. PPPoE connection for an end-user: not fine.
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
Correct. Because otherwise you could argue that the CPE is owned by an ISP, and, hence, each customer of theirs would be a different end-site.
(is the device/CPE something you can touch or is this SDN-way?). I will leave this philosophical question out of scope.
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?
I would love to learn how you can create a 'different location' that is neither topologically not geographically different, without it being the same location.
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",
Yes, so it needs to be a link over which internet routing information is exchanged.
and /56 or longer to different entities. Is exchanging traffic and Internet routing information not what the Internet is?
While I am sure that some people actually speak iBGP between _all_ nodes in their network (I think Q runs a kubernetes cluster directly hooked into their iBGP), I am pretty sure not every link comes with a BGP session.
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?
Please provide quotes. At the moment, this reads a bit like a mix between 'stated text' and 'interpretation of text under specific premises';
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.
Again, I will leave philosophical points out of scope.
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.
How would two networks using only PI peer over a PNI?
I am not aware of any implicit need to use LL for interconnectivity, could this be clarified?
See RFC4291.
New 2.9 - Introduces yet another undefined term: the "topological location"
https://en.wikipedia.org/wiki/Network_topology
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.
Yes.
- Adds impossible to verify things such as L2s between End Sites. Trust me, this is L2.
Trust me, this is the reason why, for a PoP in Amsterdam, Duesseldorf, and Berlin each, where $nice_neighboring_transport_provider moves a vlan between Amsterdam and Dusseldorf, and Dusseldorf and Amsterdam, you are entitled to _one_ full /48, because all three pops form a single end-site due to the existing L2 connectivity. Please see my thread on requesting a /46 for reference. I.e.: "Is there L2 connectivity" is a metric _currently_ used by the NCC.
- 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.
Currently, applying reasoning clearly made in the context of PA assignments to PI leads to unintentional outcomes. PI and PA assignments are, necessarily, different. As such, they should be treated differently.
- 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.
Exactly. That is why this stops the NCC from doing that.
- 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.
Yes, and that is not so difficult: Me selling Internet access to _a_ customer, who then does their thing -
not ok.
Me running an open wifi / freifunk (not a single end-user in terms of entity) -> ok.
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.
Then again, it is being applied in the context of PI.
New 7.1 The very short, to the point, minimum assignment size of /48 is replaced by a very long and interpretable text.
Please see the APWG archives on a discussion with the NCC, where the NCC claims that this means that the smallest _prefix size_, i.e., least specific prefix, is a /48.
- Introduces a new term "special purpose PI assignment" that may deviate from generic PI assignment criteria
Yes, like, for example, IXP PI assignments, which we _already_ have, and which _already_ make provisions which are _incompatible_ with the PI assignment policy; Like: Assigning /64 PI. This change specifically canonicalizes what is already there.
- "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).
Yes, see above.
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). Database, GRT, Routing Police. See above.
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.
Yes, which is why L2 connectivity no longer matters.
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).
Funnily enough, this change was made during the preparation for publication of the policy proposal, when the PO raised the point that making the longest prefix of PI a /48 would collide with RIPE-451, and was then surprised that the /48 was--more or less--already in the old policy.
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.
Again, see above. Given your extensive commentary, I would deeply appreciate it, if--in case my counter arguments are in your opinion unconvincing--you could contribute text to approach the recognized underlying operational issues the proposal tries to address in a better way. With best regards, Tobias -- Dr.-Ing. Tobias Fiebig T +31 616 80 98 99 M tobias@fiebig.nl
Howdy, On 01.09.2024 01:06, Tobias Fiebig via address-policy-wg wrote:
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.
Aggregation of address assignment, not the GRT. Someone once said that the NCC is not the routing police.
I did not invent the 'routing police', multiple people use it, and it is meant as 'the NCC does not have the power to enforce routing decisions', not that they can't require aggregation. For the aggregation part I recommend reading ripe-399 'What is Aggregation?' and 'What is Deaggregation?'. If you plan on redefining the meaning of aggregation might as well start with that. If the purpose of the policy is to permit or encourage deaggregation, please state it clearly. Same as the intent of allowing networks similar to Freifunk to operate using PI, it might be in the discussions before however I cannot find this in the stated purposes.
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. See above; In that context, see for example Jori's message.
See Marco's message, he confirmed that the End Site can receive a larger assignment if the request justifies more /64s than what would fit in a /48, so this is not about aggregation at a single End Site.
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.
This point mixes 'end site' with 'end user holding multiple end sites'; In fact, the proposed change effectively reinforces a /48 _per end site_.
It does not mix anything, with the current policy each End Site can get a /48 (or more if justified). The fact that the NCC reserves up to a /46 for each /48 assigned allows for future growth of that End Site, just as the RFCs mentioned recommend. Could you point me to the paragraph reinforcing a /48 _per end site_?
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.
If these assignment holders qualify for a single larger assignment, they will currently already hold (or would be allowed to hold) one /48 per each of these end-sites. As such, there would not be a change in relation to the deaggregation of the GRT, with the difference of the database an assignment plan actually aggregating.
See Tore's messages about deaggregation. What would the benefits of this new 'DB Aggregation' be? Also keep in mind the 'one large inet6num and multiple route6: not matching the inet6num' problem that would be created.
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"?
While I agree that, in general, this information would be useful, it works on a selected premise of aggregating the GRT, not assigned space.
I would recommend working on that premise too, see above, ripe-399. Using some terms with different meaning to suit some goals is like speaking different languages.
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? It remains more defined than current terminology. Furthermore, it is definitely clear what is _not_ the same geographical end-site.
Current policy text is short and clear: - you can provide addresses (not prefixes) in order to let visitors connect to the assignment holder's network (wifi?) - you can connect a server or appliance (does not mention "static" addressing, but is that required? if my appliances are getting dynamic addresses they should not be allowed?) - you can also connect point-to-point with 3rd parties (that are not called 'ISPs', so could be ISPs, could be other End Users, could be anything). Proposed policy allows offering up to a /56 and limits point to point links to connect to 'other ISPs' instead of '3rd parties'.
- Allows /56 or longer to different entities without being considered a sub-assignment This, again, is a stated purpose, as a static use of, even, a static /128, to connect, e.g., a server to a network is--per the last impact assessment of the policy change that introduced the explicit permission to use addresses for connecting servers or appliances--is not permitted.
However, the current policy text allows 'connecting a server or appliance to an assignment holder's network and setting up point-to-point links with 3rd parties'. Perhaps not with a /56 (as that would be a sub-assignment), but you are saying it does not allow them at all.
- "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.
Still, at the moment, this is not permitted by the policy. In fact, if you'd want to use one /48 per end-site for an infrastructure, even if both end-sites had the same routing policy, you would be forced to use two /48s that are _not_ in the same /47. Been there, done that, argued for weeks.
If they are different End Sites how can they have the same routing policy? Please use the current definitions of terms such as 'Aggregation', 'End Site', or specify that you are using the redefined terms so we can speak the same language.
- "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.
Correct. Server in your rack, fine. PPPoE connection for an end-user: not fine.
I feel I'm creating a loop now, but: you say PPPoE is not ok, a CPE installed at different location for providing Internet is ok? (see below)
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
Correct. Because otherwise you could argue that the CPE is owned by an ISP, and, hence, each customer of theirs would be a different end-site.
I see nothing to argue here, providing Internet access at a different location is what an ISP does, installing/offering CPEs too. See above, providing Internet over PPPoE is not ok, providing Internet at a different location ok. Loopy.
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?
I would love to learn how you can create a 'different location' that is neither topologically not geographically different, without it being the same location.
I would love to learn that too, however, my comment was on the lines of 'why does it have to be specific geo/topo in one place and in the other place is ok to be generic?', sorry if it was not clear.
and /56 or longer to different entities. Is exchanging traffic and Internet routing information not what the Internet is?
While I am sure that some people actually speak iBGP between _all_ nodes in their network (I think Q runs a kubernetes cluster directly hooked into their iBGP), I am pretty sure not every link comes with a BGP session.
The proposed policy text mentions different entities. Unless you are referring to Q in the Star Trek way, running whatever protocols inside your cluster == your infrastructure so you would be allowed to use the whole /48. If you have multiple Q entities and assign them a /56 each that would be a sub-assignment under the current policy, no matter what protocol they use (i/eBGP, RIP, static, ...). Wikipedia reference: https://en.wikipedia.org/wiki/Q_(Star_Trek)
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?
Please provide quotes. At the moment, this reads a bit like a mix between 'stated text' and 'interpretation of text under specific premises';
Sure, here we go: - 'stated text' of Purpose for 2.6: "Explicitly prohibits using PI to connect remote End Sites of customers to the Internet, except for p2p links to other ISPs." Are the customers of an End User 'other ISPs'? Providing Internet at a different location and/or offering a CPE is not what an ISP does? - 'stated text' of proposed 2.9.2: "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." If it does not constitute an End Site of the assignment holder it must constitute an End Site of the 'single End User / Customer', right? But providing Internet to customers at different End Sites is prohibited according to the Purpose of the proposed 2.6.
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.
How would two networks using only PI peer over a PNI?
See current policy text of 2.6: '... and setting up point-to-point links with 3rd parties'.
I am not aware of any implicit need to use LL for interconnectivity, could this be clarified?
See RFC4291.
Could you be more specific? Which section/paragraph of that RFC implies LL for interconnectivity? If you really really want a PNI without providing ptp to your peer, you could do this: 2001:db8:a::/48 - PI End User 1 2001:db8:b::/48 - PI End User 2 PI E U 1 - 2001:db8:a::a/128 - static route to 2001:db8:b::b/128 over that interface PI E U 2 - 2001:db8:b::b/128 - static route to 2001:db8:a::a/128 over that interface Each End User uses only addresses from their /48. Happily set up eBGP and exchange the best routing information available. Or any other protocol.
- 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.
Currently, applying reasoning clearly made in the context of PA assignments to PI leads to unintentional outcomes. PI and PA assignments are, necessarily, different. As such, they should be treated differently.
Currently 4 out of 5 RIRs have very similar definitions of an End Site. APNIC and LACNIC are the most similar to the RIPENCC wording, ARIN has a shorter but similarly in meaning definition (more strict). AFRINIC does not define the term although they use it. It is not clear to me why there should be created a difference between PA and PI End Sites. Why should a PI End Site have special treatment over a PA End Site? Is this worth creating major differences in the policy compared to the other RIRs? Could you please explain this need better? The main difference between PA and PI addresses is who assigns it: the LIR or the NCC. In theory both are supposed to perform the same checks before assigning space, and with the same definition of an End Site the same prefix length would be assigned. Secondary difference would be that you can keep the PI when changing LIRs/ISPs.
- 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.
Yes, and that is not so difficult:
Me selling Internet access to _a_ customer, who then does their thing -
not ok.
Me running an open wifi / freifunk (not a single end-user in terms of entity) -> ok.
You running an open wifi at your End Site - more than ok, great. You deploying an infrastructure that is both geographically and topologically different from your End Site in order to provide wifi (even for free) means you are an ISP. I think this is the current interpretation of the policy and also the "problem" you are trying to fix. I see this as a feature, even if run by volunteers, even if I would get paid to use it, it is still an ISP providing Internet access to people. Don't get me wrong, Freifunk is a cool thing, from a technical point of view what they do is amazing with the mesh stuff, but this does not change the fact that they provide Internet access to people just like an ISP would. Best, Radu
* Angela Dall'Ara
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.
There's one thing I just don't quite get with this proposal. Maybe I am being dense, but hopefully someone can clarify it for me. The proposed text in 2.9 makes it clear that separate locations with different routing policies should be considered separate End Sites. Next, the proposed text in 7.1 makes it clear that having multiple End Sites qualifies for an assignment larger than /48. However, it states that this is done «to avoid fragmentation». But doesn't the fact that those separate End Sites are defined to have different routing policies make the fragmentation happen anyway? Reading between the lines it seems that the whole point of this change is to ensure that the separate End Sites can get their own /48 to advertise in a fragmented manner to the DFZ. From a technical standpoint that makes a lot of sense as the sites might have different IP transit providers and you need at least a /48 to get visibility in the global DFZ. That said, doesn't policy already allow for such End Sites with different routing policies to get their own PI /48? If so, isn't this part of the proposal trying to solve a non-existent problem? Another thing I find strange is the reference to layer-2 connectivity in 2.9 and 7.1.1. This seems oddly technology-specific to me. Is it the intention that two End Sites (with different routing policies) interconnected with an L2VPN should be treated differently than two End Sites (with different routing policies) interconnected with an L3VPN? Looks that way, but why? Tore
Hi Tore,
The proposed text in 2.9 makes it clear that separate locations with different routing policies should be considered separate End Sites. Next, the proposed text in 7.1 makes it clear that having multiple End Sites qualifies for an assignment larger than /48.
However, it states that this is done «to avoid fragmentation». But doesn't the fact that those separate End Sites are defined to have different routing policies make the fragmentation happen anyway?
In the global routing table: yes In ACLs and IPAM etc: no It all depends what you are working on :)
Another thing I find strange is the reference to layer-2 connectivity in 2.9 and 7.1.1. This seems oddly technology-specific to me. Is it the intention that two End Sites (with different routing policies) interconnected with an L2VPN should be treated differently than two End Sites (with different routing policies) interconnected with an L3VPN? Looks that way, but why?
IIRC this is about the history of treating multiple sites that are connected on layer-2 as a single end-site. As that has caused confusion in the past, the new text explicitly states that a layer-2 connection does not automatically mean “single end-site”. Cheers, Sander
Hello Tore, Hello Sander, Thank you sander for your reply; It already captures the core points well.
In the global routing table: yes In ACLs and IPAM etc: no
It all depends what you are working on :)
Also in the context of NCC IPAM, esp. given current reservation approaches.
IIRC this is about the history of treating multiple sites that are connected on layer-2 as a single end-site. As that has caused confusion in the past, the new text explicitly states that a layer-2 connection does not automatically mean “single end-site”.
This is also correct; In the past, there have been several cases where it was, for example, claimed that three end sites (Amsterdam, Dusseldorf, Berlin) are, effectively, a single end-site, because there is L2 connectivity (which, very likely, goes via an L2VPN anyway). To resolve that discussion/interpretation issue, the proposed changes makes this very much explicit; So, effectively, the change ensures that L2 and L3 VPN connected sites are treated the same, and no longer different. With best regards, Tobias
Hi Sander,
The proposed text in 2.9 makes it clear that separate locations with different routing policies should be considered separate End Sites. Next, the proposed text in 7.1 makes it clear that having multiple End Sites qualifies for an assignment larger than /48.
However, it states that this is done «to avoid fragmentation». But doesn't the fact that those separate End Sites are defined to have different routing policies make the fragmentation happen anyway? In the global routing table: yes In ACLs and IPAM etc: no
It all depends what you are working on :)
Yeah, ok, I can see that. Well, in an IPAM you'd normally want to track which prefix belongs at which site, so you'll need separate entries for each prefix anyway. You'd also get a few more inet6num objects in the database (but the same number of route6 objects), but disk is cheap. All in all it seems like the actual benefit of this part proposal is not too big and the benefits do not extend to the community at large (like limiting DFZ growth would). Another thing occurred to me though. With the current fee structure, an organisation with several sites would contribute €50 *per site* to to the RIPE NCC's budget. With this proposal, as I understand it, a huge organisation with 30000 sites could get a PI /33, advertise 30000 /48s into the DFZ, and all it'd cost them is just €50 per year. Good for the PI holder of course, but not so good for the community. It would certainly make economic sense for us as a public cloud provider to terminate our LIR membership and go for this new PI, since it explicitly allows hosting customer VMs and such (if it weren't for the fact that we were also dependent on IPv4). I wonder if this has been considered, as it is not being discussed in the proposal. I think I will wait for the impact analysis before I decide where I stand on this part of the proposal.
Another thing I find strange is the reference to layer-2 connectivity in 2.9 and 7.1.1. This seems oddly technology-specific to me. Is it the intention that two End Sites (with different routing policies) interconnected with an L2VPN should be treated differently than two End Sites (with different routing policies) interconnected with an L3VPN? Looks that way, but why? IIRC this is about the history of treating multiple sites that are connected on layer-2 as a single end-site. As that has caused confusion in the past, the new text explicitly states that a layer-2 connection does not automatically mean “single end-site”.
I wasn't aware of that history. Current policy does not mention «layer 2» at all, so I wonder where that came from. Are layer 2 connectivity (like L2VPNs) and layer 3 connectivity (like L3VPNs) treated differently today? Do we want that tomorrow, if so why? If it shouldn't matter, I'd prefer some kind of technology-agnostic term to be used here, like simply «connectivity». Tore
Hello Tore,
Yeah, ok, I can see that. Well, in an IPAM you'd normally want to track which prefix belongs at which site, so you'll need separate entries for each prefix anyway. You'd also get a few more inet6num objects in the database (but the same number of route6 objects), but disk is cheap. All in all it seems like the actual benefit of this part proposal is not too big and the benefits do not extend to the community at large (like limiting DFZ growth would).
Still, it does allow for more consistent hierarchical addressing plans, easier ACL setups (as mentioned by Sander), easier (controlled) growth of networks (keep in mind that, at the moment, at least the /46 of a /48 PI is left unassigned), reduces overhead in terms of small growth, etc.
Another thing occurred to me though. With the current fee structure, an organisation with several sites would contribute €50 *per site* to to the RIPE NCC's budget. With this proposal, as I understand it, a huge organisation with 30000 sites could get a PI /33, advertise 30000 /48s into the DFZ, and all it'd cost them is just €50 per year. Good for the PI holder of course, but not so good for the community.
First, the maximum size for PI is limited to a /36 (always smaller than the smallest allocation, at the nibble boundary). Also, iirc, at the moment charging is based on _complete assignments_. I.e., as I understand it, that _one_ assignment process for 8192 /48 for 8192 sites in _one_ process for _one_ customer would count as _one_ assignment, and hence only cost EUR75 _once_ per year. IIRC, I even saw somebody discussing the option of batching processes to be able to offer PI sponsoring cheaper/make more profit. However, besides that, the charging scheme is outside of scope for the assignment policy. It would be relatively easy to adjust charges for PI based on size, e.g. (numbers grabbed completely out of thin air and _ONLY_ as an example!): /48 .0625 * Annual LIR fee (for 2025 EUR 112.50) /44 .125 * Annual LIR fee (for 2025 EUR 225.00) /40 .25 * Annual LIR fee (for 2025 EUR 450.00) /36 .5 * Annual LIR fee (for 2025 EUR 900.00) That, again, would be a matter for the charging scheme task-force to consider.
It would certainly make economic sense for us as a public cloud provider to terminate our LIR membership and go for this new PI, since it explicitly allows hosting customer VMs and such (if it weren't for the fact that we were also dependent on IPv4). With caveats:
- There are no more specific objects, and if there might be in the future, i'd assume that they would be bound to have the same ORG-ID as the main assignment holder, being purely for documentary purposes. - The fee structure might change, see above, which is a task for another WG/the membership in general. - You will likely only get a /48 per end-site, up to a maximum of a /36 if you have more than 256 sites.
I wonder if this has been considered, as it is not being discussed in the proposal. I think I will wait for the impact analysis before I decide where I stand on this part of the proposal.
See above; I would argue that this specific part (connection to charging) is out of scope for the AP WG / a proposal here; But I _do_ think that there are some good ways to solve this. I will, hence, pick this point up for the arguments part of the next version.
I wasn't aware of that history. Current policy does not mention «layer 2» at all, so I wonder where that came from. Are layer 2 connectivity (like L2VPNs) and layer 3 connectivity (like L3VPNs) treated differently today? Do we want that tomorrow, if so why? If it shouldn't matter, I'd prefer some kind of technology-agnostic term to be used here, like simply «connectivity».
This is the result of policy interpretation by the NCC when applying the policy. I would be happy to change the term to 'any form of internal connectivity between two sites', pending that in the impact assessment the result would be the same, i.e., no longer merging two end-sites as soon as you have a VLAN tagged between them (or, even worse, directly a DF). With best regards, Tobias
Hello Tobias, Tore et. al, I'm glad to see some pain points such as 2.6 being updated. This has caused quite a bit of back-and-forth between me and the NCC when sponsoring PI assignments for End Users. Also a big fan of following nibble boundaries, will make domain object management and growth a lot easier. As Tobias mentioned, it would be nice if there was some kind of way to document in the RIPE DB more-specific use-cases of your PI (with the mentioned restriction making sense to me, to prevent sub-assignment), but I think this is currently out-of-scope for this proposal. Unfortunately, I do not have much more input, as most concerns and/or questions I would have had, have already been asked by others and answered by Tobias. :) @Tore: I currently hold 4x/48 PI, and I can confirm, these are charged "per ticket" and not per object. E.g: If you received 4x/48 PI in a single request from the NCC, you pay the PI fee *once* for those 4x/48PI. Lastly, I would like to mention I support the proposal and would like to see how things develop. Warm regards, Jori Vanneste On Thu, 29 Aug 2024 10:48:00 +0200 Tobias Fiebig via address-policy-wg <address-policy-wg@ripe.net> wrote:
Hello Tore,
Yeah, ok, I can see that. Well, in an IPAM you'd normally want to track which prefix belongs at which site, so you'll need separate entries for each prefix anyway. You'd also get a few more inet6num objects in the database (but the same number of route6 objects), but disk is cheap. All in all it seems like the actual benefit of this part proposal is not too big and the benefits do not extend to the community at large (like limiting DFZ growth would).
Still, it does allow for more consistent hierarchical addressing plans, easier ACL setups (as mentioned by Sander), easier (controlled) growth of networks (keep in mind that, at the moment, at least the /46 of a /48 PI is left unassigned), reduces overhead in terms of small growth, etc.
Another thing occurred to me though. With the current fee structure, an organisation with several sites would contribute €50 *per site* to to the RIPE NCC's budget. With this proposal, as I understand it, a huge organisation with 30000 sites could get a PI /33, advertise 30000 /48s into the DFZ, and all it'd cost them is just €50 per year. Good for the PI holder of course, but not so good for the community.
First, the maximum size for PI is limited to a /36 (always smaller than the smallest allocation, at the nibble boundary).
Also, iirc, at the moment charging is based on _complete assignments_. I.e., as I understand it, that _one_ assignment process for 8192 /48 for 8192 sites in _one_ process for _one_ customer would count as _one_ assignment, and hence only cost EUR75 _once_ per year. IIRC, I even saw somebody discussing the option of batching processes to be able to offer PI sponsoring cheaper/make more profit.
However, besides that, the charging scheme is outside of scope for the assignment policy. It would be relatively easy to adjust charges for PI based on size, e.g. (numbers grabbed completely out of thin air and _ONLY_ as an example!):
/48 .0625 * Annual LIR fee (for 2025 EUR 112.50) /44 .125 * Annual LIR fee (for 2025 EUR 225.00) /40 .25 * Annual LIR fee (for 2025 EUR 450.00) /36 .5 * Annual LIR fee (for 2025 EUR 900.00)
That, again, would be a matter for the charging scheme task-force to consider.
It would certainly make economic sense for us as a public cloud provider to terminate our LIR membership and go for this new PI, since it explicitly allows hosting customer VMs and such (if it weren't for the fact that we were also dependent on IPv4). With caveats:
- There are no more specific objects, and if there might be in the future, i'd assume that they would be bound to have the same ORG-ID as the main assignment holder, being purely for documentary purposes. - The fee structure might change, see above, which is a task for another WG/the membership in general. - You will likely only get a /48 per end-site, up to a maximum of a /36 if you have more than 256 sites.
I wonder if this has been considered, as it is not being discussed in the proposal. I think I will wait for the impact analysis before I decide where I stand on this part of the proposal.
See above; I would argue that this specific part (connection to charging) is out of scope for the AP WG / a proposal here; But I _do_ think that there are some good ways to solve this.
I will, hence, pick this point up for the arguments part of the next version.
I wasn't aware of that history. Current policy does not mention «layer 2» at all, so I wonder where that came from. Are layer 2 connectivity (like L2VPNs) and layer 3 connectivity (like L3VPNs) treated differently today? Do we want that tomorrow, if so why? If it shouldn't matter, I'd prefer some kind of technology-agnostic term to be used here, like simply «connectivity».
This is the result of policy interpretation by the NCC when applying the policy. I would be happy to change the term to 'any form of internal connectivity between two sites', pending that in the impact assessment the result would be the same, i.e., no longer merging two end-sites as soon as you have a VLAN tagged between them (or, even worse, directly a DF).
With best regards, Tobias ----- 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/
Hi Jori,
@Tore: I currently hold 4x/48 PI, and I can confirm, these are charged "per ticket" and not per object.
E.g: If you received 4x/48 PI in a single request from the NCC, you pay the PI fee *once* for those 4x/48PI.
Wow, that's surprising to hear. You learn something every day! I've already understood the word «assignment» in the charging scheme (e.g., «the separate charge of EUR 50 per independent Internet number resource assignment» from ripe-800) to refer to the actual *num object(s) in the database, not to the one-time action of issuing the assignment(s). To me it doesn't really make much sense to issue a recurring charge for a one-time action like that. Tore
Hi, On Thu, Aug 29, 2024 at 01:19:23PM +0200, Tore Anderson wrote:
I've already understood the word «assignment» in the charging scheme (e.g., «the separate charge of EUR 50 per independent Internet number resource assignment» from ripe-800) to refer to the actual *num object(s) in the database, not to the one-time action of issuing the assignment(s). To me it doesn't really make much sense to issue a recurring charge for a one-time action like that.
That was the original idea. "A PI holding end-user has his PI network which is charged once a year as a reminder that PI is not free, and as a minor incentive to return the network when no longer used". The intricacies with "one /44 for 15 sites = 1 or 16 charging units?" etc. came up over the years... so giving clear guidance to the NCC on what is to be considered "a chargeable assignment according to the charging scheme" is definitely a worthy goal. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Ingo Lalla, Karin Schuler, Sebastian Cler Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
Moin,
The intricacies with "one /44 for 15 sites = 1 or 16 charging units?" etc. came up over the years... so giving clear guidance to the NCC on what is to be considered "a chargeable assignment according to the charging scheme" is definitely a worthy goal.
While I generally agree, I am still not sure whether that should be part of the assignment policy, or a separate document. Along with that, I would also argue that a tiered approach tying PI prices relatively to the membership fee in some way might be a good way forward (as noted in the previous mail). In any case, the current proposal does not necessarily change the incentive structure, as it does not change that one /44 vs. 16 /48 from the same request would still only be charged once for EUR75/year under either version of the policy. So, I would argue that--while I generally agree that the incentive issue is certainly imperative to solve--it is not something to solve in the current iteration/change. With best regards, Tobias
Hi,
The intricacies with "one /44 for 15 sites = 1 or 16 charging units?" etc. came up over the years... so giving clear guidance to the NCC on what is to be considered "a chargeable assignment according to the charging scheme" is definitely a worthy goal.
While I generally agree, I am still not sure whether that should be part of the assignment policy, or a separate document.
I have to chime in here. Anything dictating charging scheme behaviour is out of scope for this working group. And I’m saying that with both APWG chair and RIPE NCC board experience in mind :) So, what I would suggest: - this working group shouldn’t define any charging related things in the policy text - however, the RIPE NCC board and staff do look at the rationale behind discussions and consensus in the WG - that rationale may be taken on board by the Charging Scheme Task Force 2024 - which may influence their output - which will be taken seriously by the RIPE NCC board - which may result in certain charging scheme proposals - on which the RIPE NCC membership then has to vote So there are many steps between consensus here in the working group and the final vote by the RIPE NCC members. The wishes of this working group may (and as an ex-WG-chair I’d say “should”, but it hasn’t always worked out that way) influence the votes by the members. The important thing then becomes Communication™. If this working group can clearly explain their reasoning, then the board can explain choices made regarding the charging scheme proposals based on that, which the members then can use as input when voting. But, as with many complex things in life: no guarantees or promises :) Cheers, Sander Disclaimer: I’m not formally speaking as a board member here. I am attempting to inform this working group on what my personal understanding and expectations are based on my own experience. I am aware that things are even more complex than I describe here, but I feel any further detail will only distract. I’m meandering enough as it is :D
Hi, On Thu, Aug 29, 2024 at 04:38:48PM +0200, Sander Steffann wrote:
The intricacies with "one /44 for 15 sites = 1 or 16 charging units?" etc. came up over the years... so giving clear guidance to the NCC on what is to be considered "a chargeable assignment according to the charging scheme" is definitely a worthy goal.
While I generally agree, I am still not sure whether that should be part of the assignment policy, or a separate document.
I have to chime in here. Anything dictating charging scheme behaviour is out of scope for this working group. And I???m saying that with both APWG chair and RIPE NCC board experience in mind :)
It is, but APWG *can* signal what we think is a reasonable way to cover costs and/or provide incentives the way we want them. Of course the NCC board and members decide, and sometimes this leads to big amount of frustration... but we (APWG) still shouldn't just say "we do not care" :-)
So, what I would suggest: - this working group shouldn???t define any charging related things in the policy text - however, the RIPE NCC board and staff do look at the rationale behind discussions and consensus in the WG - that rationale may be taken on board by the Charging Scheme Task Force 2024 - which may influence their output - which will be taken seriously by the RIPE NCC board - which may result in certain charging scheme proposals - on which the RIPE NCC membership then has to vote
Agree. We can't put hard numbers anywhere, we can just suggest what we think would be a good approach to achieve "some desired outcome", and give compelling reasoning for that ;-) Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Ingo Lalla, Karin Schuler, Sebastian Cler Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
Wow, that's surprising to hear. You learn something every day!
Very surprising indeed. The NCC mental gymnastics never cease to amaze. Perhaps someone from the NCC could chime in on why they've interpreted the charging scheme this way? ------------------------------ Any statements contained in this email are personal to the author and are not necessarily the statements of the company unless specifically stated. AS207960 Cyfyngedig, having a registered office at 13 Pen-y-lan Terrace, Caerdydd, Cymru, CF23 9EU, trading as Glauca Digital, is a company registered in Wales under № 12417574 <https://find-and-update.company-information.service.gov.uk/company/12417574>, LEI 875500FXNCJPAPF3PD10. ICO register №: ZA782876 <https://ico.org.uk/ESDWebPages/Entry/ZA782876>. UK VAT №: GB378323867. EU VAT №: EU372013983. Turkish VAT №: 0861333524. South Korean VAT №: 522-80-03080. AS207960 Ewrop OÜ, having a registered office at Lääne-Viru maakond, Tapa vald, Porkuni küla, Lossi tn 1, 46001, trading as Glauca Digital, is a company registered in Estonia under № 16755226. Estonian VAT №: EE102625532. Glauca Digital and the Glauca logo are registered trademarks in the UK, under № UK00003718474 and № UK00003718468, respectively. On Thu, 29 Aug 2024 at 13:20, Tore Anderson <tore@fud.no> wrote:
Hi Jori,
@Tore: I currently hold 4x/48 PI, and I can confirm, these are charged "per ticket" and not per object.
E.g: If you received 4x/48 PI in a single request from the NCC, you pay the PI fee *once* for those 4x/48PI.
Wow, that's surprising to hear. You learn something every day!
I've already understood the word «assignment» in the charging scheme (e.g., «the separate charge of EUR 50 per independent Internet number resource assignment» from ripe-800) to refer to the actual *num object(s) in the database, not to the one-time action of issuing the assignment(s). To me it doesn't really make much sense to issue a recurring charge for a one-time action like that.
Tore
----- To unsubscribe from this mailing list or change your subscription options, please visit: https://e.as207960.net/w4bdyj/eDAODsow4j8pMWf4 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://e.as207960.net/w4bdyj/QeRbZW5iVhNDz1q5
Hi Jori,
@Tore: I currently hold 4x/48 PI, and I can confirm, these are charged "per ticket" and not per object.
E.g: If you received 4x/48 PI in a single request from the NCC, you pay the PI fee *once* for those 4x/48PI.
Wow, that's surprising to hear. You learn something every day!
While I didn't know this, I'm not terribly surprised. The fee structure is probably done this way to promote the idea that this is an administrative fee to cover the administrative overhead related to registering and maintaining the entry's uniqueness, and *not* to spread the misconception that you "buy (or rent) address space from the RIPE NCC". Regards, - Håvard
Dear all, As already mentioned, the RIPE NCC Executive Board proposes the charging scheme and the membership votes on whether to approve it or not. So while policy and charging are independent of each other, the Board will of course try to propose charging schemes that comply with RIPE Policy while providing the RIPE NCC with the funding it needs in a financially responsible way. The annual charges for PI assignments were introduced in 2010 following approval of the relevant charging scheme at the General Meeting in October 2009. At that GM, the Board made clear that the charges for independent resources were introduced to implement RIPE Policy Proposal 2007-01 (current policy ripe-637 [1]). The Board also noted that the charges for PI assignments were not related to the amount of addresses but to the assignment itself, which could contain a small or larger amount of address space. The Charging Scheme Task Force report in 2012 [2] also recommended to the Board that PI assignments should continue to be charged per assignment rather than be based on the size of the assignment. The RIPE NCC has always charged an assignment for any that is made in a single day. The idea here is not to negatively affect anyone for a decision made by the RIPE NCC or for other factors that might result in them receiving multiple prefixes based on a single request. For example, if somebody asks for a /44 IPv6 PI (equals 16x /48) but only qualifies for 5 /48's - it wouldn't be fair to charge them five times more than for one single block. Similarly, if somebody transfers part of their IPv4 PI, maybe a /24 out of a /22, this will leave them with two prefixes (/23 and /24) and potentially a double charge. Of course, guidance on how we interpret policy is always welcome from the community. It is also worth noting that handling End Users for PI assignments and ASNs is an ongoing workload when it comes to keeping the Registry up to date and also with regards to sanctions. Kind regards, Marco Schmidt Manager Registration Services RIPE NCC [1] https://www.ripe.net/publications/docs/ripe-637/ [2] https://www.ripe.net/media/documents/Final_Report_of_the_Charging_Scheme_Tas... On 29/08/2024 13:19, Tore Anderson wrote:
Hi Jori,
@Tore: I currently hold 4x/48 PI, and I can confirm, these are charged "per ticket" and not per object.
E.g: If you received 4x/48 PI in a single request from the NCC, you pay the PI fee *once* for those 4x/48PI.
Wow, that's surprising to hear. You learn something every day!
I've already understood the word «assignment» in the charging scheme (e.g., «the separate charge of EUR 50 per independent Internet number resource assignment» from ripe-800) to refer to the actual *num object(s) in the database, not to the one-time action of issuing the assignment(s). To me it doesn't really make much sense to issue a recurring charge for a one-time action like that.
Tore
----- 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/
* Marco Schmidt
The RIPE NCC has always charged an assignment for any that is made in a single day. The idea here is not to negatively affect anyone for a decision made by the RIPE NCC or for other factors that might result in them receiving multiple prefixes based on a single request.
For example, if somebody asks for a /44 IPv6 PI (equals 16x /48) but only qualifies for 5 /48's - it wouldn't be fair to charge them five times more than for one single block. Similarly, if somebody transfers part of their IPv4 PI, maybe a /24 out of a /22, this will leave them with two prefixes (/23 and /24) and potentially a double charge. Of course, guidance on how we interpret policy is always welcome from the community.
Hi Marco, So let me see if I understand correctly: Assume organisation A requested and received, say, three separate /48 assignments to be used in three different sites on the same day / in the same ticket, then they will only pay a single PI fee annually in perpetuity? At the same time, assume organisation B also requested and received three separate /48s to be used in three different sites, but did so in three different tickets submitted over three consecutive days, then they will need to pay three PI fees annually in perpetuity? To be clear I am not talking about a single /46 assignment for a single gigantic site (or collection of sites with uniform routing requirements) here, but three distinct /48s given to be used in different sites with different routing requirements.
It is also worth noting that handling End Users for PI assignments and ASNs is an ongoing workload when it comes to keeping the Registry up to date and also with regards to sanctions.
Certainly, and I bet that is one of the reasons for having an annual fee in the first place. However I do not see how this could explain the different treatment between organisation A and B above. I could see the rationale for giving A a one-time discount on the act of issuing the PI prefixes themselves (assuming there is a one-time charge for that), but I don't think I can see any reason to give organisation A a discount on the yearly recurring fees in perpetuity. The on-going maintenance for A and B's prefixes in the years following their issuance should after all be identical, and both A and B ought to have the same economic incentives to return any prefixes that fall into disuse. Tore
Hello Tore, Radu and all, Tore’s understanding of the two scenarios is correct. The main difference is that in the first scenario, organisation A submits a single request, allowing us to perform the entire evaluation, including all necessary due diligence checks, in one go. In the second scenario, organisation B would send us three separate requests, requiring us to perform due diligence and evaluations three times. While your hypothetical scenario suggests the requests might arrive on three consecutive days, in reality, they typically come in more sporadically. But regardless of the time between submissions, all checks will need to be performed for each request. Additionally, in the first scenario, the request might initially be for a /46. After our evaluation, we would need to explain why several /48 assignments will be issued instead, which is one of the issues this policy proposal aims to address. As for your comments on the yearly recurring fee, I believe this topic is less related to this policy proposal and more relevant to the ongoing work of the Charging Scheme Task Force, which aims to define the principles of a future Charging Scheme. The discussions on this proposal have been brought to the attention of the task force, and their work will be communicated to the membership as it progresses. Regarding Radu’s questions about the numbers, I can clarify that all requests for multiple /48s are for different end sites of the same organisation. If a request would justify the need for more /64 subnets at a single end site than could fit in one /48, the RIPE NCC would issue a single prefix that provides sufficient space for that end site. I hope this answers your questions. Kind regards, Marco Schmidt Manager Registration Services RIPE NCC On 02/09/2024 09:28, Tore Anderson wrote:
* Marco Schmidt
The RIPE NCC has always charged an assignment for any that is made in a single day. The idea here is not to negatively affect anyone for a decision made by the RIPE NCC or for other factors that might result in them receiving multiple prefixes based on a single request.
For example, if somebody asks for a /44 IPv6 PI (equals 16x /48) but only qualifies for 5 /48's - it wouldn't be fair to charge them five times more than for one single block. Similarly, if somebody transfers part of their IPv4 PI, maybe a /24 out of a /22, this will leave them with two prefixes (/23 and /24) and potentially a double charge. Of course, guidance on how we interpret policy is always welcome from the community.
Hi Marco,
So let me see if I understand correctly:
Assume organisation A requested and received, say, three separate /48 assignments to be used in three different sites on the same day / in the same ticket, then they will only pay a single PI fee annually in perpetuity?
At the same time, assume organisation B also requested and received three separate /48s to be used in three different sites, but did so in three different tickets submitted over three consecutive days, then they will need to pay three PI fees annually in perpetuity?
To be clear I am not talking about a single /46 assignment for a single gigantic site (or collection of sites with uniform routing requirements) here, but three distinct /48s given to be used in different sites with different routing requirements.
It is also worth noting that handling End Users for PI assignments and ASNs is an ongoing workload when it comes to keeping the Registry up to date and also with regards to sanctions.
Certainly, and I bet that is one of the reasons for having an annual fee in the first place. However I do not see how this could explain the different treatment between organisation A and B above.
I could see the rationale for giving A a one-time discount on the act of issuing the PI prefixes themselves (assuming there is a one-time charge for that), but I don't think I can see any reason to give organisation A a discount on the yearly recurring fees in perpetuity. The on-going maintenance for A and B's prefixes in the years following their issuance should after all be identical, and both A and B ought to have the same economic incentives to return any prefixes that fall into disuse.
Tore
On 02.09.2024 15:19, Marco Schmidt wrote:
Regarding Radu’s questions about the numbers, I can clarify that all requests for multiple /48s are for different end sites of the same organisation. If a request would justify the need for more /64 subnets at a single end site than could fit in one /48, the RIPE NCC would issue a single prefix that provides sufficient space for that end site.
Thank you, Marco, I was suspecting it is that way since the current policy has no max limit just minimum size of /48. So, this adds to the multiple definitions of the same terms argument, aggregation would happen in the database not in the routing tables. I see no benefit in that, they are deaggregated now, they would be deaggregated then, it is better to have them documented as separate End Sites to reflect that. Radu
Hi, On Thu, Aug 29, 2024 at 10:48:00AM +0200, Tobias Fiebig via address-policy-wg wrote:
However, besides that, the charging scheme is outside of scope for the assignment policy.
It is, and it is not. What we (APWG) do has effects, and the guidelines we give are usually considered by the members when doing charging scheme. So we need to be careful with the incentives we signal. (I have not yet digested the policy proposal completely - it's quite a bit of changes at the same time, some of them possibly having side effects as Tore pointed out) Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Ingo Lalla, Karin Schuler, Sebastian Cler Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
Dear Address Policy WG, We are extending the Discussion Phase for 2024-01 (Revised IPv6 PI Assignment Policy) until 22 November 2024. Discussion on this issue will continue on this mailing list and at RIPE 89 in Prague. Kind regards, 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/
Hi, On Tue, Sep 17, 2024 at 01:23:00AM -0700, Leo Vegoda wrote:
We are extending the Discussion Phase for 2024-01 (Revised IPv6 PI Assignment Policy) until 22 November 2024.
So. Apologies for taking until the very last moment to send my full feedback. It *is* a long proposal, and has a long list of changes, some of them look like "intentional" and some of them might or might not be "unintended consequences". Part of the problem is that it mixes intentional changes (Nibbles and Aggregation) with clarification, and at that, adds lots of text which do not serve the clarification purpose. This makes it very hard to come to a clear statement of support or objection (short summary to save you a long read: I do object to the proposal in this form). I do support the goal of clarifying the PI use-cases, and I do support the intended "newly permitted use cases". I am a bit sceptical on the nibbles, and I disagree with the goal of "aggregation in the database" (the DB does not care). This has side effects, which might or might not be intentional - as proposed, it does make IPv6 PI a lot less attractive for coroporate use ("we have these 15 locations all over germany, each using an IPv6 /48 PI, now we open two new locations, ask for 2x extra /48 PI, and have to renumber all the other 15, really?"). So if we want this, it should be very clear that this is a desirable outcome, and should be stated as such in the rationale. I also disagree with the rationale given that "aggregated assignment from the NCC" will do anything useful for *routing table* size - it's PI, after all, and the implied intent of requesting a separate /48 for each location is that "each location is independent", so I do not see why these would then be announced as a, say, /44. So, going through the proposal in detail Section 2.6 My understanding is that this is what will address one of the more immediate problems, namely, clear guidance on what can be done with PI space and not. This takes into account recent developments in IPv6 technology (DHCP PD to devices). I support this. The wording of the new paragraph 3 ((sub-)assignments within the same organization) is what I'd consider "too much text", though - "within your organization" should not need explicit spelling out, as that's always the purpose of assignments "use within the receiving org". Maybe reword to make the intent more clear - e.g. "Providing Internet connectivity to off-site entities using IPv6 PI is strictly disallowed". (If written that way, one could possibly even reduce paragraph 2 + 3 to a single thing "Usage is only permitted within the same end site, but not restricted to equipment owned by the PI holder. Using IPv6 PI for p2p links to other entities is permitted, as long as the purpose is not sole Internet transit using PI space"). Section 2.9 This is, effectively, duplicating the definition of "end site", once for assignments out of PA space, and once for PI space. This is one of the points I am unhappy with. "End site" *should* be a definition that is applicable to both PI and PA assignments - and I agree that it might have different strings attached ("for the purpose of PA assignment, end sites are expected to use transit connectivity and be aggregated (and so on)" - though the aggregation & transit part is not enforced, and sufficient deaggregation garbage in the GRT is proof of that... Maybe we should kick "end site" completely, as it has never been really well defined (we inherited this from IETF, and they have no good definition either). Besides this more generic unhappiness with the proposed new text, there is also inherent inconsistencies - it says "... and has a different routing policy...", while other parts of the proposal aim for aggregation. Now what? ;-) Also, please get rid of "Layer 2". This is too specific, and at the same time, totally unclear - "so if I have a dark fiber, which is Layer 1, this is then not considered a Layer 2 connection"? Or "I buy a routed interconnection service (L3 VPN) to interconnect my sites transparently, this is fine, then"? I can see what this is aiming for ("tightly coupled sites, effectively forming a joint network") - but "a network connection between two End Sites does not make them one..." should do the job. One thing that is new here (and not just clarification) is the requirement that PI receiving end sites must be "in the NCC service region". I just wanted to point this out, which might cause annoyance for entities that have 5 offices in the NCC service region and 1 in the ARIN region - and thus would have to deal with two LIRs now. Is that what we *want*? If yes, it should be clearly stated. Section 5.4 This basically clarifies that these guidelines only apply to IPv6 PA assignments - which is a useful clarification, given that IPv6 PI has its own set of rules (which might be seen as contradictionary). This is a good and useful change :-) Section 7.1 This is lots of text... part of it is clarification of the original intent (new 7.1), part of it is new (7.1.1 "Nibbles", and 7.1.2 "increasing the aggregated PI block" and 7.1.3). In the new 7.1, I'm mostly fine with the new text, though I'd not bother to spend text on "special purpose PI" in *here* - the whole point of "special purpose" is "not the standard thing", so defining rules for those in the relevant documents should be just fine (and less text). On the nibbles in 7.1.1, I do not agree with the argument "for aggregation", neither routing wise nor registry wise. PI, by the very definition of "independent end sites with independent routing policy", is not expected to show up in an aggregated way - so it's not clear what this is trying to achive. Also, as written, this will create pain later to IPv6 PI holders - so, you have a company that has 4 different branches, with different offices and all, and decide to number them with IPv6 PI, a /48 each. Now you sell off one of these branches (because that's what businesses do) - according to the new 7.1.1, they would not be able to take their PI space with them. Is that intended? I won't object to it ("it makes PI less attractive"), but it should state so, very clearly. 7.1.2 has the a similar consequence - if an enterprise has a /44 for 15 "branch sites" today, and wants to open 2 extra locations somewhere, they would qualify for a /40, but if this is not available, all 15 existing sites would have to renumber, which is quite a detriment to "deploy IPv6 in these 2 new locations". Is this intended? 7.1.3 has the same problem. So, I do not care much about nibbles either way (7.1.1) but I do care about incentivizing networks to use IPv6 - and the implied threat here "if you grow in number of locations, there will be a sudden jump cost for your IPv6 deployment" is not a message we should send. Offering "well, the renumbering period can basically be stretched forever if you say 'please' every 12 month" will not cause less work for the NCC either... The argument "PI networks are relatively small, so renumbering is easier" is, uh, not something I'd sign. After all a /48 has 65000 subnets in it... so you can easily number a fairly large campus with *lots* of subnets and an even higher amount of machines with a single IPv6 PI network. So this might be a valid point for an enthusiast deployment ("personal ASN") with a few subnets and a few tens of machines, but the policy needs to work for all kinds of PI holders. What I am missing in the whole 7.1 discussion is how the NCC is expected to evaluate the number of "things" for application of the charging scheme - so is the intent to permit arbitrary numbers of PI assignments (up to a /36 in total = 4096 /48s), counted as "one PI", being charged just once? If yes, this would be something I'd also oppose - the "one fee *per unit* per year" charging was introduced to make PI somewhat less attractive, and incentivize returning of resources no longer needed. Given that each PI prefix in the global table has a cost to everyone, this is a principle we should stick to. (Yes, PA deaggregations exist as well, but this is not a justification for anything). For these reasons, I do not support the proposal "as written" today. I would suggest to split off the "what is allowed and what not" clarification into a smaller proposal, which would solves a clear problem (as Benedikt Neuffer has stated) and is likely to move ahead quicker, and reconsider the goals and consequences of the aggregation approach separately. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Ingo Lalla, Karin Schuler, Sebastian Cler Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
participants (12)
-
Angela Dall'Ara -
Gert Doering -
Havard Eidnes -
Jan Zorz - Go6 -
Jori Vanneste -
Leo Vegoda -
Marco Schmidt -
Q Misell -
Radu Anghel -
Sander Steffann -
Tobias Fiebig -
Tore Anderson