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

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

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

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

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

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 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, 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

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

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

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/

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

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