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