From jlauwers at a2b-internet.com Sat May 14 14:47:11 2022 From: jlauwers at a2b-internet.com (Jeroen Lauwers) Date: Sat, 14 May 2022 12:47:11 +0000 Subject: [address-policy-wg] IPv4 PA assignments policy change draft proposal Message-ID: <79D5B2F3-DA59-4B30-8C8F-321097D3C729@a2b-internet.com> Dear community, My name is Jeroen and I am new to the community. Ripe 84 is gonna be for me the first in-person Ripe meeting. I thought it would be nice as a newcomer to contribute something to the Ripe Community. In consultation with some of the chairs, we decided I could try to pick up the recommendation from the RIPE Database Requirements Task Force. Last November the DBTF recommended changing the address policy for IPv4 PA assignments (for own usage) from mandatory to recommended. Before I would send it as an official proposal to the RIPE NCC I would like to share it with the community to see what they think about it. I also would give a short presentation about it on RIPE 84 Where there would be space for discussion and feedback. You can find the draft version down in this mail. Feel free to reach me. Kind regards, Jeroen Lauwers #### Policy Draft Proposal #### Remove mandatory IPv4 PA Self assignment registration in the RIPE Database. Number: Author: Jeroen Lauwers jlauwers at a2b-internet.com A2B Internet Proposal Version: Submission Date: Suggested RIPE WG: Address Policy Proposal Type: Modification Policy Term: Indefinite Summary of Proposal In its final report, the RIPE Database Requirements Task Force (DBTF) recommended dropping IPv4 PA assignment(s) as a policy requirement [ 1 ]. This recommendation was motivated by the fact that existing LIRs are no longer eligible to request additional IPv4 prefixes from the RIPE NCC. This partially obsoletes the requirement for LIRs to document the assignment of used/reserved prefixes in the RIPE Database. This proposal aims to change the policy on assigned IPv4 PA space from ?must" to "may", which will address the issue of unnecessary registration and verification of certain prefixes for LIRs and the RIPE NCC. However, it would still be possible (and recommended) for LIRs to register PA assignments. [1] https://www.ripe.net/publications/docs/ripe-767#612 Policy 1.0 Introduction In the past, LIRs could request a new IPv4 prefix when their current pool was sufficiently used. However, since the RIPE NCC started to run out of IPv4, LIRs with existing IPv4 prefixes have not been eligible to receive additional IPv4 prefixes from the RIPE NCC. This resulted in unnecessary efforts by LIRs to register IPv4 prefixes and by the RIPE NCC to ensure that LIRs complied with the policy. This has also led to inconsistencies in the RIPE Database, as some resource holders registered more information than necessary, while many others did not make any PA assignments. The DBTF reported that in May 2021, there were 16,232 PA allocations without any child PA assignments and 9,986 LIRs held PA allocations containing no PA assignments. The current policy states that you must register a PA assignment for each prefix that an LIR uses. If this specific policy were changed from ?must? to ?may? for IPv4 PA assignments, the RIPE NCC would not need to spend resources on enforcing compliance with LIRs that have not followed this policy. This policy change would also serve the goal to keep the database limited to what is needed. However, it would still be recommended and possible to register IPv4 PA assignments in the RIPE Database. Also, LIRs would still be obligated to make assignments in the database when they want to sub-allocate or partition part of their IPv4 resources to another entity (sub-allocated PA/assignments). 2.0 Policy Text Current policy text [ 2 ] 4.0 Registration Requirements All assignments and allocations must be registered in the RIPE Database. This is necessary to ensure uniqueness and to support network operations. Only allocations and assignments registered in the RIPE Database are considered valid. Registration of objects in the database is the final step in making an allocation or assignment. Registration data (range, contact information, status, etc.) must be correct at all times (i.e. they have to be maintained). New Policy Text 4.0 Registration Requirements Allocations and assignments to third parties must be registered in the RIPE Database to be considered valid. For IPv4 PA assignments used for the LIR's own network infrastructure, registration is recommended but not mandatory. This is necessary to ensure uniqueness and to support network operations. Registration of objects in the database is the final step in making an allocation or assignment. Registration data (range, contact information, status, etc.) which filled in the database, must be correct at all times. [ 2 ] https://www.ripe.net/publications/docs/ripe-733#4 3.0 What about legacy space? As the RIPE NCC does not audit RIPE NCC members on their legacy space or how they use it, this policy change does not have an impact on legacy space or legacy space holders. 4.0 Attribution This document was developed by the RIPE community, and more specifically by Jeroen Lauwers, based on the findings of the RIPE Database Requirements Task Force. Rationale a. Arguments supporting the proposal ? One of the main reasons for registering IPv4 PA assignments was that LIRs could show their use of IPv4 and thus justify an additional IPv4 allocation from the RIPE NCC. However, this requirement has become obsolete since the IPv4 run-out. ? The application of IPv4 assignment registration policies in the RIPE Database is inconsistent. Some resource holders flood the database with tiny assignments (e.g. assignments for individual IP addresses), while many others do not register any assignments. ? Resource holders of a /24 allocation are required to create at least two assignments (/25 or smaller). ? This is in line with the data consistency and data minimization principles (as defined in the DBTF report): ? Data stored in the RIPE Database should be adequate, relevant, and limited to only what is necessary. ? It is recommended that resource registration requirements are applied consistently. ? More flexibility b. Arguments opposing the proposal ? An exception to the main rule does not make the overall policy more understandable. ? It is questionable whether other arguments for public tracking of the use of designated prefixes are weak enough to move from ?must? to ?may?. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gert at space.net Sat May 14 21:46:17 2022 From: gert at space.net (Gert Doering) Date: Sat, 14 May 2022 21:46:17 +0200 Subject: [address-policy-wg] IPv6 Policy Musings... Message-ID: Dear Working Group, I announced too many weeks ago that a small group was looking into the IPv6 policy, as it is today, why it is what it is, and whether the underlying assumptions that the policy is based on are still valid. After taking way too long (apologies - lots of good excuses, but this really shouldn't have dragged so long), I present you document with a very personal view on the IPv6 address policy, coming from me, Kurt Kayser and Sander Steffan (.txt and .pdf). This is not a task force document, this is not a formal WG document, and this is not an official RIPE document (though it might make a labs article). It is intended as a personal look at 24-odd years of IPv6 policy... and to spur discussion and further work on some areas that feel "in the rough". We'll present about this next week, picking some points as starting points for "shall we do something here? if yes, what? and who?" - but this is not about *me*, but about the commounity - *you*. Anyone is free and welcome to start a discussion and work on aspects we brought up - or on other aspects. Gert Doering -- long-time IPv6 policy geek -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- ???Preamble At RIPE83, the new APWG chairs suggested an overhaul of the IPv6 address policy - both policy text and policy itself, if needed. Some WG members volunteered to look into the part ???why is the current policy the way it is? Are the fundamental motivations still valid????... and this is a starting document for further discussions in the WG. This document is not a formal WG document, nor a product of a formal task force, but a personal view of the authors. Authors Gert D??ring, Kurt Kayser, Sander Steffann Scope We have focussed exclusively on IPv6 policy. This does not mean that policies about other resources, such as ASNs, won???t benefit from a closer look. But that is out of scope for this document. Underlying assumptions and motivations The following underlying assumptions, goals and drivers went into the IPv6 policy, as it is now - not commenting on the merits of either point here. Discussion follows, grouped in a somewhat topical way, in the next sessions. * It should be easy to get IPv6 address space. * RIPE IPv6 address policy should encourage IPv6 rollout, not get in the way. * Aggregation is very important, both inside an ISP network and for the global routing system * Conservation of IPv6 address space is a desirable criteria, but at the same time it is acknowledged that the IPv6 address space is very large, so allocation and assignments can be more liberal (???wastive???) than for IPv4 * Implementation of allocation and assignment policies should be easy, and require less paperwork and bureaucracy than for IPv4 * Use of N:1 NAT (ISPs assigning single IPv6 addresses to customers) is seen as undesirable * ???Special Networks??? exist that need stable IPv6 addresses which must not be tied to any particular uplink provider - namely, Anycast root DNS servers and IXP exchange fabrics (some need to be seen in the global routing system, others just need to be unique) * ???Renumbering networks is hard??? * ???Multihoming needs to be done with BGP??? (due to lack of widely accepted IETF alternatives) * IETF failed to deliver on ???new??? multihoming solutions, so a certain - limited - number of companies exist that need address space not tied to a specific upstream provider, but can be announced over multiple providers or taken from upstream A to upstream B when changing contracts. Evaluation Looking into each of these - partially conflicting - goals and assumptions in more detail: ???Simplicity, encouragement, aggregation, discourage N:1 NAT??? The end result of forming policy for these goals is: * ISPs can give end users a whole network block, up to a /48 per end site, without needing justifications (generally a /56 is recommended for SoHo end users, which is still 256 subnets of IETF-recommended size /64) - and most ISPs that provide IPv6 connectivity to end users seem to assign a /56, so the policy works. * Unlike IPv4, end customers are not encouraged to use NAT to work around address shortage, and also do not need to come back regularly because they need more addresses due to network growth. * RIPE LIRs can get a /29 address block from the RIPE NCC without needing any justification, so receive sufficient address space for 0.5 Million /48 assignments, or about 134 Million /56 assignments. Less, if internal aggregation is needed, but still sufficient for all but the largest service providers. * Most RIPE LIRs will not come back to the RIPE NCC to ask for more address space for a long time - or not at all. * If a RIPE LIR needs more than a /29, the need for internal network aggregation is taken into account when judging allocation size based on number of /56s needed (numerically, the algorithm used is ???HD ratio???) Most general assumptions leading there are still valid and the existing IPv6 policy seems to reasonably balance these needs. Especially the ???easy to operate, little bureaucracy, encourage IPv6 usage??? part is still important. Items under discussion: * 2.7 Utilization & 2.8 HD-Ratio are seen as ???too complicated??? * the wording (???bits to the left of the efficiency measurement unit???) could be less scientific, and easier to understand * it does take into account that ???larger networks with multiple levels of aggregations??? can not be as efficient as ???smaller networks???, so there is a mathematical justification for doing so, and not just asking for ???10% utilization??? - but are we overdoing it, for the common cases? * 5.1.2 for ???allocations larger than a /29???, and 5.2.1 ???subsequent allocation criteria??? - it is (sometimes) very hard to bring the necessary documentation * especially the bump ???no documentation for /29??? to ???full documentation for /28??? is steep(!). * Some cases are easy, like ???traditional ISP networks???, where a LIR can just count customers, POPs, etc., and document their network aggregation hierarchy. * For other large networks, more situated in the enterprise or government arena, it is considered a huge effort to prepare this detailed level of documentation. * increasing the general allocation size (???a /24 for everybody???) would not solve the problem for very large networks, and needlessly use more address space for ???smaller LIRs??? * 5.7 ???Existing IPv6 address holders??? is seen as contradicting 5.2.1 - does a LIR need to bring documentation for an extension of its address allocation, or not? (Clarification in 5.7 that this refers to LIRs having been allocated a smaller-than-usual network, i.e. a /32 or /35, should help reducing the confusion) * 4.2 Routability is not guaranteed, but there is little guidance on routing aggregation in the address policy (currently 3.4: ???should be distributed in a hierarchical manner???) - this is a situation outside the direct responsibility of address policy, but if we could give advice here, or point to a BCOP document, this would be helpful for newcomers that are looking for guidance on commonly accepted levels of deaggregation, vs. what could be called ???network vandalism???. * Unbounded deaggregation of LIR PA blocks (/29s) into ???more specifics announced by other entities??? might create lots of demand for AS numbers as well. * 4.4 ???Consideration of IPv4 Infrastructure??? - is this still a relevant criteria? Does it create an unfair situation for ???old networks that have lots of IPv4??? vs. ???new networks that have great plans, but no v4 to back their numbers???? Is it just moot and should go? ???Special Networks??? The needs of IXP fabrics (unique, not tied to any particular ISP, possibly not even routed) and anycast root DNS servers (unique, tied to root DNS instance and not to any particular operator) have not changed. With the general availability of IPv6 PI address space, it is unclear whether these special-case blocks are still needed or whether ???plain??? IPv6 PI could serve the needs. ???Renumbering, Multihoming, Provider-Independence??? For non-trivial networks, the whole aspects of ???renumbering on ISP change??? and also ???multihoming to multiple different providers??? still does not have good solutions in IETF. Existing solutions are ???use BGP routing and multihoming??? - which has obvious scalability limitations in regards to the global routing table - or ???use IPv6 NAT/Prefix translation??? - which has implications on end-to-end address transparency. Solving these is outside the RIPE APWG???s scope. If we acknowledge that the requirements for ???BGP based multihoming??? for a certain subset of networks exist, the consequences are ???owners of such networks need to have portable address space???. With the current address policy, LIRs can use a PA /29 for that (splitting up the /29 among multiple independent locations, if needed), while non-LIR end users can receive IPv6 PI space, with a /48 per end site, non-aggregatable. Some problems in this space are * routing table size (global impact) * yearly recurring costs for address space holders (IPv6 PI is cheaper than a full RIPE NCC membership) * discouraging IPv6 PI use conflicts with encouraging IPv6 deployment * aggregability of multiple IPv6 PI assignments to PI holders that have multiple independent end sites (e.g. 5 sites = 5x /48, not 1x /45) * IPv6 PI assignment to LIRs holding IPv6 PA is something the policy permits (7.2), but only by demonstrating a ???unique routing requirement???, the interpretation of which can create quite a bit of friction between LIRs and the NCC registration services. Transfer Policy and Stockpiling IPv6 address blocks can be transferred under the ???normal??? Transfer Policy (RIPE-682), just like IPv4 address blocks or AS numbers. This is not something intrinsic to IPv6 needs, but came out of the desire to have a unified Transfer Policy for all number resources managed by the RIPE NCC. That said, there are legitimate business cases for transfers of IPv6 blocks, like mergers and acquisitions, and having identical policies for all resource types makes this much easier for all parties involved. We have observed that some entities have acquired multiple /29s, in a few cases up to ???over 50??? /29s. This is not exactly the intended outcome, but we consider this as not critical yet (50 /29s are about a /22 worth of total space, of which there are many). The common assumption is that this is a side effect of certain actors opening multiple LIRs to collect multiple IPv4 /22 address blocks, and then merging the LIRs with their v4 and v6 space - so the amount of /29s involved should become somewhat bounded. Monitoring of future developments is still seen as necessary. Recommendations: items where revisiting policy might be worth considering (not calling this ???Conclusions??? as we want the work to start here, not to end) * simplify language * simplify requirements for /28, /27, /26 ??? allocations - explicit numbers, not HD ratio, and maybe start with ???less drastic??? documentation requirements for ???just +1 bit???? * change default allocation size? (4.3) * revisit ???special case??? assignments for IXP fabrics and root DNS operators (6.) <-> loosen up general IPv6 PI policy (for LIRs!) or keep special cases? * possibly fold IPv6 for IXP policy into main IPv6 policy document (https://www.ripe.net/publications/docs/ripe-451) * revisit IPv6 PI (7.x) * cost * aggregability * multihoming options * criteria for assignment * revisit aggregation requirements and expectations (BCOP) -------------- next part -------------- A non-text attachment was scrubbed... Name: IPv6 Address Policy Musings.pdf Type: application/pdf Size: 81581 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From gert at space.net Sat May 14 22:42:13 2022 From: gert at space.net (Gert Doering) Date: Sat, 14 May 2022 22:42:13 +0200 Subject: [address-policy-wg] IPv4 PA assignments policy change draft proposal In-Reply-To: <79D5B2F3-DA59-4B30-8C8F-321097D3C729@a2b-internet.com> References: <79D5B2F3-DA59-4B30-8C8F-321097D3C729@a2b-internet.com> Message-ID: Hi, On Sat, May 14, 2022 at 12:47:11PM +0000, Jeroen Lauwers wrote: > b. Arguments opposing the proposal > ??? An exception to the main rule does not make the overall policy more understandable. This. I am not convinced why adding a special-case "may" for "LIR to itself" while keeping the "must" for "LIR to others" would be a good idea of any sorts. "The database has issues with having an allocation being used all-in-one for one specific customer (the LIR itself)" is an implementation detail, but policy should not be driven by "database stuff is hard". Now, relaxing the overall mandate on customer data registration to something that just states "this is assigned, and the responsible tech/abuse contacts are as follows" without requiring to name any customers would be something I find a useful thought, given that the argument "assignments used to be necessary to document allocation usage, when coming back to the NCC" is as valid for LIR-to-itself as for LIR-to-third-parties. Gert Doering -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From tore at fud.no Sun May 15 10:36:31 2022 From: tore at fud.no (Tore Anderson) Date: Sun, 15 May 2022 10:36:31 +0200 Subject: [address-policy-wg] IPv4 PA assignments policy change draft proposal In-Reply-To: References: <79D5B2F3-DA59-4B30-8C8F-321097D3C729@a2b-internet.com> Message-ID: * Gert Doering > I am not convinced why adding a special-case "may" for "LIR to itself" > while keeping the "must" for "LIR to others" would be a good idea of any > sorts. Maybe a compromise would be to add a ?LIR to many others [with identical contact info]? type of database entry, analogous to the AGGREGATED-BY-LIR inet6num status. Tore From jameskennedy001 at gmail.com Sun May 15 13:55:33 2022 From: jameskennedy001 at gmail.com (James Kennedy) Date: Sun, 15 May 2022 13:55:33 +0200 Subject: [address-policy-wg] IPv4 PA assignments policy change draft proposal In-Reply-To: References: <79D5B2F3-DA59-4B30-8C8F-321097D3C729@a2b-internet.com> Message-ID: Hi, > I am not convinced why adding a special-case "may" for "LIR to itself" > while keeping the "must" for "LIR to others" would be a good idea of any > sorts. I believe this relates to the DBTF recommendation - "if a resource holder wants to sub-allocate or partition part of their IPv4 resources to another entity, the task force strongly recommends documenting this sub-allocation or assignment in the RIPE Database." The DBTF didn't identify a need to change the policy for LIRs registering/documenting blocks of PA that they issue to third parties in the RIPE Database. But we did see the need to change the policy for LIR Infrastructure PA Assignments - some LIRs flood the Database with huge volumes of very small infrastructure PA Assignments that would be extremely difficult to keep up-to-date, and the TF recommends "limiting and discouraging the use of the RIPE Database as an enterprise IPAM solution". Regards, James (DBTF hat on) On Sun, May 15, 2022 at 10:36 AM Tore Anderson wrote: > > * Gert Doering > > > I am not convinced why adding a special-case "may" for "LIR to itself" > > while keeping the "must" for "LIR to others" would be a good idea of any > > sorts. > > Maybe a compromise would be to add a ?LIR to many others [with > identical contact info]? type of database entry, analogous to the > AGGREGATED-BY-LIR inet6num status. > > Tore > > -- > > To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://mailman.ripe.net/ From gert at space.net Sun May 15 14:55:08 2022 From: gert at space.net (Gert Doering) Date: Sun, 15 May 2022 14:55:08 +0200 Subject: [address-policy-wg] IPv4 PA assignments policy change draft proposal In-Reply-To: References: <79D5B2F3-DA59-4B30-8C8F-321097D3C729@a2b-internet.com> Message-ID: Hi, On Sun, May 15, 2022 at 01:55:33PM +0200, James Kennedy wrote: > The DBTF didn't identify a need to change the policy for LIRs > registering/documenting blocks of PA that they issue to third parties > in the RIPE Database. But we did see the need to change the policy for > LIR Infrastructure PA Assignments - some LIRs flood the Database with > huge volumes of very small infrastructure PA Assignments that would be > extremely difficult to keep up-to-date, and the TF recommends > "limiting and discouraging the use of the RIPE Database as an > enterprise IPAM solution". This policy proposal would be the wrong vehicle to achieve any outcome towards *that* account - assignment-to-self would still be possible, just no more mandatory. This sounds more like a task for the training department or for the ARCs than for a policy change to me. OTOH: from a database utilization perspective, why would "I put all of my /22 in the DB in form of /29 and /30" be worse than "I use a /16 for customer assignments, /30../24, and register them all (as I MUST do)"? The latter would be many times more objects... Are we no longer aiming for accurate registration, because the DBTF finds that too resource consuming? I'm not sure I understand that line of argument. (Especially if used as an enterprise IPAM - or, more likely, as a mirror of the IPAM - accuracy is likely higher than if someone just manually puts aggregates into the DB whenever he feels like it. No?) Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From jameskennedy001 at gmail.com Sun May 15 16:53:59 2022 From: jameskennedy001 at gmail.com (James Kennedy) Date: Sun, 15 May 2022 16:53:59 +0200 Subject: [address-policy-wg] IPv4 PA assignments policy change draft proposal In-Reply-To: References: <79D5B2F3-DA59-4B30-8C8F-321097D3C729@a2b-internet.com> Message-ID: Hi, > assignment-to-self would still be possible, just > no more mandatory. Correct, I believe that's the aim of this proposal. LIRs will no longer be obliged by policy to register all their infrastructure assignments in the RIPE Database. Keep in mind under current policy, resource holders of a /24 PA allocation must create at least two PA assignments (/25 or smaller). If a /24 is used for the LIR's infrastructure, this policy proposal would remove those relatively arbitrary PA assignment registration requirements. > This sounds more like a task for the training department or for the ARCs > than for a policy change to me. The training department and ARCs help enforce policy. Current policy has resulted in considerable PA assignment registration inconsistencies by LIRs (see https://www.ripe.net/publications/docs/ripe-767#612). > OTOH: from a database utilization perspective, why would "I put all of > my /22 in the DB in form of /29 and /30" be worse than "I use a /16 > for customer assignments, /30../24, and register them all (as I MUST > do)"? The latter would be many times more objects... Mitigating one case issue doesn't impact the other. But indeed this proposal could possibly be scoped out to further consider customer assignments if the proposal author and WG wish. > Are we no longer aiming for accurate registration, because the DBTF finds > that too resource consuming? I'm not sure I understand that line of > argument. I've not seen that being made as an argument by anyone. Data accuracy is very high on the list of Data Management Principles: https://www.ripe.net/publications/docs/ripe-767#5--data-management-principles https://www.ripe.net/participate/ripe/tf/rdb-requirements-tf/database-requirements-task-force-recommendations Regards, James DBTF On Sun, May 15, 2022 at 2:55 PM Gert Doering wrote: > > Hi, > > On Sun, May 15, 2022 at 01:55:33PM +0200, James Kennedy wrote: > > The DBTF didn't identify a need to change the policy for LIRs > > registering/documenting blocks of PA that they issue to third parties > > in the RIPE Database. But we did see the need to change the policy for > > LIR Infrastructure PA Assignments - some LIRs flood the Database with > > huge volumes of very small infrastructure PA Assignments that would be > > extremely difficult to keep up-to-date, and the TF recommends > > "limiting and discouraging the use of the RIPE Database as an > > enterprise IPAM solution". > > This policy proposal would be the wrong vehicle to achieve any outcome > towards *that* account - assignment-to-self would still be possible, just > no more mandatory. > > This sounds more like a task for the training department or for the ARCs > than for a policy change to me. > > OTOH: from a database utilization perspective, why would "I put all of > my /22 in the DB in form of /29 and /30" be worse than "I use a /16 > for customer assignments, /30../24, and register them all (as I MUST > do)"? The latter would be many times more objects... > > Are we no longer aiming for accurate registration, because the DBTF finds > that too resource consuming? I'm not sure I understand that line of > argument. > > (Especially if used as an enterprise IPAM - or, more likely, as a mirror > of the IPAM - accuracy is likely higher than if someone just manually puts > aggregates into the DB whenever he feels like it. No?) > > Gert Doering > -- NetMaster > -- > have you enabled IPv6 on something today...? > > SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From gert at space.net Sun May 15 18:01:37 2022 From: gert at space.net (Gert Doering) Date: Sun, 15 May 2022 18:01:37 +0200 Subject: [address-policy-wg] IPv4 PA assignments policy change draft proposal In-Reply-To: References: <79D5B2F3-DA59-4B30-8C8F-321097D3C729@a2b-internet.com> Message-ID: Hi, On Sun, May 15, 2022 at 04:53:59PM +0200, James Kennedy wrote: > > assignment-to-self would still be possible, just > > no more mandatory. > > Correct, I believe that's the aim of this proposal. LIRs will no > longer be obliged by policy to register all their infrastructure > assignments in the RIPE Database. Technically, they have never been obliged to register this in fine detail ever. Though, some do, and some do not. Setting aside a /24 and marking this as "infrastructure" has always been good enough (modulo AW and Infra-AW and all the fine print). Those that register high amounts of detail even though they are not required to do so - what makes you think that they would stop if they are no longer required to do so? In other words: I still find it totally unclear what the underlying problem statement of this proposal is. Your attempt to do so by referring to "large amount of objects put into the DB for infrastructure" didn't make it any clearer. [..] > > This sounds more like a task for the training department or for the ARCs > > than for a policy change to me. > > The training department and ARCs help enforce policy. Help enforce, and plain help LIRs to better understand what is expected from them, even if not written down. The DBTF seems to want "less detailed infrastructure objects", though I fail the reasoning for that - but if that is the goal, it could be done by adding the expected level of detail to the LIR training. > Current policy > has resulted in considerable PA assignment registration > inconsistencies by LIRs (see > https://www.ripe.net/publications/docs/ripe-767#612). Ignoring for the moment that not all LIRs are identical, that still sounds to me like "training and ARC" - and why would the proposal being discussed here have an effekt on these inconsistencies? [..] > > Are we no longer aiming for accurate registration, because the DBTF finds > > that too resource consuming? I'm not sure I understand that line of > > argument. > > I've not seen that being made as an argument by anyone. Data accuracy > is very high on the list of Data Management Principles: Yes. So what is the intended benefit when aiming for a reduction of registry entries? Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From jameskennedy001 at gmail.com Sun May 15 19:38:01 2022 From: jameskennedy001 at gmail.com (James Kennedy) Date: Sun, 15 May 2022 19:38:01 +0200 Subject: [address-policy-wg] IPv4 PA assignments policy change draft proposal In-Reply-To: References: <79D5B2F3-DA59-4B30-8C8F-321097D3C729@a2b-internet.com> Message-ID: Hi, On Sun, 15 May 2022 at 18:01, Gert Doering wrote: > Those that register high amounts of detail even though they are not > required to do so - what makes you think that they would stop if they > are no longer required to do so? I think removing the policy mandate to register all infra pa assignments would reduce the potential for some LIRs to misinterpret the intent of the policy, e.g. think they must register loads of /32s. Personally I don?t see this proposal as a silver bullet to resolve all LIR IPv4 registration issues, but a helpful piece in the larger puzzle. Another option could be to more clearly explain what exactly is and is not intended by the policy. And I?m sure the author would appreciate additional constructive suggestions. > In other words: I still find it totally unclear what the underlying > problem statement of this proposal is. Your attempt to do so by > referring to "large amount of objects put into the DB for infrastructure" > didn't make it any clearer. I can?t speak on behalf of the proposal as I?m not the author. I?m only giving context to the DBTF recommendation. > [..] > > > This sounds more like a task for the training department or for the ARCs > > > than for a policy change to me. > > > > The training department and ARCs help enforce policy. > > Help enforce, and plain help LIRs to better understand what is expected > from them, even if not written down. The DBTF seems to want "less detailed > infrastructure objects", though I fail the reasoning for that - but if > that is the goal, it could be done by adding the expected level of detail > to the LIR training. Agree this would also help but unfortunately not all LIR administrators attend training courses. No matter how many tasty cookies are on offer :( > > > Are we no longer aiming for accurate registration, because the DBTF finds > > > that too resource consuming? I'm not sure I understand that line of > > > argument. > > > > I've not seen that being made as an argument by anyone. Data accuracy > > is very high on the list of Data Management Principles: > > Yes. So what is the intended benefit when aiming for a reduction of registry > entries? Improve data accuracy for one. From personal experience of managing multiple LIRs of vastly varying sizes, I found maintaining fewer objects far easier to keep data up-to-date in the RIPE database. But of course that?s a personal anecdote. I would be very interested to hear other people?s real life experiences, opinions and suggestions. Regards, James DBTF On Sun, May 15, 2022 at 6:01 PM Gert Doering wrote: > > Hi, > > On Sun, May 15, 2022 at 04:53:59PM +0200, James Kennedy wrote: > > > assignment-to-self would still be possible, just > > > no more mandatory. > > > > Correct, I believe that's the aim of this proposal. LIRs will no > > longer be obliged by policy to register all their infrastructure > > assignments in the RIPE Database. > > Technically, they have never been obliged to register this in fine > detail ever. Though, some do, and some do not. Setting aside a /24 > and marking this as "infrastructure" has always been good enough > (modulo AW and Infra-AW and all the fine print). > > Those that register high amounts of detail even though they are not > required to do so - what makes you think that they would stop if they > are no longer required to do so? > > > In other words: I still find it totally unclear what the underlying > problem statement of this proposal is. Your attempt to do so by > referring to "large amount of objects put into the DB for infrastructure" > didn't make it any clearer. > > [..] > > > This sounds more like a task for the training department or for the ARCs > > > than for a policy change to me. > > > > The training department and ARCs help enforce policy. > > Help enforce, and plain help LIRs to better understand what is expected > from them, even if not written down. The DBTF seems to want "less detailed > infrastructure objects", though I fail the reasoning for that - but if > that is the goal, it could be done by adding the expected level of detail > to the LIR training. > > > Current policy > > has resulted in considerable PA assignment registration > > inconsistencies by LIRs (see > > https://www.ripe.net/publications/docs/ripe-767#612). > > Ignoring for the moment that not all LIRs are identical, that still sounds > to me like "training and ARC" - and why would the proposal being discussed > here have an effekt on these inconsistencies? > > [..] > > > Are we no longer aiming for accurate registration, because the DBTF finds > > > that too resource consuming? I'm not sure I understand that line of > > > argument. > > > > I've not seen that being made as an argument by anyone. Data accuracy > > is very high on the list of Data Management Principles: > > Yes. So what is the intended benefit when aiming for a reduction of registry > entries? > > Gert Doering > -- NetMaster > -- > have you enabled IPv6 on something today...? > > SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From ripedenis at gmail.com Mon May 16 14:34:41 2022 From: ripedenis at gmail.com (denis walker) Date: Mon, 16 May 2022 14:34:41 +0200 Subject: [address-policy-wg] IPv4 PA assignments policy change draft proposal In-Reply-To: References: <79D5B2F3-DA59-4B30-8C8F-321097D3C729@a2b-internet.com> Message-ID: Hi James On Sun, 15 May 2022 at 19:38, James Kennedy wrote: > > Hi, > > On Sun, 15 May 2022 at 18:01, Gert Doering wrote: > > Those that register high amounts of detail even though they are not > > required to do so - what makes you think that they would stop if they > > are no longer required to do so? > > I think removing the policy mandate to register all infra pa > assignments would reduce the potential for some LIRs to misinterpret > the intent of the policy, e.g. think they must register loads of /32s. > Personally I don?t see this proposal as a silver bullet to resolve all > LIR IPv4 registration issues, but a helpful piece in the larger > puzzle. > > Another option could be to more clearly explain what exactly is and is > not intended by the policy. And I?m sure the author would appreciate > additional constructive suggestions. > I am confused by the DBTF recommendation which I think also needs more clarity. The recommendation says: "recommends that as resource holders have full responsibility over the registration of their IPv4 PA assignment(s), they are free to make assignments or not....and documenting IPv4 PA assignment(s) will stop being a policy requirement." I read this as meaning ALL assignments. This policy proposal seems to be suggesting to only change policy for an LIR's infrastructure assignments, leaving all assignment blocks to end users as a 'must' still be documented. So what is the intention here? > > In other words: I still find it totally unclear what the underlying > > problem statement of this proposal is. Your attempt to do so by > > referring to "large amount of objects put into the DB for infrastructure" > > didn't make it any clearer. > > I can?t speak on behalf of the proposal as I?m not the author. I?m > only giving context to the DBTF recommendation. > > > [..] > > > > This sounds more like a task for the training department or for the ARCs > > > > than for a policy change to me. > > > > > > The training department and ARCs help enforce policy. > > > > Help enforce, and plain help LIRs to better understand what is expected > > from them, even if not written down. The DBTF seems to want "less detailed > > infrastructure objects", though I fail the reasoning for that - but if > > that is the goal, it could be done by adding the expected level of detail > > to the LIR training. > > Agree this would also help but unfortunately not all LIR > administrators attend training courses. No matter how many tasty > cookies are on offer :( > > > > > Are we no longer aiming for accurate registration, because the DBTF finds > > > > that too resource consuming? I'm not sure I understand that line of > > > > argument. > > > > > > I've not seen that being made as an argument by anyone. Data accuracy > > > is very high on the list of Data Management Principles: > > > > Yes. So what is the intended benefit when aiming for a reduction of registry > > entries? > > Improve data accuracy for one. From personal experience of managing > multiple LIRs of vastly varying sizes, I found maintaining fewer > objects far easier to keep data up-to-date in the RIPE database. > I don't see this as an issue of numbers. The real question should be "What is the purpose of storing this data?" If there is a valid purpose for this data then reducing numbers of valid data to improve the quality of what remains is the wrong approach. cheers denis co-chair DB-WG > But of course that?s a personal anecdote. I would be very interested > to hear other people?s real life experiences, opinions and > suggestions. > > Regards, > James > DBTF > > > On Sun, May 15, 2022 at 6:01 PM Gert Doering wrote: > > > > Hi, > > > > On Sun, May 15, 2022 at 04:53:59PM +0200, James Kennedy wrote: > > > > assignment-to-self would still be possible, just > > > > no more mandatory. > > > > > > Correct, I believe that's the aim of this proposal. LIRs will no > > > longer be obliged by policy to register all their infrastructure > > > assignments in the RIPE Database. > > > > Technically, they have never been obliged to register this in fine > > detail ever. Though, some do, and some do not. Setting aside a /24 > > and marking this as "infrastructure" has always been good enough > > (modulo AW and Infra-AW and all the fine print). > > > > Those that register high amounts of detail even though they are not > > required to do so - what makes you think that they would stop if they > > are no longer required to do so? > > > > > > In other words: I still find it totally unclear what the underlying > > problem statement of this proposal is. Your attempt to do so by > > referring to "large amount of objects put into the DB for infrastructure" > > didn't make it any clearer. > > > > [..] > > > > This sounds more like a task for the training department or for the ARCs > > > > than for a policy change to me. > > > > > > The training department and ARCs help enforce policy. > > > > Help enforce, and plain help LIRs to better understand what is expected > > from them, even if not written down. The DBTF seems to want "less detailed > > infrastructure objects", though I fail the reasoning for that - but if > > that is the goal, it could be done by adding the expected level of detail > > to the LIR training. > > > > > Current policy > > > has resulted in considerable PA assignment registration > > > inconsistencies by LIRs (see > > > https://www.ripe.net/publications/docs/ripe-767#612). > > > > Ignoring for the moment that not all LIRs are identical, that still sounds > > to me like "training and ARC" - and why would the proposal being discussed > > here have an effekt on these inconsistencies? > > > > [..] > > > > Are we no longer aiming for accurate registration, because the DBTF finds > > > > that too resource consuming? I'm not sure I understand that line of > > > > argument. > > > > > > I've not seen that being made as an argument by anyone. Data accuracy > > > is very high on the list of Data Management Principles: > > > > Yes. So what is the intended benefit when aiming for a reduction of registry > > entries? > > > > Gert Doering > > -- NetMaster > > -- > > have you enabled IPv6 on something today...? > > > > SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer > > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann > > D-80807 Muenchen HRB: 136055 (AG Muenchen) > > Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 > > -- > > To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://mailman.ripe.net/ From jameskennedy001 at gmail.com Tue May 17 12:36:11 2022 From: jameskennedy001 at gmail.com (James Kennedy) Date: Tue, 17 May 2022 12:36:11 +0200 Subject: [address-policy-wg] IPv4 PA assignments policy change draft proposal In-Reply-To: References: <79D5B2F3-DA59-4B30-8C8F-321097D3C729@a2b-internet.com> Message-ID: Hi Denis, All, The DBTF recommendation doesn't go into the detail of use cases. That level should be deliberated and teased out by the WG, and the associated RIPE policies considered along with other methods such as training material, best practice/support documentation, ARCs, etc. So, here we are :) Question for the WG: A primary purpose for registering PA assignments in the RIPE database was to show the LIR's utilization of their existing allocated space in order to justify their request for an additional allocation from the RIPE NCC. As that purpose is now obsolete, is there another reason for policy to insist ("must") LIRs register PA assignments rather than giving LIRs the choice ("may') to do so or not? On Mon, May 16, 2022 at 2:35 PM denis walker wrote: > > Hi James > > On Sun, 15 May 2022 at 19:38, James Kennedy wrote: > > > > Hi, > > > > On Sun, 15 May 2022 at 18:01, Gert Doering wrote: > > > Those that register high amounts of detail even though they are not > > > required to do so - what makes you think that they would stop if they > > > are no longer required to do so? > > > > I think removing the policy mandate to register all infra pa > > assignments would reduce the potential for some LIRs to misinterpret > > the intent of the policy, e.g. think they must register loads of /32s. > > Personally I don?t see this proposal as a silver bullet to resolve all > > LIR IPv4 registration issues, but a helpful piece in the larger > > puzzle. > > > > Another option could be to more clearly explain what exactly is and is > > not intended by the policy. And I?m sure the author would appreciate > > additional constructive suggestions. > > > > I am confused by the DBTF recommendation which I think also needs more > clarity. The recommendation says: > "recommends that as resource holders have full responsibility over the > registration of their IPv4 PA assignment(s), they are free to make > assignments or not....and documenting IPv4 PA assignment(s) will stop > being a policy requirement." > > I read this as meaning ALL assignments. This policy proposal seems to > be suggesting to only change policy for an LIR's infrastructure > assignments, leaving all assignment blocks to end users as a 'must' > still be documented. So what is the intention here? You're right, the differentiation of issuing PA space to third parties is not made in that recommendation statement but the following: "However, if a resource holder wants to sub-allocate or partition part of their IPv4 resources to another entity, the task force strongly recommends documenting this sub-allocation or assignment in the RIPE Database." If the author and WG don't agree with "assignment" in that last sentence, indeed the scope for consideration can be *all* PA assignments ("can" rather than "must" be registered in the RIPE Database). > > > In other words: I still find it totally unclear what the underlying > > > problem statement of this proposal is. Your attempt to do so by > > > referring to "large amount of objects put into the DB for infrastructure" > > > didn't make it any clearer. > > > > I can?t speak on behalf of the proposal as I?m not the author. I?m > > only giving context to the DBTF recommendation. > > > > > [..] > > > > > This sounds more like a task for the training department or for the ARCs > > > > > than for a policy change to me. > > > > > > > > The training department and ARCs help enforce policy. > > > > > > Help enforce, and plain help LIRs to better understand what is expected > > > from them, even if not written down. The DBTF seems to want "less detailed > > > infrastructure objects", though I fail the reasoning for that - but if > > > that is the goal, it could be done by adding the expected level of detail > > > to the LIR training. > > > > Agree this would also help but unfortunately not all LIR > > administrators attend training courses. No matter how many tasty > > cookies are on offer :( > > > > > > > Are we no longer aiming for accurate registration, because the DBTF finds > > > > > that too resource consuming? I'm not sure I understand that line of > > > > > argument. > > > > > > > > I've not seen that being made as an argument by anyone. Data accuracy > > > > is very high on the list of Data Management Principles: > > > > > > Yes. So what is the intended benefit when aiming for a reduction of registry > > > entries? > > > > Improve data accuracy for one. From personal experience of managing > > multiple LIRs of vastly varying sizes, I found maintaining fewer > > objects far easier to keep data up-to-date in the RIPE database. > > > > I don't see this as an issue of numbers. The real question should be > "What is the purpose of storing this data?" If there is a valid > purpose for this data then reducing numbers of valid data to improve > the quality of what remains is the wrong approach. Agree with valid purpose being the baseline driver for (any) data storage. But I don't see that as being mutually exclusive to not having registrations that seemingly don't have valid purpose, e.g. assignments under /24s PA allocations. Regards, James DBTF (apwg co-chair hat still off) > cheers > denis > co-chair DB-WG > > > But of course that?s a personal anecdote. I would be very interested > > to hear other people?s real life experiences, opinions and > > suggestions. > > > > Regards, > > James > > DBTF > > > > > > On Sun, May 15, 2022 at 6:01 PM Gert Doering wrote: > > > > > > Hi, > > > > > > On Sun, May 15, 2022 at 04:53:59PM +0200, James Kennedy wrote: > > > > > assignment-to-self would still be possible, just > > > > > no more mandatory. > > > > > > > > Correct, I believe that's the aim of this proposal. LIRs will no > > > > longer be obliged by policy to register all their infrastructure > > > > assignments in the RIPE Database. > > > > > > Technically, they have never been obliged to register this in fine > > > detail ever. Though, some do, and some do not. Setting aside a /24 > > > and marking this as "infrastructure" has always been good enough > > > (modulo AW and Infra-AW and all the fine print). > > > > > > Those that register high amounts of detail even though they are not > > > required to do so - what makes you think that they would stop if they > > > are no longer required to do so? > > > > > > > > > In other words: I still find it totally unclear what the underlying > > > problem statement of this proposal is. Your attempt to do so by > > > referring to "large amount of objects put into the DB for infrastructure" > > > didn't make it any clearer. > > > > > > [..] > > > > > This sounds more like a task for the training department or for the ARCs > > > > > than for a policy change to me. > > > > > > > > The training department and ARCs help enforce policy. > > > > > > Help enforce, and plain help LIRs to better understand what is expected > > > from them, even if not written down. The DBTF seems to want "less detailed > > > infrastructure objects", though I fail the reasoning for that - but if > > > that is the goal, it could be done by adding the expected level of detail > > > to the LIR training. > > > > > > > Current policy > > > > has resulted in considerable PA assignment registration > > > > inconsistencies by LIRs (see > > > > https://www.ripe.net/publications/docs/ripe-767#612). > > > > > > Ignoring for the moment that not all LIRs are identical, that still sounds > > > to me like "training and ARC" - and why would the proposal being discussed > > > here have an effekt on these inconsistencies? > > > > > > [..] > > > > > Are we no longer aiming for accurate registration, because the DBTF finds > > > > > that too resource consuming? I'm not sure I understand that line of > > > > > argument. > > > > > > > > I've not seen that being made as an argument by anyone. Data accuracy > > > > is very high on the list of Data Management Principles: > > > > > > Yes. So what is the intended benefit when aiming for a reduction of registry > > > entries? > > > > > > Gert Doering > > > -- NetMaster > > > -- > > > have you enabled IPv6 on something today...? > > > > > > SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer > > > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann > > > D-80807 Muenchen HRB: 136055 (AG Muenchen) > > > Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 > > > > -- > > > > To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://mailman.ripe.net/ From max at rfc2324.org Sun May 22 20:59:04 2022 From: max at rfc2324.org (Maximilian Wilhelm) Date: Sun, 22 May 2022 20:59:04 +0200 Subject: [address-policy-wg] IPv6 Policy Musings... In-Reply-To: References: Message-ID: <20220522185904.GH1092@principal.rfc2324.org> Anno domini 2022 Gert Doering scripsit: Hey folks, > I announced too many weeks ago that a small group was looking into the > IPv6 policy, as it is today, why it is what it is, and whether the > underlying assumptions that the policy is based on are still valid. [...] > We'll present about this next week, picking some points as starting > points for "shall we do something here? if yes, what? and who?" - > but this is not about *me*, but about the commounity - *you*. Anyone > is free and welcome to start a discussion and work on aspects we brought > up - or on other aspects. Thanks for this and the work you put into it! I also believe some parts of the policies need some review and overhaul, and I think you identified a lot of details to think about. I'll try go provide a brain dump of some topics which resonated with me and which I ran into in the past with one of my different hats. First and foremoest, I agree with the observation that IPv6 PI space is a complicated beast and I still remember my last attempt at making it more usuable so people don't have to lie about there use cases. I fully agree with Jan's statement at the mic that we should look into this again and like Gert's suggestion to just drop the "3rd party clause" of the PI policy. In *this* case the marked might really have solved the issue and I'd be confident the issue of ISPs only giving out one IP per subscriber won't arise as those offers will be laughted at. Another commonly observed obstacle with IPv6 PI has been getting more than one /48, which also has been brought up by Max (not me :)), which I also fully agree with. If a network has a number of sites today and qualifies for n * /48 prefixes and in the foreseeable future might be able to conntect those sites (by means of DF, waves, or whatever), it does make a lot of sense to provide this organization with the aggregate for ceil(n * /48). Even if the sites don't end up being interconnected there's not much difference in prefix size and routing table usage, but less hassle for all parties involved. As a customer I recently ran into the issue that an IP access business connection came with an IPv4 /29 out of the box but no IPv6 whatsoever, not even a /64 on-link which would have totally sufficed for the use case. To get a /56 available on that link, it needed to be booked for 30? MRC on top of the existing monthly fee, which isn't very 2020. Private customers obviously get IPv6 by default as DS-lite is used to serve their IPv4 traffic. Tackling business practices isn't really within our scope, but maybe we can have this in mind when updating BCOP documents, to "motivate" ISPs to diverge from such practices, which certainly do not help furthering IPv6 deployment. Cheers, Max -- Friends are relatives you make for yourself.