From adallara at ripe.net Mon Apr 3 11:03:44 2023 From: adallara at ripe.net (Angela Dall'Ara) Date: Mon, 3 Apr 2023 10:03:44 +0100 Subject: [address-policy-wg] 2023-02 Review Phase (Minimum Size for IPv4 Temporary Assignments) Message-ID: Dear colleagues, Policy proposal 2023-02, "Minimum Size for IPv4 Temporary Assignments", is now in the Review Phase. This policy proposal recommends setting the minimum assignment size for IPv4 temporary assignments to a /24,while still allowing for a smaller assignment if requested by the End User. This policy proposal also allows routing requirements to justify the request for more than a /24 for research purposes. The RIPE NCC has prepared an impact analysis on this proposal to support the community?s discussion. You can find the proposal and impact analysis at: _https://www.ripe.net/participate/policies/proposals/2023-02_ _https://www.ripe.net/participate/policies/proposals/2023-02#impact-analysis_ And the draft documents at: _https://www.ripe.net/participate/policies/proposals/2023-02/draft_ As per the RIPE Policy Development Process (PDP), the purpose of this four-week Review Phase is to continue discussion of the proposal taking the impact analysis into consideration, and to review the full draft RIPE Policy Document. At the end of the Review Phase, the Working Group (WG) Chairs will determine whether the WG has reached rough consensus. It is therefore important to provide your opinion, even if it is simply a restatement of your input from the previous phase. We encourage you to read the proposal, impact analysis and draft document and to send any comments to address-policy-wg at ripe.net before 2 May 2023. Kind regards, Angela Dall'Ara Policy Officer RIPE NCC -------------- next part -------------- An HTML attachment was scrubbed... URL: From tobias at fiebig.nl Thu Apr 6 02:03:02 2023 From: tobias at fiebig.nl (Tobias Fiebig) Date: Thu, 06 Apr 2023 02:03:02 +0200 Subject: [address-policy-wg] IPv6 PI /46 Assignment Request Experience Summary Message-ID: <54972320fe9e84a057c470b80e850ff789582ac8.camel@fiebig.nl> Heho, I just had an interesting thread with the RIPE NCC when applying for an ASN and IPv6 /46 PI. Given the upcoming discussion on the 11th, some people suggested it might be interesting to describe the process on the list. Please excuse the length. I tried to be short, but there is a bit of context i believe should be included. With best regards, Tobias # Background ## About me For those who do not know me, I am Tobias, in my day-job I am a somewhat network measurement, somewhat security, somewhat humans researcher at the MPI-INF. In my spare time, i push a few packets around the Internet. I am currently speaking for myself/as de.wybt, and not my affiliation/MPI. ## Measurement.Network I am currently trying to build a 'measurement AS', i.e., an AS that is solely dedicated to network measurements, providing that service to academics, but also adding on some additional support. Specifically, the idea (briefly) is to: - Esp. support things going beyond SYN/Banner scanns; Did a lot of mail stuff in the past, for example, where it is easier to make mistakes. - Have a well-known AS/v4+v6 prefix dedicated to the network to make blocking easier, esp. as some researchers use public cloud infra for measurements, which are hard to block (as real services may be on those addr a week later) - Keep blocking collateral away from university/researchers' own institutions' networks - Do probe attribution, abuse handling, and opt-out correctly - Provide support/review of tools, going beyond 'academic ethics review' (there were some cases were people released harmfull tools due to their limited experience with the protocols they measured; and new PhDs students usually don't have 20 years of industry experience ;-)) - Make such infra more accessible; Some university IT departments can be a little anxious when you want to do active measurements My current plan is to get this built and running, and then see if some parts of the community would be willing to adopt it (and its? governance); Usually easier to ask for support when you have something working to show for. ;-) The idea is to have at least two PoPs with dedicated routing policies to also move DNS and mail 100% into the AS (block one thing, see no packets of any kind). Additionally, a further /23 allows for anycast experiments or tests using more/less specifics, without interfering with the infrastructure/static measurement networks. For the purpose of setting this up, MPI borrowed me a /22 v4. This left me with needing an ASN and an IPv6 prefix, the latter ideally being at least a /46 to be able to exactly mirror whatever policy might be on the /22. # Requests to the NCC Based on the above, I requested a 32bit ASN and a /46 PI from the NCC. Assignment of the ASN commenced after some in-depth discussion on policy provisions and how they apply to legacy space; After fulfilling the requirement that LEGACY spaceh should have INETNUM for the same org as the ORG holding an ASN (independent of MNT-ROUTE), the ASN was issued, even though I could not find this requirement in the applicable policy documents. The discussion around a PI assignment was, however, less successful. ## Reasoning for PI (7.2): - This is an independent project from the main activities of the main ASN of the LIR and should ultimately be upstreamed independent of AS59645. For now, while setting up, upstream would be provided by AS59645 and AS41051. - The assignment should not overlap with the existing PA of the LIR to ensure that the PA is not affected by potential blocking activity - The project, when established, would qualify for interconnection the main networks of the LIR do not necessarily qualify for, i.e., again necessitate a different routing policy. ## Reasoning for a /46 - The nature of the project needs it to be able to mirror any routing policy set for the v4 /22 to be able to leverage this network for measurements to its full extend based on requested experiments, ranging from experiments using more/less specifics or anycast experiments. (routing needs) - There are at least two PoPs which are to be hosting services necessitating distinct routing policies (DNS prim/sec, mail prim/sec), even though there is L2 transport for iBGP between the PoPs. Even though upstreams overlap between the PoPs, upstreams also have diverging routing policies for both PoPs. (routing need) ## Additional reasoning in line with general goals (3.) - To prevent renumbering and overhead if the project would reach a state that allows it to enter community governance, resources should be independent of the LIR, i.e., transferable (3.7). - As the routing policy of the /22 v4 should be mirrored, more than a /46 is not necessary (3.5), a /46 allows for aggregation (3.4) under changing policy, i.e., when no experiments are running that require all four sub-networks in different policies, and an aggregatable prefix is needed to be able to run experiments with overlapping prefixes, e.g., investigate how well more specifics are honored given some anecdotes that they might not _always_ win). # Discussion with the NCC ## First exchange In the first reply, the NCC requested a full documentation of the intended modus operandi of measurement.network, likely aiming at identifying whether use of addresses would technically constitute sub-allocations to researchers, barring the use of PI. Additionally, the NCC noted that additional reasoning for PI has to be provided given existing PA. The NCC noted, after just having had initially denied the request for an ASN to announce the v4 /22, that the /22 or any more specifics are not in the DFZ, and hence requested documentation of AS59645's current routing policy and how it would differ for the requested PI. ### Reply In reply, I provided a full documentation of the proposed goals and modus operandi as well as the intended governance structure of measurement.network. Furthermore, I detailed the reasoning following 7.2 as outlined above. ## Second exchange After informing me of needing some time to deliberate, the NCC came back and requested information on what 'network measurements' are, which subnet sizes would be used for measurements, and the legal status of any potential 'review board' of the project prior to it moving to not-only-me-is-responsible-governance, likely to ascertain whether there should be another entity listed as an ORG. Additionally, the NCC mentioned that more specific INET(6)NUM objects cannot be created for PI (see also my recent post on the db-wg ML). Instead, the NCC suggested i could do this with an allocation. ### Reply In reply, i defined network measurements and provided examples via my recent publications, clarified that, for now, i would be solely responsible in a legal sense, explained subnet sizes planned to be used, detailed various experiments needing unique routing policies stretching over a /46, and documented why technically, more specific INET6NUM are covered by policy as long as they use the same ORG object, but simply are not supported by the DB. Additionally, i asked whether their reference to PA suggested that they propose to apply RIPE-738 5.2.1. b), i.e., the justification of a new allocation due to new needs arising from this project, specifically, as per RIPE-738 5.1.2, the segmentation of infrastructure for security reasons, more specifically, the blocking and security implications of measurement infrastructure. Even though i noted that I'd be happy to receive an additional non-adjacent allocation to my existing PA, I also noted that a /46 PI would satisfy the unique routing requirementes we seemed to have converged on at this point, as it aligns closer to 3.5 of the policy (address space conservation). ## Third exchange A day later, the NCC came back, first addressing my question regarding their suggestion around PA by referencing the general page on assessment criteria for IPv6 allocations, and noting that a /29 holds 524 thousand /48. The NCC also agreed on my point concerning more specific INET(6)NUM objects, but noted that this is not supported by the DB. Next, the NCC came back to highlighting unique routing requirements, noting that announcements would take place in the same physical locations as AS59645 is present in, and hence again questioned unique routing requirements. Furthermore, the NCC noted that i mentioned that both sites are connected via L2, making Duesseldorf and Berlin essentially one end-site. This means that they could only issue one /48 unless i can demonstrate unique routing requirements for each site; The NCC also states that "The minimum size of the assignment is a /48.", which is interpreted as to mean that '[f]ollowing the policy, [the NCC] can only issue larger assignments to sites where there is a need to use more than 65536 of /64 subnets. However, multiple /48 assignments can be issued to multiple distinct sites.' Hence, as even when qualifying for more than one /48, i would receive multiple non-contiguous prefixes, the NCC concludes, that this means that 'it [is] impossible to achieve traffic advertisement using more and less specific prefixes (as [the NCC] understand[s] you need to use for the measurements) while using IPv6 PI space' ### Reply In reply, i first referred back to the second message in the ticket, where i detailed the different upstream and pering interconnections the project would qualify for, despite the announcements happening from the same physical locations, i.e., measurement.networking being topologically different. Next, i first state that 'minimum size of the assignment' prevents a /49, but not--as implied--a /47. Next, i challenge the point that addressing needs (number of devices to address) is the only justification for less specific assignments, referring to 5.4.2 of the policy, which clearly stats that exceeding the size of a single /48, either via multiple /48 or a shorter prefix, requires that it: a) must be based on address usage OR b) because different routing requirements exist Subsequently, i also note that the policy does not distinguish between assigning more than a single /48 to an end-site and assigning a less specific prefix, as it reads "Assignments larger than a /48 [shorter prefix] or additional assignments exceeding a total of a /48..." Before concluding, i again reference the NCCs statement that PI could not meet my routing requirements, asking whether their statements means that they acknowledge that my unique routing requirements could be satisfied by assigning a /46, but not by assigning a /48. I conclude the reply by summarizing my core points: - I read the NCCs statements regarding impossibility of fulfillign my routing requirements as acknowledging the existence of unique routing requirements. - The NCC proposes multiple /48 instead of a /46, claiming the former to be in-policy and the latter not, while the policy does not distinguish the two cases (or connected). - Noting that given 3.8 and thereon 3.4 of the policy, a single /46 will be more compliant than multiple /48, thereby making multiple /48 essentially incompliant. Finally, i note that i find it challenging to see how the NCC applies policy, especially given they cite policy incomplete and make proposals essentially less compliant than the (in my opinion in-policy) initial request. Hence, I ask whether they could point to where the policy supports their interpretation, or if they believe the case to be so unclear that it should be discussed with the wg. ## Fourth exchange Three days later, the NCC came back, claiming that 5.4.2 of the policy only "covers cases when [a] single End-site need[s] a larger prefix due to "address usage" which in this case is measured in terms of subnets. Subnet size in IPv6 is fixed at /64." Furthermore, they reiterate that this only means multiple assignements can be requested and approved under the policy. The NCC also reiterates that, due to the L2 connection, only one /48 can be issued, and i only informed the NCC about one routing policy. The NCC also repeats that, even if there were multiple locations, only multiple /48 could be assigned, not referring to policy at all. ### Reply In reply, i highlgihted again that the NCC makes claims not covered by policy, specifically, there being a difference between multiple non-adjacent more specifics vs. a less specific of the same aggregate size (barring the aggregation principle outlined in 3.8, which should be the highest priority goal in all interpretations of the policy, according to the policy, essentially prioritizing a single less specific over multiple more specifics). I also reiterate that 5.4.2 does not require multiple locations for routing requirements to be in place. I conclude by reiterating that the NCC acknowledged my unique routing requirements use case, given it sees it as a routing setup not possible with a single /48; Note that--as the NCC considers DUS and BER to be one site--5.4.2 certainly applies, which also means that the same requirements hold for assigning multiple /48 instead of a shorter prefix (aggain, barring 3.8). I close with the question why the NCC--given it considers multiple /48 feasible--refuses to apply policy (unique routing requirements and a single prefix shorter than /48 to satisfy these). ## Resolution At this point, the process had been going for nearly two weeks. While typing up the last reply to the NCC around 4pm, I acquired a /32 IPv6 PA and had the offering party initiate a transfer. The next morning, I received a reply from the NCC telling me that they would come back to me regarding my prior reply to the PI request. When the transfer of the /32 was completed a few hours later, I informed the NCC that the issue had been resolved and I would no longer need a dedicated assignment. So far, the ticket has not been closed, but i expect this to happen shortly. # Relevant discussion points Given how the process went, I see some points relevant to the ongoing discussion. ## Interpretation of policy by the NCC I believe that my reading of the policy has been outlined sufficiently above. I see that one may disagree on matters of how policy may be read. What, however, concerns me a bit is that the NCC provided incomplete citations of the policy in multiple instances throughout the ticket, where the omitted parts no longer supported the position of the NCC. Furthermore, i find the very fundamental adherence to, even multiple, /48 assignements in place of a smaller prefix/larger assignment size odd given 3.4 and 3.7 of the policy, especially considering the statement in 3.8 of the policy that makes it very clear that "In IPv6 address policy, the goal of aggregation is considered to be the most important." ## 3.5-3.7 of RIPE-738 Given the standard reservation sizes for v6 PI, as well as the ultimate solution for the issue I encountered, I am not sure whether either multiple /48 or the path I now ultimately took to reduce overhead for me is ideal; However, obtaining a larger prefix than needed (due to the minimum size of PA, i.e., /32 instead of /46), and doing so in less than 24h, in contrast to a nearly two week (unsuccesful) request with the NCC feels odd. I am also not to sure whether 3.6 is sufficiently covered here. As it is indeed significantly easier for LIRs to obtain PA of at least /32, than it is for end-users to even obtain a /47. Looking at this cynicaly, one might argue that undertaking/building/contributing a project like the one I am building is hardly possible for end-users that are not LIRs, even though I'd also argue that projects like this are very much what PI is for. Being an LIR making this easier, at least to me, pretty much feels like an "other factor", as described in 3.6. -- Dr.-Ing. Tobias Fiebig T +31 616 80 98 99 M tobias at fiebig.nl From massimo at ntt.net Fri Apr 7 10:22:32 2023 From: massimo at ntt.net (Massimo Candela) Date: Fri, 7 Apr 2023 10:22:32 +0200 Subject: [address-policy-wg] 2023-02 Review Phase (Minimum Size for IPv4 Temporary Assignments) In-Reply-To: References: Message-ID: <1e8fde20-f723-1dfd-3c56-2133ce06fbca@ntt.net> On 03/04/2023 18:03, Angela Dall'Ara wrote: > Dear colleagues, > > Policy proposal 2023-02, "Minimum Size for IPv4 Temporary Assignments", > is now in the Review Phase. > > It is therefore important to provide your opinion, even if it is simply > a restatement of your input from the previous phase. I support the proposal. From massimo at ntt.net Fri Apr 7 10:43:10 2023 From: massimo at ntt.net (Massimo Candela) Date: Fri, 7 Apr 2023 10:43:10 +0200 Subject: [address-policy-wg] delegate LIR portal access to specific user for specific resources - was: 2023-02 New Policy Proposal (Minimum Size for IPv4 Temporary Assignments) In-Reply-To: References: <62d6b343-3976-69ab-7eb6-448d85b9cce4@ntt.net> Message-ID: Hi Elvis, On 14/03/2023 08:42, Elvis Daniel Velea wrote: > Hi Massimo, > > thank you for your message. Let me see if I have an answer to some of > your questions/comments. See inline. > > ------- > I also mention below a variation of this proposal, which could be it's > own proposal/thread (suggestions welcome): > > There should be an easy way to do "temporary assignments" (which may or > may not be the correct term in this case) to researchers/developers, > starting from address space of a company which is "sponsoring" the > research. > > > The key part of what I would like to have is the possibility to provide > somebody with access to LIR portal services but limited to a specific > subset of my resources. > > In general, a company is not going to support a research/experiment by > providing indiscriminate access to the LIR portal. Creating a new > LIR or > transferring prefixes is not a plausible solution in this context. > > > An existing LIR can do an assignment to a researcher/developer as we > speak. All assignments an LIR makes are ?temporary?, some may last a day > and some may last 10 years? Can you explain this better? I have been asking to several ncc contacts and there was no suitable solution for this at the moment. Asking researchers/developers to create their own LIRs so that resources can be transferred is not a practical solution, but I'm not sure you are referring to this. Giving the researcher/developer access to the LIR portal/APIs for all the resources is also not a solution. > > If you want the researcher to have access to services like RPKI, they > can ask their LIR. In some cases, maybe temporary transfers could also > be of use. Again, I don't see a way to do this at the moment. > > Note that this proposal aims to update the temporary assignment proposal > that is currently in place. The RIPE NCC makes these temporary > assignments from a pool of IPs they have reserved specifically for this > purpose. I understand. This is why I said that this could be a different proposal (even if related by a similar purpose). I changed the email subject to avoid confusion. > > > Also, I believe this would remove the need for an approval procedure > from the RIPE NCC side: (1) if the address space used is of a company, > there is less need to validate the research project motivations; and > (2) > the company "sponsoring" is also the one responsible for the address > space. > > > I am not sure I understand what you mean by this. The NCC does not need > to approve any assignments made by LIRs. The NCC will need to approve > temporary assignments if the request is sent by an LIR (for an end-user) > based on the current temporary assignment policy. That's exactly what I'm saying. Assignments done by LIRs of their own resources do not require approval, while they would satisfy the research use case (in summary: using prefixes from the ncc stash is not needed in all cases). Thanks for your answers. Ciao, Massimo From tobias at fiebig.nl Fri Apr 7 12:20:32 2023 From: tobias at fiebig.nl (Tobias Fiebig) Date: Fri, 07 Apr 2023 12:20:32 +0200 Subject: [address-policy-wg] delegate LIR portal access to specific user for specific resources - was: 2023-02 New Policy Proposal (Minimum Size for IPv4 Temporary Assignments) In-Reply-To: References: <62d6b343-3976-69ab-7eb6-448d85b9cce4@ntt.net> Message-ID: Heho, Answering as i just use[d] this. > Can you explain this better? I have been asking to several ncc > contacts and there was no suitable solution for this at the moment. > > Asking researchers/developers to create their own LIRs so that > resources can be transferred is not a practical solution, but I'm not > sure you are referring to this. Giving the researcher/developer > access to the LIR portal/APIs for all the resources is also not a > solution. The researchers just need a MNT object on an account they can create (and likely already have for Atlas), which does not have to be an LIR. The LIR then just does an 'ALLOCATED-BY-LIR' with the researchers' MNT as MNT-BY. Should then just show up under 'your resources', iirc. RPKI, of course, still has to be set by the LIR. This is not much different than what is happening with a tmp. PI assignment; There, the LIR will have MNT-BY on the resource (as well as the end-user who requested it, i.e., the researchers). As said, the only thing missing there is being able to set RPKI oneself. The rest should work (barring DNS of parent zones already exist in the DB). If you send me a MNT-BY/ORG/ROLE set, we can also quickly test this by me making a temporary allocation for testing. With best regards, Tobias -- Dr.-Ing. Tobias Fiebig T +31 616 80 98 99 M tobias at fiebig.nl From sander at steffann.nl Sat Apr 8 17:55:57 2023 From: sander at steffann.nl (Sander Steffann) Date: Sat, 8 Apr 2023 17:55:57 +0200 Subject: [address-policy-wg] RIR Policy Proposal overview Message-ID: <075243C4-36A3-474C-BB20-370C8CD6A4A7@steffann.nl> Hi everybody, I created a quick overview page of all the policy proposals in the different RIRs: https://proposals.nogalliance.org/ Hope you find this useful! Cheers! Sander From gert at space.net Tue Apr 11 08:42:44 2023 From: gert at space.net (Gert Doering) Date: Tue, 11 Apr 2023 08:42:44 +0200 Subject: [address-policy-wg] 2023-02 Review Phase (Minimum Size for IPv4 Temporary Assignments) In-Reply-To: References: Message-ID: Hi, On Mon, Apr 03, 2023 at 10:03:44AM +0100, Angela Dall'Ara wrote: > Policy proposal 2023-02, "Minimum Size for IPv4 Temporary Assignments", > is now in the Review Phase. I still support the proposed change. 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 me at cynthia.re Tue Apr 11 12:46:50 2023 From: me at cynthia.re (=?UTF-8?Q?Cynthia_Revstr=C3=B6m?=) Date: Tue, 11 Apr 2023 12:46:50 +0200 Subject: [address-policy-wg] 2023-02 Review Phase (Minimum Size for IPv4 Temporary Assignments) In-Reply-To: References: Message-ID: I support the policy proposal. However, I would prefer to see the second paragraph of the proposed article 3.3 reworded. Currently it's just one really long sentence and it was a bit difficult for me to read. I'm pretty sure that I got the point but I think it should be improved and disambiguated a bit. -Cynthia On Mon, 3 Apr 2023, 11:04 Angela Dall'Ara, wrote: > Dear colleagues, > > > > Policy proposal 2023-02, "Minimum Size for IPv4 Temporary Assignments", > is now in the Review Phase. > > > > This policy proposal recommends setting the minimum assignment size for IPv4 > temporary assignments to a /24, while still allowing for a smaller > assignment if requested by the End User. This policy proposal also allows > routing requirements to justify the request for more than a /24 for > research purposes. > > > > The RIPE NCC has prepared an impact analysis on this proposal to support > the community?s discussion. > > > > You can find the proposal and impact analysis at: > > *https://www.ripe.net/participate/policies/proposals/2023-02 > * > > *https://www.ripe.net/participate/policies/proposals/2023-02#impact-analysis > * > > And the draft documents at: > > *https://www.ripe.net/participate/policies/proposals/2023-02/draft > * > > > > As per the RIPE Policy Development Process (PDP), the purpose of this > four-week Review Phase is to continue discussion of the proposal taking the > impact analysis into consideration, and to review the full draft RIPE > Policy Document. > > > > At the end of the Review Phase, the Working Group (WG) Chairs will > determine whether the WG has reached rough consensus. > > It is therefore important to provide your opinion, even if it is simply a > restatement of your input from the previous phase. > > > > We encourage you to read the proposal, impact analysis and draft document > and to send any comments to address-policy-wg at ripe.net before 2 May 2023. > > > > > > Kind regards, > > > > Angela Dall'Ara > > Policy Officer > > RIPE NCC > > -- > > To unsubscribe from this mailing list, get a password reminder, or change > your subscription options, please visit: > https://mailman.ripe.net/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From erik at bais.name Tue Apr 11 13:43:34 2023 From: erik at bais.name (Erik Bais) Date: Tue, 11 Apr 2023 11:43:34 +0000 Subject: [address-policy-wg] IPv6 policy - 2nd prioritisation and outcomes discussion webinar In-Reply-To: References: Message-ID: This is a small reminder that we are looking forward to you see online and your input on the review for the IPv6 policy this afternoon. Regards, Erik Bais On behalf of the AP-WG Chair collective. ?On 21/03/2023, 22:48, "address-policy-wg on behalf of Leo Vegoda" on behalf of leo at vegoda.org > wrote: At RIPE 85 we continued a review of the IPv6 policy that began at RIPE 83. Several areas for improvement were agreed. We promised to host an inter-sessional webinar to discuss priorities and the outcomes to work towards. We held the first webinar on Monday, 20 February 2023. You can read a summary of what was discussed on RIPE Labs. A full recording and minutes are published on the interim sessions page. - https://labs.ripe.net/author/leo_vegoda/next-steps-in-ipv6-policy-work/ - https://www.ripe.net/participate/ripe/wg/active-wg/ap/interim-sessions The second webinar will take place on Tuesday, 11 April at 13:30 UTC (15:30 CEST). If you want to help us set priorities and define the outcomes the community needs you are welcome to join. Join Zoom Meeting https://ripe.zoom.us/j/93730573273?pwd=eWJ1WEEzSzVSSEJNKy9JeXk0L3RqZz09 Leo Vegoda for the Address Policy WG co-chairs -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://mailman.ripe.net/ From adallara at ripe.net Mon Apr 24 09:01:03 2023 From: adallara at ripe.net (Angela Dall'Ara) Date: Mon, 24 Apr 2023 09:01:03 +0200 Subject: [address-policy-wg] 2023-01 Extended Discussion Phase (Reducing IXP IPv4 assignment default size to a /26) Message-ID: Dear colleagues, The policy proposal 2023-01, "Reducing IXP IPv4 assignment default size to a /26" is now in the extended Discussion Phase. This proposal modifies the default size of IPv4 assignments for IXPs from a /24 to /26 and clarifies the return of the assignments previously issued for their IXP peering LAN. The Discussion Phase has been extended as there was some support for the concept, but no feedback was sent on v 2.0. As per the RIPE Policy Development Process (PDP), the purpose of this five-week Discussion Phase is to discuss the proposal and provide feedback to the proposers. If you support this version of the proposal (v 2.0), please indicate that support with a simple message to the mailing list. If you have objections or would like a change, please provide that feedback to the mailing list. At the end of the Discussion Phase, the proposers, with the agreement of the WG Chairs, will decide how to proceed with the proposal. You can find the full proposal at: https://www.ripe.net/participate/policies/proposals/2023-01 The PDP document can be found at: https://www.ripe.net/publications/docs/ripe-781 We encourage you to review this proposal and send your comments to address-policy-wg at ripe.net before 29 May 2023. Kind regards, Angela Dall'Ara Policy Officer RIPE NCC -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnold.nipper at de-cix.net Mon Apr 24 11:10:54 2023 From: arnold.nipper at de-cix.net (Arnold Nipper) Date: Mon, 24 Apr 2023 11:10:54 +0200 Subject: [address-policy-wg] 2023-01 Extended Discussion Phase (Reducing IXP IPv4 assignment default size to a /26) In-Reply-To: References: Message-ID: <17bd099b-f053-0d39-3266-ae032f9d5e70@de-cix.net> On 24.04.2023 09:01, Angela Dall'Ara wrote: > support this version of the proposal (v 2.0) > +1 -- Arnold Nipper Chief Technology Evangelist and Co-Founder DE-CIX Management GmbH Lindleystra?e 12 | 60314 Frankfurt a.M. | Germany Phone +49 69 1730902 22 | Mobile +49 172 2650958 arnold.nipper at de-cix.net | www.de-cix.net Geschaeftsfuehrer Ivaylo Ivanov und Sebastian Seifert Registergericht AG Koeln HRB 51135 Want to work at DE-CIX: https://de-cix.net/en/about-de-cix/careers -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 203 bytes Desc: OpenPGP digital signature URL: From gert at space.net Mon Apr 24 11:30:52 2023 From: gert at space.net (Gert Doering) Date: Mon, 24 Apr 2023 11:30:52 +0200 Subject: [address-policy-wg] 2023-01 Extended Discussion Phase (Reducing IXP IPv4 assignment default size to a /26) In-Reply-To: References: Message-ID: Hi, On Mon, Apr 24, 2023 at 09:01:03AM +0200, Angela Dall'Ara wrote: > This proposal modifies the default size of IPv4 assignments for IXPs > from a /24 to /26 and clarifies the return of the assignments previously > issued for their IXP peering LAN. Support. v2.0 has taken the feedback about not requiring "new technology" in policy into account, and sticks to the key issue, reducing the assignment size. Also, /26 seems a reasonable middle way on the arguments heard in the previous discussion. 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 max at rfc2324.org Mon Apr 24 11:34:20 2023 From: max at rfc2324.org (Maximilian Wilhelm) Date: Mon, 24 Apr 2023 11:34:20 +0200 Subject: [address-policy-wg] 2023-01 Extended Discussion Phase (Reducing IXP IPv4 assignment default size to a /26) In-Reply-To: References: Message-ID: <20230424093420.GG24599@principal.rfc2324.org> Moin, Anno domini 2023 Gert Doering scripsit: > On Mon, Apr 24, 2023 at 09:01:03AM +0200, Angela Dall'Ara wrote: > > This proposal modifies the default size of IPv4 assignments for IXPs > > from a /24 to /26 and clarifies the return of the assignments previously > > issued for their IXP peering LAN. > > Support. v2.0 has taken the feedback about not requiring "new technology" > in policy into account, and sticks to the key issue, reducing the > assignment size. Also, /26 seems a reasonable middle way on the > arguments heard in the previous discussion. +1 Cheers, Max From steven.bakker at ams-ix.net Tue Apr 25 10:59:39 2023 From: steven.bakker at ams-ix.net (Steven Bakker) Date: Tue, 25 Apr 2023 08:59:39 +0000 Subject: [address-policy-wg] 2023-01 Extended Discussion Phase (Reducing IXP IPv4 assignment default size to a /26) In-Reply-To: References: Message-ID: <6e9f986faaad4211744272683bf468b79387f3dd.camel@ams-ix.net> Hi, Looks good to me. -- Steven On Mon, 2023-04-24 at 09:01 +0200, Angela Dall'Ara wrote: > Dear colleagues, > ? > The policy proposal 2023-01, "Reducing IXP IPv4 assignment default > size to a /26" is now in the extended Discussion Phase. > ? > This proposal modifies the default size of IPv4 assignments for IXPs > from a /24 to /26 and clarifies the return of the assignments > previously issued for their IXP peering LAN. > ? > The Discussion Phase has been extended as there was some support for > the concept, but no feedback was sent on v 2.0. > ? > As per the RIPE Policy Development Process (PDP), the purpose of this > five-week Discussion Phase is to discuss the proposal and provide > feedback to the proposers. > If you support this version of the proposal (v 2.0), please indicate > that support with a simple message to the mailing list. > If you have objections or would like a change, please provide that > feedback to the mailing list. > ? > At the end of the Discussion Phase, the proposers, with the agreement > of the WG Chairs, will decide how to proceed with the proposal. > > > You can find the full proposal at: > https://www.ripe.net/participate/policies/proposals/2023-01 > ? > The PDP document can be found at: > https://www.ripe.net/publications/docs/ripe-781 > > ? > We encourage you to review this proposal and send your comments to > address-policy-wg at ripe.net before 29 May 2023. > > > Kind regards, > > Angela Dall'Ara > Policy Officer > RIPE NCC -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From cfriacas at fccn.pt Wed Apr 26 10:13:16 2023 From: cfriacas at fccn.pt (=?ISO-8859-15?Q?Carlos_Fria=E7as?=) Date: Wed, 26 Apr 2023 09:13:16 +0100 (WEST) Subject: [address-policy-wg] 2023-01 - New Version Policy Proposal (Reducing IXP IPv4 assignment default size to a /26) In-Reply-To: <281efcf3-c3d2-b8c1-f914-b4969ec12b04@ripe.net> References: <281efcf3-c3d2-b8c1-f914-b4969ec12b04@ripe.net> Message-ID: <3b97d0eb-5aa6-3e7e-9ed-adc5f82e88cf@fccn.pt> Hi All, I would like to express my support to this proposal. It doesn't seem to tackle recovering IXP assignments made to orgs which are not really operating as IXPs, but is definitely a step in a positive direction. Best Regards, Carlos On Mon, 6 Mar 2023, Angela Dall'Ara wrote: > > Dear colleagues, > > RIPE policy proposal 2023-01, "Reducing IXP IPv4 assignment default size to a /26" is now available for discussion again. > > The goal of this proposal is to reduce the default size of IPv4 assignments for IXPs from a /24 to /26 and clarifies the return of the > assignments previously issued for their IXP peering LAN. > > > Following the last round of discussion, this proposal has been updated and it is now at version 2.0. > The main difference from version 1.0 is that IXPs are not required to implement the exchange of IPv4 routing information over IPv6 > before requesting an assignment larger than a /24. > > ? > > You can find the full proposal at: > https://www.ripe.net/participate/policies/proposals/2023-01 > > As per the RIPE Policy Development Process (PDP), the purpose of this four-week Discussion Phase is to discuss the proposal and provide > feedback to the proposer. > > At the end of the Discussion Phase, the proposers, with the agreement of the WG Chairs, will decide how to proceed with the proposal. > > The PDP document can be found at: > https://www.ripe.net/publications/docs/ripe-781 > > > We encourage you to review this proposal and send your comments to > address-policy-wg at ripe.net before 4 April 2023. > > > Kind regards, > > Angela Dall'Ara > Policy Officer > RIPE NCC > > > From gert at space.net Wed Apr 26 10:18:05 2023 From: gert at space.net (Gert Doering) Date: Wed, 26 Apr 2023 10:18:05 +0200 Subject: [address-policy-wg] 2023-01 - New Version Policy Proposal (Reducing IXP IPv4 assignment default size to a /26) In-Reply-To: <3b97d0eb-5aa6-3e7e-9ed-adc5f82e88cf@fccn.pt> References: <281efcf3-c3d2-b8c1-f914-b4969ec12b04@ripe.net> <3b97d0eb-5aa6-3e7e-9ed-adc5f82e88cf@fccn.pt> Message-ID: Hi, On Wed, Apr 26, 2023 at 09:13:16AM +0100, Carlos Fria?as via address-policy-wg wrote: > It doesn't seem to tackle recovering IXP assignments made to orgs which > are not really operating as IXPs, but is definitely a step in a positive > direction. "not operating as IXP" is something that normal RS procedures should cover ("you were given an address block that is exclusive for IXPs, so please return if you are not running one"). "not *really* operating as IXP" is usually open for long discussions... gert -- 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 cfriacas at fccn.pt Wed Apr 26 10:19:35 2023 From: cfriacas at fccn.pt (=?ISO-8859-15?Q?Carlos_Fria=E7as?=) Date: Wed, 26 Apr 2023 09:19:35 +0100 (WEST) Subject: [address-policy-wg] 2023-02 Review Phase (Minimum Size for IPv4 Temporary Assignments) In-Reply-To: References: Message-ID: <321344-e978-5547-7880-589a9673a3d@fccn.pt> Hi, I also support this proposal, after reading the NCC's impact analysis. I was a bit surprised to see there is a /13 reserved for temporary assignments, and only a /15 for IXPs (just read also 2023-01...). I would also like to add a +1 to what Cynthia wrote, even if this will require a version 2.0 of this proposal. Regards, Carlos On Tue, 11 Apr 2023, Cynthia Revstr?m via address-policy-wg wrote: > I support the policy proposal. > However, I would prefer to see the second paragraph of the proposed article 3.3 reworded. Currently it's just one really long sentence > and it was a bit difficult for me to read. I'm pretty sure that I got the point but I think it should be improved and disambiguated a > bit. > > -Cynthia > > On Mon, 3 Apr 2023, 11:04 Angela Dall'Ara, wrote: > > Dear colleagues, > > ? > > Policy proposal 2023-02, "Minimum Size for IPv4 Temporary Assignments", is now in the Review Phase. > > ? > > This policy proposal recommends setting the minimum assignment size for IPv4 temporary assignments to a /24, while still > allowing for a smaller assignment if requested by the End User. This policy proposal also allows routing requirements to > justify the request for more than a /24 for research purposes. > > ? > > The RIPE NCC has prepared an impact analysis on this proposal to support the community?s discussion. > > ? > > You can find the proposal and impact analysis at: > > https://www.ripe.net/participate/policies/proposals/2023-02 > > https://www.ripe.net/participate/policies/proposals/2023-02#impact-analysis > > And the draft documents at: > > https://www.ripe.net/participate/policies/proposals/2023-02/draft > > ? > > As per the RIPE Policy Development Process (PDP), the purpose of this four-week Review Phase is to continue discussion of > the proposal taking the impact analysis into consideration, and to review the full draft RIPE Policy Document. > > ? > > At the end of the Review Phase, the Working Group (WG) Chairs will determine whether the WG has reached rough consensus. > > It is therefore important to provide your opinion, even if it is simply a restatement of your input from the previous phase. > > ? > > We encourage you to read the proposal, impact analysis and draft document and to send any comments to > address-policy-wg at ripe.net before 2 May 2023. > > ? > > ? > > Kind regards, > > ? > > Angela Dall'Ara > > Policy Officer > > RIPE NCC > > -- > > To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: > https://mailman.ripe.net/ > > > From cfriacas at fccn.pt Wed Apr 26 10:35:46 2023 From: cfriacas at fccn.pt (=?ISO-8859-15?Q?Carlos_Fria=E7as?=) Date: Wed, 26 Apr 2023 09:35:46 +0100 (WEST) Subject: [address-policy-wg] 2023-01 - New Version Policy Proposal (Reducing IXP IPv4 assignment default size to a /26) In-Reply-To: References: <281efcf3-c3d2-b8c1-f914-b4969ec12b04@ripe.net> <3b97d0eb-5aa6-3e7e-9ed-adc5f82e88cf@fccn.pt> Message-ID: <2de4ee0-a7cf-32b4-a72c-8262c6143326@fccn.pt> On Wed, 26 Apr 2023, Gert Doering wrote: > "not *really* operating as IXP" is usually open for long discussions... Agree. I won't go there, as i don't want to draft a new proposal :-))) Cheers, Carlos > gert > -- > 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 nick at foobar.org Wed Apr 26 16:59:59 2023 From: nick at foobar.org (Nick Hilliard) Date: Wed, 26 Apr 2023 17:59:59 +0300 Subject: [address-policy-wg] 2023-01 - New Version Policy Proposal (Reducing IXP IPv4 assignment default size to a /26) In-Reply-To: <281efcf3-c3d2-b8c1-f914-b4969ec12b04@ripe.net> References: <281efcf3-c3d2-b8c1-f914-b4969ec12b04@ripe.net> Message-ID: <53dfc57e-dff2-d252-e58b-3cae26ae3373@foobar.org> Angela Dall'Ara wrote on 06/03/2023 10:43: > As per the RIPE Policy Development Process (PDP), the purpose of this > four-week Discussion Phase is to discuss the proposal and provide > feedback to the proposer. two issues: - I can't work out what the proposed new section 7 is saying. - there are a bunch of problematic edge cases associated with section 5. E.g. what happens if an IXP has a /23 and has 254 IP addresses used after 1Y? They will be obliged to downgrade to a /24, according to the current text.? Also I don't know what a special circumstance is. The problems in section 5 can be fixed easily, but it depends on how the authors want to handle assignment upgrades / renumberings. I'd suggest either dropping the 1Y utilisation requirement to e.g. 40%, or else that if you reach e.g. 80% current usage, you qualify to receive an assignment of 2x the current, up to /22.? Those figures are plucked out of the air btw. The point with them is that they are not 50%, which is obviously a magic number when the natural increase of assignment size would be to double the size of the block. Nick -------------- next part -------------- An HTML attachment was scrubbed... URL: