From nick at foobar.org Tue Feb 7 12:01:24 2023 From: nick at foobar.org (Nick Hilliard) Date: Tue, 7 Feb 2023 11:01:24 +0000 Subject: [address-policy-wg] 2023-01 New Policy Proposal (Reducing IXP IPv4 assignment default size to a /26) In-Reply-To: <79b6bc20-7a68-3e06-34d4-c6da16a4e0e8@ripe.net> References: <79b6bc20-7a68-3e06-34d4-c6da16a4e0e8@ripe.net> Message-ID: <0d17b589-2ba5-9538-960b-828b5860dcf8@foobar.org> Angela Dall'Ara wrote on 09/01/2023 10:40: > 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. not sure if this comment is in time, but the text contains: > Assignments strictly larger than a /24 will only be made to IXPs that > offer the exchange of IPv4 routing information over IPv6 at their > route servers As far as I understand, this protocol is not widely deployed in IXPs, nor is it widely tested in inter-AS production environments. It would be concerning if an untested protocol were mandated as a production requirement in a RIR addressing policy document. Before continuing down this path, could the authors provide information on how this protocol works in production environments? Nick From matthias.wichtlhuber at de-cix.net Wed Feb 8 14:36:13 2023 From: matthias.wichtlhuber at de-cix.net (Matthias Wichtlhuber) Date: Wed, 8 Feb 2023 13:36:13 +0000 Subject: [address-policy-wg] 2023-01 New Policy Proposal (Reducing IXP IPv4 assignment default size to a /26) In-Reply-To: <0d17b589-2ba5-9538-960b-828b5860dcf8@foobar.org> References: <79b6bc20-7a68-3e06-34d4-c6da16a4e0e8@ripe.net>, <0d17b589-2ba5-9538-960b-828b5860dcf8@foobar.org> Message-ID: Hi Nick, > As far as I understand, this protocol is not widely deployed in IXPs, > nor is it widely tested in inter-AS production environments. It would be > concerning if an untested protocol were mandated as a production > requirement in a RIR addressing policy document. > Before continuing down this path, could the authors provide information > on how this protocol works in production environments? This part of the proposal is intended to foster the adoption of the technology. IXPs may offer it as beta or experimental while still doing the actual exchange of traffic via standard BGP over IPv4. We are aware this is part controversial; we can remove it if the community thinks this is a bad idea. Matthias -- Dr.-Ing. Matthias Wichtlhuber Senior Researcher ------------------------------ DE-CIX Management GmbH Lindleystr. 12, 60314 Frankfurt (Germany) phone: +49 69 1730902 141 mobile: +49 171 3836036 fax: +49 69 4056 2716 e-mail: matthias.wichtlhuber at de-cix.net web: www.de-cix.net ------------------------------ DE-CIX Management GmbH Executive Directors: Ivaylo Ivanov and Sebastian Seifert Trade registry: District court (Amtsgericht) Cologne, HRB 51135 Registered office: Lichtstr. 43i, 50825 Cologne ------------------------------ DE-CIX 25th anniversary: Without you the Internet would not be the same! Join us on the journey at https://withoutyou.de-cix.net ________________________________________ Von: address-policy-wg im Auftrag von Nick Hilliard Gesendet: Dienstag, 7. Februar 2023 12:01:24 An: Angela Dall'Ara Cc: RIPE Address Policy Working Group Betreff: Re: [address-policy-wg] 2023-01 New Policy Proposal (Reducing IXP IPv4 assignment default size to a /26) Angela Dall'Ara wrote on 09/01/2023 10:40: > 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. not sure if this comment is in time, but the text contains: > Assignments strictly larger than a /24 will only be made to IXPs that > offer the exchange of IPv4 routing information over IPv6 at their > route servers As far as I understand, this protocol is not widely deployed in IXPs, nor is it widely tested in inter-AS production environments. It would be concerning if an untested protocol were mandated as a production requirement in a RIR addressing policy document. Before continuing down this path, could the authors provide information on how this protocol works in production environments? Nick -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://mailman.ripe.net/ From sander at steffann.nl Wed Feb 8 16:23:51 2023 From: sander at steffann.nl (Sander Steffann) Date: Wed, 8 Feb 2023 16:23:51 +0100 Subject: [address-policy-wg] 2023-01 New Policy Proposal (Reducing IXP IPv4 assignment default size to a /26) In-Reply-To: References: <79b6bc20-7a68-3e06-34d4-c6da16a4e0e8@ripe.net> <0d17b589-2ba5-9538-960b-828b5860dcf8@foobar.org> Message-ID: <9277B8C7-B648-45B7-B145-E9FE208D3343@steffann.nl> Hi, >>> Assignments strictly larger than a /24 will only be made to IXPs that >>> offer the exchange of IPv4 routing information over IPv6 at their >>> route servers >> >> As far as I understand, this protocol is not widely deployed in IXPs, >> nor is it widely tested in inter-AS production environments. It would be >> concerning if an untested protocol were mandated as a production >> requirement in a RIR addressing policy document. >> >> Before continuing down this path, could the authors provide information >> on how this protocol works in production environments? > > This part of the proposal is intended to foster the adoption of the technology. > IXPs may offer it as beta or experimental while still doing the actual exchange > of traffic via standard BGP over IPv4. Doesn?t the way this policy is written defeat the purpose of using IPv6 to exchange IPv4 routing information? Only those who can use IPv6 (and arguable therefore don?t need IPv4 anymore) can get more IPv4 space? > We are aware this is part controversial; we can remove it if the community thinks > this is a bad idea. Putting controversial stuff is address policy is usually not a good idea. In my opinion address policy has to provide what is needed for a super stable environment. Enforcing the use of less tested or experimental protocols doesn?t fit with that. Now, I totally understand the chicken and egg problem here: as long as IXPs get IPv4 addresses there will be no need to exchange IPv4 routing information over IPv6. But until that has been properly tested we continue to give them IPv4 space. But let?s not put in artificial restrictions to make them test it. If the real reason is that we don?t have enough IPv4 space to give to IXPs in the future, then let?s make *that* clear. Like: ?From IXPs will no longer be able to grow their IPv4 assignment beyond . IXPs that anticipate needing to grow larger than this are strongly encouraged to start testing with exchanging IPv4 routing information over IPv6?. The cutoff date may be a little arbitrary (I?m sure the NCC can give reasonable predictions to base it on) but at least it matches with reality :) Cheers, Sander From randy at psg.com Wed Feb 8 18:44:13 2023 From: randy at psg.com (Randy Bush) Date: Wed, 08 Feb 2023 09:44:13 -0800 Subject: [address-policy-wg] 2023-01 New Policy Proposal (Reducing IXP IPv4 assignment default size to a /26) In-Reply-To: References: <79b6bc20-7a68-3e06-34d4-c6da16a4e0e8@ripe.net> Message-ID: > This part of the proposal is intended to foster the adoption of the > technology. i think they should not get space unless they serve me a really tasty paella or, less obliquely, could we please keep religion out of operating the internet? randy From farmer at umn.edu Wed Feb 8 19:26:16 2023 From: farmer at umn.edu (David Farmer) Date: Wed, 8 Feb 2023 12:26:16 -0600 Subject: [address-policy-wg] 2023-01 New Policy Proposal (Reducing IXP IPv4 assignment default size to a /26) In-Reply-To: <9277B8C7-B648-45B7-B145-E9FE208D3343@steffann.nl> References: <79b6bc20-7a68-3e06-34d4-c6da16a4e0e8@ripe.net> <0d17b589-2ba5-9538-960b-828b5860dcf8@foobar.org> <9277B8C7-B648-45B7-B145-E9FE208D3343@steffann.nl> Message-ID: On Wed, Feb 8, 2023 at 9:24 AM Sander Steffann wrote: > > Now, I totally understand the chicken and egg problem here: as long as > IXPs get IPv4 addresses there will be no need to exchange IPv4 routing > information over IPv6. But until that has been properly tested we continue > to give them IPv4 space. But let?s not put in artificial restrictions to > make them test it. If the real reason is that we don?t have enough IPv4 > space to give to IXPs in the future, then let?s make *that* clear. > > Like: ?From IXPs will no longer be able to grow > their IPv4 assignment beyond . IXPs that > anticipate needing to grow larger than this are strongly encouraged to > start testing with exchanging IPv4 routing information over IPv6?. > > The cutoff date may be a little arbitrary (I?m sure the NCC can give > reasonable predictions to base it on) but at least it matches with reality > :) > I generally support the idea above. However, reviewing this and the previous thread leading up to this policy proposal, I haven't seen any projected runout dates for the current IXP pool. Therefore, can we get projected runout dates based on the current and proposed minimum IXP allocation sizes? We can use that to inform the selection of a date in the above suggestion, presumably picking a date sometime short of the projected runout. Thanks -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: From nick at foobar.org Wed Feb 8 21:47:48 2023 From: nick at foobar.org (Nick Hilliard) Date: Wed, 8 Feb 2023 20:47:48 +0000 Subject: [address-policy-wg] 2023-01 New Policy Proposal (Reducing IXP IPv4 assignment default size to a /26) In-Reply-To: References: <79b6bc20-7a68-3e06-34d4-c6da16a4e0e8@ripe.net> <0d17b589-2ba5-9538-960b-828b5860dcf8@foobar.org> Message-ID: <345aef28-721c-258e-7250-df04f902c252@foobar.org> Matthias Wichtlhuber wrote on 08/02/2023 13:36: > This part of the proposal is intended to foster the adoption of the technology. > IXPs may offer it as beta or experimental while still doing the actual exchange > of traffic via standard BGP over IPv4. Hi Matthias, this is premature: if the protocol didn't work well in production environments, that would raise questions about the wisdom of mandating the protocol in the first place. In any event, as Randy pointed out, it's generally not a good idea to use policy in one area to try to force specific technology choices in another. Nick From shane at time-travellers.org Wed Feb 8 23:35:12 2023 From: shane at time-travellers.org (Shane Kerr) Date: Wed, 8 Feb 2023 23:35:12 +0100 Subject: [address-policy-wg] 2023-01 New Policy Proposal (Reducing IXP IPv4 assignment default size to a /26) In-Reply-To: <79b6bc20-7a68-3e06-34d4-c6da16a4e0e8@ripe.net> References: <79b6bc20-7a68-3e06-34d4-c6da16a4e0e8@ripe.net> Message-ID: <757d1d2a-62f4-125f-58fa-2634663c1896@time-travellers.org> Colleagues, On 09/01/2023 11.40, Angela Dall'Ara wrote: > > A new RIPE Policy Proposal, 2023-01, "Reducing IXP IPv4 assignment > default size to a /26" > is now available for discussion. > > The goal of this proposal is to extend the lifetime of the IXP IPv4 > address pool and to motivate IXPs to implement the exchange of IPv4 > routing information over IPv6. > We encourage you to review this proposal and send your comments to > address-policy-wg at ripe.net before 7 February 2023. Sorry I missed the deadline. If I recall correctly, the original motivation of the IXP policy was to allow IXP to get space, even if they did not otherwise qualify to become an LIR. This was so that they could maintain independence from LIR peering at the IXP. However, there are basically no restrictions on becoming an LIR, and basically no space available. So there is no reason for a special IXP policy. My own preference is that we stop IXP IPv4 assignments completely. IXP can purchase IPv4 space on the open market the same as everyone else. Cheers, -- Shane -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_0x3732979CF967B306.asc Type: application/pgp-keys Size: 11519 bytes Desc: OpenPGP public key URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 840 bytes Desc: OpenPGP digital signature URL: From matthias.wichtlhuber at de-cix.net Thu Feb 9 09:23:27 2023 From: matthias.wichtlhuber at de-cix.net (Matthias Wichtlhuber) Date: Thu, 9 Feb 2023 08:23:27 +0000 Subject: [address-policy-wg] 2023-01 New Policy Proposal (Reducing IXP IPv4 assignment default size to a /26) In-Reply-To: <345aef28-721c-258e-7250-df04f902c252@foobar.org> References: <79b6bc20-7a68-3e06-34d4-c6da16a4e0e8@ripe.net> <0d17b589-2ba5-9538-960b-828b5860dcf8@foobar.org> , <345aef28-721c-258e-7250-df04f902c252@foobar.org> Message-ID: Hi Nick, Randy, David, Sander, (all,) agreed, we will remove this part from the proposal. @David: there was prediction by Marco Schmidt from RIPE at the last meeting. It is linked in the proposal. Regards, Matthias -- Dr.-Ing. Matthias Wichtlhuber Senior Researcher ------------------------------ DE-CIX Management GmbH Lindleystr. 12, 60314 Frankfurt (Germany) phone: +49 69 1730902 141 mobile: +49 171 3836036 fax: +49 69 4056 2716 e-mail: matthias.wichtlhuber at de-cix.net web: www.de-cix.net ------------------------------ DE-CIX Management GmbH Executive Directors: Ivaylo Ivanov and Sebastian Seifert Trade registry: District court (Amtsgericht) Cologne, HRB 51135 Registered office: Lichtstr. 43i, 50825 Cologne ------------------------------ DE-CIX 25th anniversary: Without you the Internet would not be the same! Join us on the journey at https://withoutyou.de-cix.net ________________________________________ Von: Nick Hilliard Gesendet: Mittwoch, 8. Februar 2023 21:47:48 An: Matthias Wichtlhuber Cc: Angela Dall'Ara; RIPE Address Policy Working Group Betreff: Re: AW: [address-policy-wg] 2023-01 New Policy Proposal (Reducing IXP IPv4 assignment default size to a /26) Matthias Wichtlhuber wrote on 08/02/2023 13:36: > This part of the proposal is intended to foster the adoption of the technology. > IXPs may offer it as beta or experimental while still doing the actual exchange > of traffic via standard BGP over IPv4. Hi Matthias, this is premature: if the protocol didn't work well in production environments, that would raise questions about the wisdom of mandating the protocol in the first place. In any event, as Randy pointed out, it's generally not a good idea to use policy in one area to try to force specific technology choices in another. Nick From adallara at ripe.net Thu Feb 9 09:26:06 2023 From: adallara at ripe.net (Angela Dall'Ara) Date: Thu, 9 Feb 2023 09:26:06 +0100 Subject: [address-policy-wg] 2023-02 New Policy Proposal (Minimum Size for IPv4 Temporary Assignments) Message-ID: Dear colleagues, A new RIPE Policy Proposal, 2023-02, "Minimum Size for IPv4 Temporary Assignments" is now available for discussion. This policy proposal recommends setting the minimum assignment size for 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. You can find the full proposal at: https://www.ripe.net/participate/policies/proposals/2023-02 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 proposers. 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 10 March 2023. Kind regards, Angela Dall'Ara Policy Officer RIPE NCC From gert at space.net Thu Feb 9 09:28:57 2023 From: gert at space.net (Gert Doering) Date: Thu, 9 Feb 2023 09:28:57 +0100 Subject: [address-policy-wg] 2023-01 New Policy Proposal (Reducing IXP IPv4 assignment default size to a /26) In-Reply-To: References: <79b6bc20-7a68-3e06-34d4-c6da16a4e0e8@ripe.net> <0d17b589-2ba5-9538-960b-828b5860dcf8@foobar.org> <345aef28-721c-258e-7250-df04f902c252@foobar.org> Message-ID: Hi, On Thu, Feb 09, 2023 at 08:23:27AM +0000, Matthias Wichtlhuber wrote: > Hi Nick, Randy, David, Sander, (all,) > > agreed, we will remove this part from the proposal. I actually do like this push, and it's not the first time we've done policy to push "non-progress" elsewhere (32 bit ASNs "by default"). OTOH, without this clause, IXPs will notice "there is no more IPv4 space, so maybe we need to do something else", and then it will be a bit late to start researching - so maybe this is something people from the IXP community (EuroIX?) can start working on, *together with the usual vendors*, to make sure this stuff actually works when the IXPs need it, and there is good documentation for the IXP members "how to make it work on their gear"... 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 wolfgang.tremmel at de-cix.net Thu Feb 9 10:01:49 2023 From: wolfgang.tremmel at de-cix.net (Wolfgang Tremmel) Date: Thu, 9 Feb 2023 09:01:49 +0000 Subject: [address-policy-wg] 2023-01 New Policy Proposal (Reducing IXP IPv4 assignment default size to a /26) In-Reply-To: References: <79b6bc20-7a68-3e06-34d4-c6da16a4e0e8@ripe.net> <0d17b589-2ba5-9538-960b-828b5860dcf8@foobar.org> <345aef28-721c-258e-7250-df04f902c252@foobar.org> Message-ID: <43A60836-97D8-4992-8590-2A181B740251@de-cix.net> AS196610 is happy to take peers at any exchange I am present to try this out. I already have it working on two private connections. It works, it just can be awkward to configure (on my side, its just a tag in peering manager to set it up) I also have a slide deck ready to explain it. Video will be next. Get Popcorn. best regards Wolfgang > On 9. Feb 2023, at 09:28, Gert Doering wrote: > > to start researching - so maybe this is something people from the IXP > community (EuroIX?) can start working on, *together with the usual > vendors*, to make sure this stuff actually works when the IXPs need it, > and there is good documentation for the IXP members "how to make it > work on their gear"... -- Wolfgang Tremmel Phone +49 69 1730902 0 | wolfgang.tremmel at de-cix.net Executive Directors: Ivaylo Ivanov and Sebastian Seifert | Trade Registry: AG Cologne, HRB 51135 DE-CIX Management GmbH | Lindleystrasse 12 | 60314 Frankfurt am Main | Germany | www.de-cix.net From gert at space.net Thu Feb 9 10:33:40 2023 From: gert at space.net (Gert Doering) Date: Thu, 9 Feb 2023 10:33:40 +0100 Subject: [address-policy-wg] 2023-01 New Policy Proposal (Reducing IXP IPv4 assignment default size to a /26) In-Reply-To: <43A60836-97D8-4992-8590-2A181B740251@de-cix.net> References: <79b6bc20-7a68-3e06-34d4-c6da16a4e0e8@ripe.net> <0d17b589-2ba5-9538-960b-828b5860dcf8@foobar.org> <345aef28-721c-258e-7250-df04f902c252@foobar.org> <43A60836-97D8-4992-8590-2A181B740251@de-cix.net> Message-ID: Hi, On Thu, Feb 09, 2023 at 09:01:49AM +0000, Wolfgang Tremmel wrote: > AS196610 is happy to take peers at any exchange I am present to try this out. > > I already have it working on two private connections. > It works, it just can be awkward to configure (on my side, its just a tag in peering manager to set it up) > > I also have a slide deck ready to explain it. Video will be next. Get Popcorn. Impressive! :-) Looking forward to the slide deck, especially to the section "on vendor X, you need yz... to make it work" (and/or "vendor Z does not understand what we want them to do"...). 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 nick at foobar.org Thu Feb 9 11:52:15 2023 From: nick at foobar.org (Nick Hilliard) Date: Thu, 9 Feb 2023 10:52:15 +0000 Subject: [address-policy-wg] 2023-01 New Policy Proposal (Reducing IXP IPv4 assignment default size to a /26) In-Reply-To: References: <79b6bc20-7a68-3e06-34d4-c6da16a4e0e8@ripe.net> <0d17b589-2ba5-9538-960b-828b5860dcf8@foobar.org> <345aef28-721c-258e-7250-df04f902c252@foobar.org> Message-ID: <97c39946-dc8a-968d-1e37-65d141e000e4@foobar.org> Gert Doering wrote on 09/02/2023 08:28: > OTOH, without this clause, IXPs will notice "there is no more IPv4 space, > so maybe we need to do something else", and then it will be a bit late > to start researching - so maybe this is something people from the IXP > community (EuroIX?) can start working on, *together with the usual > vendors*, to make sure this stuff actually works when the IXPs need it, > and there is good documentation for the IXP members "how to make it > work on their gear"... No doubt at some point in the future, this will work reasonably well. In the interim, it will be fertile territory for difficult-to-diagnose forwarding bugs, i.e. the class of bugs that gives the night terrors to both device software/firmware developers and network operators. We're no longer in a world where it's viable to deploy untested and experimental L3 packet forwarding features in IXPs. NISD2 is just around the corner, which will categorise all IXPs in the EU region as Essential Entities - the equivalent of Operators of Essential Services in NISD1. I.e. IXPs will shortly be regulated entities. If enabling rfc8950 caused an IXP to blackhole traffic for a couple of million people, how would it work explaining it to a regulator that the root cause for this outage was an experimental baseline forwarding feature, mandated by an addressing policy and enforced by the RIPE NCC? RFC8950 will have its place in the toolbox, but we're not there yet. Nick From gert at space.net Thu Feb 9 12:00:54 2023 From: gert at space.net (Gert Doering) Date: Thu, 9 Feb 2023 12:00:54 +0100 Subject: [address-policy-wg] 2023-01 New Policy Proposal (Reducing IXP IPv4 assignment default size to a /26) In-Reply-To: <97c39946-dc8a-968d-1e37-65d141e000e4@foobar.org> References: <79b6bc20-7a68-3e06-34d4-c6da16a4e0e8@ripe.net> <0d17b589-2ba5-9538-960b-828b5860dcf8@foobar.org> <345aef28-721c-258e-7250-df04f902c252@foobar.org> <97c39946-dc8a-968d-1e37-65d141e000e4@foobar.org> Message-ID: Hi, On Thu, Feb 09, 2023 at 10:52:15AM +0000, Nick Hilliard wrote: > We're no longer in a world where it's viable to deploy untested and > experimental L3 packet forwarding features in IXPs. NISD2 is just > around the corner, which will categorise all IXPs in the EU region as > Essential Entities - the equivalent of Operators of Essential Services > in NISD1. I.e. IXPs will shortly be regulated entities. I hear you, but that argument can be twisted around into "why are you not permitting access to new market entrants to your IXP? don't tell me stories about 'no IPv4 addresses for the fabric', you had enough time to prepare"... So, if there are no more v4 addresses in the RIPE NCC IXP pool, some unpleasantness will ensue, no matter what. (But I do agree that "testing and education" can be done nicely outside the policy) 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 jameskennedy001 at gmail.com Thu Feb 9 14:44:01 2023 From: jameskennedy001 at gmail.com (James Kennedy) Date: Thu, 9 Feb 2023 14:44:01 +0100 Subject: [address-policy-wg] End of Discussion Phase for 2023-01 (Reducing IXP IPv4 assignment default size to a /26) Message-ID: Dear WG, The Discussion Phase of policy proposal 2023-01 "Reducing IXP IPv4 assignment default size to a /26" has now ended. Many thanks to all for your comments. Taking into consideration the community feedback, the proposers have drafted a new version of the proposal. The RIPE NCC will soon publish the new version on the mailing list and kick-off a new Discussion Phase as per the PDP: https://www.ripe.net/publications/docs/ripe-781. Regards, James From leo at vegoda.org Wed Feb 15 13:21:46 2023 From: leo at vegoda.org (Leo Vegoda) Date: Wed, 15 Feb 2023 07:21:46 -0500 Subject: [address-policy-wg] IPv6 policy - prioritisation and outcomes discussion webinar In-Reply-To: References: Message-ID: Hi, Just a reminder that we'll run this session next Monday, 20 February 2023 at 13:00 UTC (14:00 CET). Please put this in your calendar if you want to be involved in planning our IPv6 policy development work. Kind regards, Leo Vegoda for the Address Policy WG co-chairs On Thu, 26 Jan 2023 at 13:14, Leo Vegoda 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. > > The identified areas for improvement include: > - Better guidance on documentation requirements for large allocations > - Simpler language for the HD-ratio > - Make it easier for small networks to assign a few addresses to other > organisations > - Ensure allocations always fall on a nibble boundary > > If you wants to help us set priorities and define the outcomes the > community needs you are welcome to join. > > Monday, 20 February 2023 at 13:00 UTC (14:00 CET). > > Join Zoom Meeting > https://ripe.zoom.us/j/94307989734?pwd=YytnQm53SjJEWUtKemxQM3dGcjZmQT09 > > Meeting ID: 943 0798 9734 > Passcode: 339420 > > Leo Vegoda > for the Address Policy WG co-chairs From LeeHoward at hilcostreambank.com Thu Feb 16 19:52:49 2023 From: LeeHoward at hilcostreambank.com (Howard, Lee) Date: Thu, 16 Feb 2023 18:52:49 +0000 Subject: [address-policy-wg] 2023-01 New Policy Proposal (Reducing IXP IPv4 assignment default size to a /26) In-Reply-To: <757d1d2a-62f4-125f-58fa-2634663c1896@time-travellers.org> References: <79b6bc20-7a68-3e06-34d4-c6da16a4e0e8@ripe.net> <757d1d2a-62f4-125f-58fa-2634663c1896@time-travellers.org> Message-ID: -----Original Message----- From: address-policy-wg On Behalf Of Shane Kerr Sent: Wednesday, February 8, 2023 5:35 PM To: address-policy-wg at ripe.net Subject: Re: [address-policy-wg] 2023-01 New Policy Proposal (Reducing IXP IPv4 assignment default size to a /26) > If I recall correctly, the original motivation of the IXP policy was to allow IXP to get space, even if they did not otherwise > qualify to become an LIR. This was so that they could maintain independence from LIR peering at the IXP. > However, there are basically no restrictions on becoming an LIR, and basically no space available. So there is no reason > for a special IXP policy. > My own preference is that we stop IXP IPv4 assignments completely. IXP can purchase IPv4 space on the open market > the same as everyone else. > Shane I don't typically comment on address policy because it might look self-serving, but someone asked me to comment. Thinking about the costs to set up an IXP, I went back to this RIPE presentation a few years ago: "The $1,000 Internet Exchange" https://ripe71.ripe.net/presentations/30-1000-dollar-exchange-ripe71.pdf Market price for a /24 might be high enough to prevent an IXP from forming. Even a significant subnet might be expensive, and that's if someone was willing and able to sell a /26. Lee From fearghas at gmail.com Fri Feb 17 01:38:04 2023 From: fearghas at gmail.com (Fearghas Mckay) Date: Thu, 16 Feb 2023 19:38:04 -0500 Subject: [address-policy-wg] 2023-01 New Policy Proposal (Reducing IXP IPv4 assignment default size to a /26) In-Reply-To: <757d1d2a-62f4-125f-58fa-2634663c1896@time-travellers.org> References: <79b6bc20-7a68-3e06-34d4-c6da16a4e0e8@ripe.net> <757d1d2a-62f4-125f-58fa-2634663c1896@time-travellers.org> Message-ID: Hi > On 8 Feb 2023, at 17:35, Shane Kerr wrote: > > If I recall correctly, the original motivation of the IXP policy was to allow IXP to get space, even if they did not otherwise qualify to become an LIR. This was so that they could maintain independence from LIR peering at the IXP. As the chair of the EIX-WG at the time which generated the policy, rather than AP, the rationale was about ensuring that there would be space for IXP fabric as v4 ran out. That was the driver, not the inability of IXPs to afford LIR membership etc. Only IPv4 run out. FWIW I do not support this policy as written and expecting starter IXPs to go to the open market is not the kind of policy that is my understanding of the RIPE way. Thanks f -------------- next part -------------- An HTML attachment was scrubbed... URL: From leo at vegoda.org Mon Feb 27 16:44:19 2023 From: leo at vegoda.org (Leo Vegoda) Date: Mon, 27 Feb 2023 07:44:19 -0800 Subject: [address-policy-wg] 2023-02 New Policy Proposal (Minimum Size for IPv4 Temporary Assignments) In-Reply-To: References: Message-ID: Hi, We've not had any feedback on this proposal yet. As a reminder, this proposal would set "the minimum assignment size 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." Support for the proposal, or arguments against it are welcome. Many thanks, Leo Vegoda Address Policy WG co-chair On Thu, 9 Feb 2023 at 00:26, Angela Dall'Ara wrote: > > Dear colleagues, > > A new RIPE Policy Proposal, 2023-02, "Minimum Size for IPv4 Temporary > Assignments" > is now available for discussion. > > This policy proposal recommends setting the minimum assignment size for > 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. > > You can find the full proposal at: > https://www.ripe.net/participate/policies/proposals/2023-02 > > 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 proposers. > > 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 10 March 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 randy at psg.com Mon Feb 27 22:33:35 2023 From: randy at psg.com (Randy Bush) Date: Mon, 27 Feb 2023 13:33:35 -0800 Subject: [address-policy-wg] 2023-02 New Policy Proposal (Minimum Size for IPv4 Temporary Assignments) In-Reply-To: References: Message-ID: leo > As a reminder, this proposal would set "the minimum assignment size to > a /24 while still allowing for a smaller assignment if requested by > the End User. i tried a similar proposal some years back. it was shot down. so i guess i have to support this incarnation. good luck. ( i have schadenfreude that ipv6's hope for success is schadenfreude about ipv4 :) randy