From mschmidt at ripe.net Mon Feb 4 13:04:26 2019 From: mschmidt at ripe.net (Marco Schmidt) Date: Mon, 4 Feb 2019 13:04:26 +0100 Subject: [address-policy-wg] 2019-02 New Policy Proposal (Reducing IPv4 Allocations to a /24) Message-ID: Dear colleagues, A new RIPE Policy proposal, 2019-02, "Reducing IPv4 Allocations to a /24" is now available for discussion. This proposal aims to reduce the IPv4 allocation size to a /24 once the RIPE NCC is unable to allocate contiguous /22 ranges. You can find the full proposal at: https://www.ripe.net/participate/policies/proposals/2019-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 proposer. At the end of the Discussion Phase, the proposer, with the agreement of the WG Chairs, will decide how to proceed with the proposal. We encourage you to review this proposal and send your comments to before 5 March 2019. Regards, Marco Schmidt Policy Officer From ripe at liopen.fr Mon Feb 4 13:41:40 2019 From: ripe at liopen.fr (Denis Fondras) Date: Mon, 4 Feb 2019 13:41:40 +0100 Subject: [address-policy-wg] 2019-02 New Policy Proposal (Reducing IPv4 Allocations to a /24) In-Reply-To: References: Message-ID: <20190204124140.GV56439@carcass.ledeuns.net> This sounds reasonable to me. Newcomers can still get a share while transitionning to IPv6 :) Is there an incentive to make ops accept longer-than-/24 as a next step ? On Mon, Feb 04, 2019 at 01:04:26PM +0100, Marco Schmidt wrote: > Dear colleagues, > > A new RIPE Policy proposal, 2019-02, "Reducing IPv4 Allocations to a /24" > is now available for discussion. > > This proposal aims to reduce the IPv4 allocation size to a /24 once the > RIPE NCC is unable to allocate contiguous /22 ranges. > > You can find the full proposal at: > https://www.ripe.net/participate/policies/proposals/2019-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 proposer. > > At the end of the Discussion Phase, the proposer, with the agreement of > the WG Chairs, will decide how to proceed with the proposal. > > We encourage you to review this proposal and send your comments to > before 5 March 2019. > > Regards, > > Marco Schmidt > Policy Officer > > -- Denis Fondras / Liopen T?l: +33.473.422.720 Mob: +33.761.029.186 M?l: contact at liopen.fr JID: denis at liopen.fr PGP: 0xF7D4828559706135 From raymond.jetten at elisa.fi Mon Feb 4 13:44:13 2019 From: raymond.jetten at elisa.fi (Jetten Raymond) Date: Mon, 4 Feb 2019 12:44:13 +0000 Subject: [address-policy-wg] 2019-02 New Policy Proposal (Reducing IPv4 Allocations to a /24) In-Reply-To: References: Message-ID: Hi, I strongly oppose this proposal, a similar proposal was mode before, (2017-03) , and I agree with the arguments opposing the proposal. Rgds, Ray -----Original Message----- From: address-policy-wg On Behalf Of Marco Schmidt Sent: 4. helmikuuta 2019 14:04 To: address-policy-wg at ripe.net Subject: [address-policy-wg] 2019-02 New Policy Proposal (Reducing IPv4 Allocations to a /24) Dear colleagues, A new RIPE Policy proposal, 2019-02, "Reducing IPv4 Allocations to a /24" is now available for discussion. This proposal aims to reduce the IPv4 allocation size to a /24 once the RIPE NCC is unable to allocate contiguous /22 ranges. You can find the full proposal at: https://www.ripe.net/participate/policies/proposals/2019-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 proposer. At the end of the Discussion Phase, the proposer, with the agreement of the WG Chairs, will decide how to proceed with the proposal. We encourage you to review this proposal and send your comments to before 5 March 2019. Regards, Marco Schmidt Policy Officer From sander at steffann.nl Mon Feb 4 13:58:37 2019 From: sander at steffann.nl (Sander Steffann) Date: Mon, 4 Feb 2019 13:58:37 +0100 Subject: [address-policy-wg] 2019-02 New Policy Proposal (Reducing IPv4 Allocations to a /24) In-Reply-To: <20190204124140.GV56439@carcass.ledeuns.net> References: <20190204124140.GV56439@carcass.ledeuns.net> Message-ID: Hi Denis, > This sounds reasonable to me. > Newcomers can still get a share while transitionning to IPv6 :) > > Is there an incentive to make ops accept longer-than-/24 as a next step ? No, at the last RIPE meeting consensus was that longer-than-/24 was not worth it. Cheers, Sander From Piotr.Strzyzewski at polsl.pl Mon Feb 4 14:11:01 2019 From: Piotr.Strzyzewski at polsl.pl (Piotr Strzyzewski) Date: Mon, 4 Feb 2019 14:11:01 +0100 Subject: [address-policy-wg] 2019-02 New Policy Proposal (Reducing IPv4 Allocations to a /24) In-Reply-To: References: Message-ID: <20190204131101.GB17817@hydra.ck.polsl.pl> On Mon, Feb 04, 2019 at 12:44:13PM +0000, Jetten Raymond wrote: Dear WG members > I strongly oppose this proposal, a similar proposal was mode before, (2017-03) , > and I agree with the arguments opposing the proposal. I share Raymonds point of view. Piotr -- Piotr Strzy?ewski Silesian University of Technology, Computer Centre Gliwice, Poland From sander at steffann.nl Mon Feb 4 14:11:03 2019 From: sander at steffann.nl (Sander Steffann) Date: Mon, 4 Feb 2019 14:11:03 +0100 Subject: [address-policy-wg] 2019-02 New Policy Proposal (Reducing IPv4 Allocations to a /24) In-Reply-To: References: Message-ID: Hi Raymond, > I strongly oppose this proposal, a similar proposal was mode before, (2017-03) , > and I agree with the arguments opposing the proposal. 2017-03 was a different kind of proposal. At that time the choice was between handing out /22 or handing out /24 to all new LIRs. While I did think back then that this was a good idea I understood the reasons against that proposal. LIRs that would get a /22 under the old policy would then get a /24, making things worse for those LIRs. It would also delay the moment that the NCC would hit the bottom by a very long time, therefore potentially giving the impression that IPv4 was still available. Your concluding argument for that proposal was "A /22 is not even enough, let alone a /24 to yet connect to the "dark ages of the IPv4 internet", not now and unfortunately not in the future either...". And at the time that was a valid argument, because of those LIRs that otherwise would get a /22. For this proposal the circumstances have changed though. Now the choice is between giving the new LIRs that come after the /22s have run out a /24 or nothing at all. The analysis from the NCC has shown that if we make a waiting list with /22s the queue will grow indefinitely, which means that the vast majority of the LIRs will never get anything at all. With a /24 allocation size the waiting list becomes manageable and more predictable. I don't think that choosing to give them nothing when we could have given them a /24 is a reasonable argument at the point in time when we have already run out of /22s... Cheers, Sander From francis.brosnan at aspl.es Mon Feb 4 14:14:59 2019 From: francis.brosnan at aspl.es (Francis Brosnan =?ISO-8859-1?Q?Bl=E1zquez?=) Date: Mon, 04 Feb 2019 14:14:59 +0100 Subject: [address-policy-wg] 2019-02 New Policy Proposal (Reducing IPv4 Allocations to a /24) In-Reply-To: References: <20190204124140.GV56439@carcass.ledeuns.net> Message-ID: <1549286099.28715.34.camel@aspl.es> Hello. We do not agree with this proposal. Sooner or later RIPE IPv4 address space will run out. Moving from /22 to /24 will not change that, which is the essence of the question, but doing so will create more fragmentation (BGP, smaller LIRS, cost unfairness between members...). In practical terms, we believe this will also boost IP broker market (the smaller the blocks, the stronger IP brokers will get). Current policy is a good compromise: it focus on allocating to LIRs that assign and use address space ...until no more allocation can be done. Best Regards. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jim at rfc1035.com Mon Feb 4 14:21:13 2019 From: jim at rfc1035.com (Jim Reid) Date: Mon, 4 Feb 2019 13:21:13 +0000 Subject: [address-policy-wg] 2019-02 New Policy Proposal (Reducing IPv4 Allocations to a /24) In-Reply-To: <1549286099.28715.34.camel@aspl.es> References: <20190204124140.GV56439@carcass.ledeuns.net> <1549286099.28715.34.camel@aspl.es> Message-ID: <34F53465-5289-4E68-9086-AC8CDF8DD02D@rfc1035.com> > On 4 Feb 2019, at 13:14, Francis Brosnan Bl?zquez wrote: > > Current policy is a good compromise: it focus on allocating to LIRs > that assign and use address space ...until no more allocation can be > done. +1 I do not support 2019-02. From raymond.jetten at elisa.fi Mon Feb 4 14:23:32 2019 From: raymond.jetten at elisa.fi (Jetten Raymond) Date: Mon, 4 Feb 2019 13:23:32 +0000 Subject: [address-policy-wg] 2019-02 New Policy Proposal (Reducing IPv4 Allocations to a /24) In-Reply-To: References: Message-ID: Hi Sander, To make it more clear what I mean, a /24 will not be enough to connect a say /29 IPv6 to the v4 world, a /22 ( or any range of addresses up to a /22 in size ) is not enough either. Therefore I support the current policy, and am against the new proposal. Rgds, Ray -----Original Message----- From: Sander Steffann Sent: 4. helmikuuta 2019 15:11 To: Jetten Raymond Cc: Marco Schmidt ; address-policy-wg at ripe.net Subject: Re: [address-policy-wg] 2019-02 New Policy Proposal (Reducing IPv4 Allocations to a /24) Hi Raymond, > I strongly oppose this proposal, a similar proposal was mode before, (2017-03) , > and I agree with the arguments opposing the proposal. 2017-03 was a different kind of proposal. At that time the choice was between handing out /22 or handing out /24 to all new LIRs. While I did think back then that this was a good idea I understood the reasons against that proposal. LIRs that would get a /22 under the old policy would then get a /24, making things worse for those LIRs. It would also delay the moment that the NCC would hit the bottom by a very long time, therefore potentially giving the impression that IPv4 was still available. Your concluding argument for that proposal was "A /22 is not even enough, let alone a /24 to yet connect to the "dark ages of the IPv4 internet", not now and unfortunately not in the future either...". And at the time that was a valid argument, because of those LIRs that otherwise would get a /22. For this proposal the circumstances have changed though. Now the choice is between giving the new LIRs that come after the /22s have run out a /24 or nothing at all. The analysis from the NCC has shown that if we make a waiting list with /22s the queue will grow indefinitely, which means that the vast majority of the LIRs will never get anything at all. With a /24 allocation size the waiting list becomes manageable and more predictable. I don't think that choosing to give them nothing when we could have given them a /24 is a reasonable argument at the point in time when we have already run out of /22s... Cheers, Sander From sander at steffann.nl Mon Feb 4 14:27:29 2019 From: sander at steffann.nl (Sander Steffann) Date: Mon, 4 Feb 2019 14:27:29 +0100 Subject: [address-policy-wg] 2019-02 New Policy Proposal (Reducing IPv4 Allocations to a /24) In-Reply-To: <1549286099.28715.34.camel@aspl.es> References: <20190204124140.GV56439@carcass.ledeuns.net> <1549286099.28715.34.camel@aspl.es> Message-ID: <43861F5C-D338-4907-B092-DA528EA97155@steffann.nl> Hello Francis and Jim, > We do not agree with this proposal. > > Sooner or later RIPE IPv4 address space will run out. Moving from /22 > to /24 will not change that, which is the essence of the question, but > doing so will create more fragmentation (BGP, smaller LIRS, cost > unfairness between members...). > > In practical terms, we believe this will also boost IP broker market > (the smaller the blocks, the stronger IP brokers will get). > > Current policy is a good compromise: it focus on allocating to LIRs > that assign and use address space ...until no more allocation can be > done. It seems you misunderstand the proposal. This policy agrees with you that /22s should be allocated until RIPE NCC runs out. It is about what happens afterwards. We create a waiting list with either /22 or /24 allocation size. - Choosing /22 means that the waiting list is unmanageable and therefore (mostly) useless. - Choosing /24 means that the waiting list is manageable and a bit less useless. We're not suggesting to change the allocation size now, only for the waiting list. Cheers, Sander From sander at steffann.nl Mon Feb 4 14:28:33 2019 From: sander at steffann.nl (Sander Steffann) Date: Mon, 4 Feb 2019 14:28:33 +0100 Subject: [address-policy-wg] 2019-02 New Policy Proposal (Reducing IPv4 Allocations to a /24) In-Reply-To: References: Message-ID: <2A9C98CA-1273-4C8C-8DF5-C28314C9F062@steffann.nl> Hi Raymond, > To make it more clear what I mean, a /24 will not be enough to connect a say /29 IPv6 to the v4 world, a /22 ( or any range of addresses up to a /22 in size ) is not enough either. Therefore I support the current policy, and am against the new proposal. Can you please explain how you see that? This proposal only deals with the situation *after* the current policy becomes useless... Cheers, Sander From raymond.jetten at elisa.fi Mon Feb 4 14:32:54 2019 From: raymond.jetten at elisa.fi (Jetten Raymond) Date: Mon, 4 Feb 2019 13:32:54 +0000 Subject: [address-policy-wg] 2019-02 New Policy Proposal (Reducing IPv4 Allocations to a /24) In-Reply-To: <2A9C98CA-1273-4C8C-8DF5-C28314C9F062@steffann.nl> References: <2A9C98CA-1273-4C8C-8DF5-C28314C9F062@steffann.nl> Message-ID: Hi Sander, The current policy does not become useless: "In case an allocation of a single /22 as per clause 1 can no longer be made, multiple allocations up to an equivalent of a /22 in address space will be made to fulfill a request." is in the current proposal. Rgds, Ray -----Original Message----- From: Sander Steffann Sent: 4. helmikuuta 2019 15:29 To: Jetten Raymond Cc: Marco Schmidt ; address-policy-wg at ripe.net Subject: Re: [address-policy-wg] 2019-02 New Policy Proposal (Reducing IPv4 Allocations to a /24) Hi Raymond, > To make it more clear what I mean, a /24 will not be enough to connect a say /29 IPv6 to the v4 world, a /22 ( or any range of addresses up to a /22 in size ) is not enough either. Therefore I support the current policy, and am against the new proposal. Can you please explain how you see that? This proposal only deals with the situation *after* the current policy becomes useless... Cheers, Sander From sander at steffann.nl Mon Feb 4 14:40:41 2019 From: sander at steffann.nl (Sander Steffann) Date: Mon, 4 Feb 2019 14:40:41 +0100 Subject: [address-policy-wg] 2019-02 New Policy Proposal (Reducing IPv4 Allocations to a /24) In-Reply-To: References: <2A9C98CA-1273-4C8C-8DF5-C28314C9F062@steffann.nl> Message-ID: <4BD490EB-26F2-42C3-8028-F2DBF7BE7098@steffann.nl> Hi Raymond, > The current policy does not become useless: > > "In case an allocation of a single /22 as per clause 1 can no longer be made, multiple allocations up to an equivalent of a /22 in address space will be made to fulfill a request." is in the current proposal. Ok, that will extend the lifetime of the /22 policy with a little bit (causing a large amount of fragments to end up in the routing table), and *then* it becomes useless... How do you see the policy after that, when there is a waiting list? Keep pushing lots of fragments to the last LIRs? Cheers, Sander From jim at rfc1035.com Mon Feb 4 14:40:44 2019 From: jim at rfc1035.com (Jim Reid) Date: Mon, 4 Feb 2019 13:40:44 +0000 Subject: [address-policy-wg] 2019-02 New Policy Proposal (Reducing IPv4 Allocations to a /24) In-Reply-To: <43861F5C-D338-4907-B092-DA528EA97155@steffann.nl> References: <20190204124140.GV56439@carcass.ledeuns.net> <1549286099.28715.34.camel@aspl.es> <43861F5C-D338-4907-B092-DA528EA97155@steffann.nl> Message-ID: <97ABDD02-4D99-4167-8363-66C0B5AAA18C@rfc1035.com> > On 4 Feb 2019, at 13:27, Sander Steffann wrote: > > It seems you misunderstand the proposal. This policy agrees with you that /22s should be allocated until RIPE NCC runs out. It is about what happens afterwards. We create a waiting list with either /22 or /24 allocation size. > > - Choosing /22 means that the waiting list is unmanageable and therefore (mostly) useless. > - Choosing /24 means that the waiting list is manageable and a bit less useless. > > We're not suggesting to change the allocation size now, only for the waiting list. I?m not convinced there?s any point in having a waiting list or maintaining an expensive bureauracy to oversee the dregs of the dregs of v4. IMO, once the NCC is unable to allocate /22s to new LIRs, it?s game over. v4 is finally exhausted. Get over it. A policy to deal with whatever /24s the NCC might find stuffed down the back of the sofa will be more bother than its worth. Unless someone can provide compelling arguments -- ie there?s still a lot of v4 for the NCC to allocate -- I just don?t see the point. Sorry. How much of this hypothetical /24 space does the NCC hold anyway? How long might it last? From sander at steffann.nl Mon Feb 4 14:49:17 2019 From: sander at steffann.nl (Sander Steffann) Date: Mon, 4 Feb 2019 14:49:17 +0100 Subject: [address-policy-wg] 2019-02 New Policy Proposal (Reducing IPv4 Allocations to a /24) In-Reply-To: <97ABDD02-4D99-4167-8363-66C0B5AAA18C@rfc1035.com> References: <20190204124140.GV56439@carcass.ledeuns.net> <1549286099.28715.34.camel@aspl.es> <43861F5C-D338-4907-B092-DA528EA97155@steffann.nl> <97ABDD02-4D99-4167-8363-66C0B5AAA18C@rfc1035.com> Message-ID: <20EB26CC-D32B-452B-A893-A3476CABE1ED@steffann.nl> Hi Jim, > A policy to deal with whatever /24s the NCC might find stuffed down the back of the sofa will be more bother than its worth. Unless someone can provide compelling arguments -- ie there?s still a lot of v4 for the NCC to allocate -- I just don?t see the point. Sorry. > > How much of this hypothetical /24 space does the NCC hold anyway? How long might it last? It's more about that the NCC does with returned address space. The current pools will indeed run out very quickly, no point trying to extend those. The usefulness of this policy can be seen in https://ripe77.ripe.net/presentations/71-Andrea_Cima_RIPE_77_APWG.pdf slide 14. When we use the returned space in /22 chunks there is not much point in having a waiting list. If we use /24 there is. That's all :) Sander From dfk at ripe.net Mon Feb 4 14:58:28 2019 From: dfk at ripe.net (Daniel Karrenberg) Date: Mon, 4 Feb 2019 14:58:28 +0100 Subject: [address-policy-wg] 2019-02 New Policy Proposal (Reducing IPv4 Allocations to a /24) In-Reply-To: <97ABDD02-4D99-4167-8363-66C0B5AAA18C@rfc1035.com> References: <20190204124140.GV56439@carcass.ledeuns.net> <1549286099.28715.34.camel@aspl.es> <43861F5C-D338-4907-B092-DA528EA97155@steffann.nl> <97ABDD02-4D99-4167-8363-66C0B5AAA18C@rfc1035.com> Message-ID: On 04/02/2019 14:40, Jim Reid wrote: > > >> On 4 Feb 2019, at 13:27, Sander Steffann wrote: >> >> It seems you misunderstand the proposal. This policy agrees with you that /22s should be allocated until RIPE NCC runs out. It is about what happens afterwards. We create a waiting list with either /22 or /24 allocation size. >> >> - Choosing /22 means that the waiting list is unmanageable and therefore (mostly) useless. >> - Choosing /24 means that the waiting list is manageable and a bit less useless. >> >> We're not suggesting to change the allocation size now, only for the waiting list. > > I?m not convinced there?s any point in having a waiting list or maintaining an expensive bureauracy to oversee the dregs of the dregs of v4. IMO, once the NCC is unable to allocate /22s to new LIRs, it?s game over. v4 is finally exhausted. Get over it. > > A policy to deal with whatever /24s the NCC might find stuffed down the back of the sofa will be more bother than its worth. Unless someone can provide compelling arguments -- ie there?s still a lot of v4 for the NCC to allocate -- I just don?t see the point. Sorry. > > How much of this hypothetical /24 space does the NCC hold anyway? How long might it last? But how tenable is it both in principle and in 'Internet governance' terms for the NCC to collect fragmentlets of IPv4 and just sit on them? Not very! So we need a policy to allocate them in a useful manner. The question before us is: What is the minimum useful allocation? Nothing else. Daniel From sander at steffann.nl Mon Feb 4 15:02:15 2019 From: sander at steffann.nl (Sander Steffann) Date: Mon, 4 Feb 2019 15:02:15 +0100 Subject: [address-policy-wg] 2019-02 New Policy Proposal (Reducing IPv4 Allocations to a /24) In-Reply-To: References: <20190204124140.GV56439@carcass.ledeuns.net> <1549286099.28715.34.camel@aspl.es> <43861F5C-D338-4907-B092-DA528EA97155@steffann.nl> <97ABDD02-4D99-4167-8363-66C0B5AAA18C@rfc1035.com> Message-ID: Hi Daniel, > But how tenable is it both in principle and in 'Internet governance' > terms for the NCC to collect fragmentlets of IPv4 and just sit on them? > > Not very! > > So we need a policy to allocate them in a useful manner. > > The question before us is: What is the minimum useful allocation? > Nothing else. You are much better at summarising than I am :) Andrea Cima has shown us at RIPE76 that /22 is not useful, and /24 is just about useful. Cheers, Sander From jim at rfc1035.com Mon Feb 4 15:07:32 2019 From: jim at rfc1035.com (Jim Reid) Date: Mon, 4 Feb 2019 14:07:32 +0000 Subject: [address-policy-wg] 2019-02 New Policy Proposal (Reducing IPv4 Allocations to a /24) In-Reply-To: References: <20190204124140.GV56439@carcass.ledeuns.net> <1549286099.28715.34.camel@aspl.es> <43861F5C-D338-4907-B092-DA528EA97155@steffann.nl> <97ABDD02-4D99-4167-8363-66C0B5AAA18C@rfc1035.com> Message-ID: <34189379-6FFE-4607-9B31-F076E12B703B@rfc1035.com> > On 4 Feb 2019, at 13:58, Daniel Karrenberg wrote: > > The question before us is: What is the minimum useful allocation? Well yes Daniel. But how long does that discussion last? Perhaps 5-10 years from now we?ll be debating policies on how the NCC allocates /30s or /31s of v4. :-) Even if the NCC is left with fragments of v4, it may well be impractical to allocate them. Kind of like how the final reserves in a mine or an oil well get left in the ground because it?s not financially viable to extract them. From garry at nethinks.com Mon Feb 4 15:20:09 2019 From: garry at nethinks.com (garry at nethinks.com) Date: Mon, 4 Feb 2019 15:20:09 +0100 Subject: [address-policy-wg] 2019-02 New Policy Proposal (Reducing IPv4 Allocations to a /24) In-Reply-To: <34189379-6FFE-4607-9B31-F076E12B703B@rfc1035.com> References: <20190204124140.GV56439@carcass.ledeuns.net> <1549286099.28715.34.camel@aspl.es> <43861F5C-D338-4907-B092-DA528EA97155@steffann.nl> <97ABDD02-4D99-4167-8363-66C0B5AAA18C@rfc1035.com> <34189379-6FFE-4607-9B31-F076E12B703B@rfc1035.com> Message-ID: > >> On 4 Feb 2019, at 13:58, Daniel Karrenberg wrote: >> >> The question before us is: What is the minimum useful allocation? > Well yes Daniel. > > But how long does that discussion last? Perhaps 5-10 years from now we?ll be debating policies on how the NCC allocates /30s or /31s of v4. :-) No, because (hopefully) the prefix filters on the v4 Internet will never EVER allow anything smaller than a /24 to be routed on the open Internet ... Allowing LIRs to obtain their /22 - even if it is in up to 4 subnets - will be a lot better than not being able to supply _any_ v4 addresses to those late adopters due to only having the policies with /22 ... -garry -- Garry Glendown * Professional Services & Solutions NETHINKS GmbH | Bahnhofstra?e 16 | 36037 Fulda T +49 661 25 000 0 | F +49 661 25 000 49 | garry.glendown at nethinks.com Gesch?ftsf?hrer: Uwe Bergmann, Bastian Marmetschke Vorsitzender des Aufsichtsrats: Garry Glendown | AG Fulda HRB 2546 PGP Fingerprint: B1CF 4952 F6EB E060 8A10 B957 700E F97F B412 DD32 ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From hunekm at gmail.com Mon Feb 4 15:46:34 2019 From: hunekm at gmail.com (Martin =?utf-8?B?SHVuxJtr?=) Date: Mon, 04 Feb 2019 15:46:34 +0100 Subject: [address-policy-wg] 2019-02 New Policy Proposal (Reducing IPv4 Allocations to a /24) In-Reply-To: References: Message-ID: <4683368.o2AGSbb5lF@rumburak.ite.tul.cz> Hi, I don't think that we have to change current policy at all. Current policy allows to get /22 divided to smaller blocks, so it doesn't have to be changed just because of this. My personal opinion on IPv4 exhaustion is that it would be better to come sooner than later. Any means of slowing exhaustion down would just prolong the IPv4 agony. Reaching zero free pool is the only way. Please stop trying to conserve any more IPv4 addresses, IPv4 has reached a dead-end, let it die peacefully. Best Regards, Martin Hunek Dne pond?l? 4. ?nora 2019 13:04:26 CET, Marco Schmidt napsal(a): > Dear colleagues, > > A new RIPE Policy proposal, 2019-02, "Reducing IPv4 Allocations to a /24" > is now available for discussion. > > This proposal aims to reduce the IPv4 allocation size to a /24 once the > RIPE NCC is unable to allocate contiguous /22 ranges. > > You can find the full proposal at: > https://www.ripe.net/participate/policies/proposals/2019-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 proposer. > > At the end of the Discussion Phase, the proposer, with the agreement of > the WG Chairs, will decide how to proceed with the proposal. > > We encourage you to review this proposal and send your comments to > before 5 March 2019. > > Regards, > > Marco Schmidt > Policy Officer > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: This is a digitally signed message part. URL: From sander at steffann.nl Mon Feb 4 15:52:06 2019 From: sander at steffann.nl (Sander Steffann) Date: Mon, 4 Feb 2019 15:52:06 +0100 Subject: [address-policy-wg] 2019-02 New Policy Proposal (Reducing IPv4 Allocations to a /24) In-Reply-To: <4683368.o2AGSbb5lF@rumburak.ite.tul.cz> References: <4683368.o2AGSbb5lF@rumburak.ite.tul.cz> Message-ID: <8F07A5E6-24C6-4405-B372-D6449F4F22A3@steffann.nl> Hi Martin, > I don't think that we have to change current policy at all. > > Current policy allows to get /22 divided to smaller blocks, so it doesn't have to be changed just because of this. > > My personal opinion on IPv4 exhaustion is that it would be better to come sooner than later. Any means of slowing exhaustion down would just prolong the IPv4 agony. Reaching zero free pool is the only way. Please look at the presentation I linked to and Daniel's comment. > Please stop trying to conserve any more IPv4 addresses, IPv4 has reached a dead-end, let it die peacefully. This is not about conserving IPv4 addresses. Sander From uros at ub330.net Mon Feb 4 15:55:08 2019 From: uros at ub330.net (Uros Gaber) Date: Mon, 4 Feb 2019 15:55:08 +0100 Subject: [address-policy-wg] 2019-02 New Policy Proposal (Reducing IPv4 Allocations to a /24) In-Reply-To: <4683368.o2AGSbb5lF@rumburak.ite.tul.cz> References: <4683368.o2AGSbb5lF@rumburak.ite.tul.cz> Message-ID: Hi, while the current policy does permit the /22 allocation be made from smaller blocks it does not in it's current form allow smaller allocations. I do support this policy as it does allow more new comers to the market to get at least a /24 which is still better than nothing. I think that any consecutive changes to this policy regarding the size of allocations will not be brought to light unless the prefix filters will allow smaller routes. About the financial viability I think that from the RIR standpoint it doesn't pose a problem as the RIR should have the same amount of work with a LIR that has /22, /24 or any other allocation. Best regards, Uros Gaber On Mon, Feb 4, 2019 at 3:47 PM Martin Hun?k wrote: > Hi, > > I don't think that we have to change current policy at all. > > Current policy allows to get /22 divided to smaller blocks, so it doesn't > have to be changed just because of this. > > My personal opinion on IPv4 exhaustion is that it would be better to come > sooner than later. Any means of slowing exhaustion down would just prolong > the IPv4 agony. Reaching zero free pool is the only way. > > Please stop trying to conserve any more IPv4 addresses, IPv4 has reached a > dead-end, let it die peacefully. > > Best Regards, > Martin Hunek > > Dne pond?l? 4. ?nora 2019 13:04:26 CET, Marco Schmidt napsal(a): > > Dear colleagues, > > > > A new RIPE Policy proposal, 2019-02, "Reducing IPv4 Allocations to a /24" > > is now available for discussion. > > > > This proposal aims to reduce the IPv4 allocation size to a /24 once the > > RIPE NCC is unable to allocate contiguous /22 ranges. > > > > You can find the full proposal at: > > https://www.ripe.net/participate/policies/proposals/2019-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 proposer. > > > > At the end of the Discussion Phase, the proposer, with the agreement of > > the WG Chairs, will decide how to proceed with the proposal. > > > > We encourage you to review this proposal and send your comments to > > before 5 March 2019. > > > > Regards, > > > > Marco Schmidt > > Policy Officer > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sander at steffann.nl Mon Feb 4 16:02:10 2019 From: sander at steffann.nl (Sander Steffann) Date: Mon, 4 Feb 2019 16:02:10 +0100 Subject: [address-policy-wg] 2019-02 New Policy Proposal (Reducing IPv4 Allocations to a /24) In-Reply-To: References: Message-ID: <01594E1D-ECBF-4E70-844A-71F76291A981@steffann.nl> Hello working group, The first comments I got back on this proposal all seemed to miss the point of it. Let me explicitly state what this policy is NOT about: - it is NOT about conserving IPv4 addresses - it is NOT about postponing the runout date - it is NOT about extending the lifetime of IPv4 It's purpose is solely about: - dealing with the returned address space the NCC will get over the years Under the current policy: - the waiting list will grow indefinitely - the allocations given out will consist of tiny fragments - it will therefore not be of any practical use This proposal proposes: - keeping /22 until we run out of /22s - give out /24s only after that - this helps to keep the waiting list manageable [1] - declare everything smaller (longer prefix) than a /24 unusable - this helps against people getting unusable dust [1]: see https://ripe77.ripe.net/presentations/71-Andrea_Cima_RIPE_77_APWG.pdf slide 14 Please forget about previous attempts to change allocation sizes. Those were about changing the current allocation policy. This proposal only looks forward to what to do after the current policy becomes unusable. Please focus on that. Cheers, Sander From hunekm at gmail.com Mon Feb 4 16:09:06 2019 From: hunekm at gmail.com (Martin =?utf-8?B?SHVuxJtr?=) Date: Mon, 04 Feb 2019 16:09:06 +0100 Subject: [address-policy-wg] 2019-02 New Policy Proposal (Reducing IPv4 Allocations to a /24) In-Reply-To: <8F07A5E6-24C6-4405-B372-D6449F4F22A3@steffann.nl> References: <4683368.o2AGSbb5lF@rumburak.ite.tul.cz> <8F07A5E6-24C6-4405-B372-D6449F4F22A3@steffann.nl> Message-ID: <4078838.uclnDJ5vct@rumburak.ite.tul.cz> Hi Sander, > Please look at the presentation I linked to and Daniel's comment. Looking at it right now. But I'm still not convinced that it is a good idea. > > > Please stop trying to conserve any more IPv4 addresses, IPv4 has reached a dead-end, let it die peacefully. > > This is not about conserving IPv4 addresses. Maybe not directly, but when the waiting list get incredibly long, it would mean that if you get into queue late you won't probably get any address. That what I'm talking here, a total exhaustion of IPv4. When giving out /24, there is higher chance that more subjects would get IPv4 pool, so it would last bit longer as the result. I would rather see policy about when we reach situation where there is no longer /22 to distribute than move all returned IPv4 pools after that into IXP reserved pool. Than no waiting list would be needed. But I'm pretty sure that such a policy would not pass as well. Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: This is a digitally signed message part. URL: From dfk at ripe.net Mon Feb 4 16:13:54 2019 From: dfk at ripe.net (Daniel Karrenberg) Date: Mon, 4 Feb 2019 16:13:54 +0100 Subject: [address-policy-wg] 2019-02 New Policy Proposal (Reducing IPv4 Allocations to a /24) In-Reply-To: References: <20190204124140.GV56439@carcass.ledeuns.net> <1549286099.28715.34.camel@aspl.es> <43861F5C-D338-4907-B092-DA528EA97155@steffann.nl> <97ABDD02-4D99-4167-8363-66C0B5AAA18C@rfc1035.com> Message-ID: On 04/02/2019 15:02, Sander Steffann wrote: > Hi Daniel, > >> But how tenable is it both in principle and in 'Internet governance' >> terms for the NCC to collect fragmentlets of IPv4 and just sit on them? >> >> Not very! >> >> So we need a policy to allocate them in a useful manner. >> >> The question before us is: What is the minimum useful allocation? >> Nothing else. > > You are much better at summarising than I am :) > > Andrea Cima has shown us at RIPE76 that /22 is not useful, and /24 is just about useful. Sorry for not being precise. I meant 'useful to route packets' and not useful to make the allocation process more convenient. So let us look at what minimum prefix is useful to route packets: Looking at http://bgp.potaroo.net/as6447/ it appears that at this time more than 50% of the IPv4 prefixes seen by that collector are /24s. So /24s are useful. The numbers of prefixes longer than /25 are negligible in comparison. Other statistics Geoff provides there also support that /25 or longer is not useful in practice today. Geoff's data agrees with what RIS sees too. This should be no shocking news to anybody here. It is not tenable for the NCC to force new LIRs to wait for a /22 to be returned when they would be happy to use a /24 that the RIPE NCC has. So that needs to be an option. Offering the choice to wait for a longer prefix raises all sorts of complications about fairness and practicality. Therefore a rational policy will end up at one-size-fits-all: /24. It is just the reality of current routing practice. A rational policy will have to accept it. Daniel From danny at danysek.cz Mon Feb 4 16:19:50 2019 From: danny at danysek.cz (Daniel Suchy) Date: Mon, 4 Feb 2019 16:19:50 +0100 Subject: [address-policy-wg] 2019-02 New Policy Proposal (Reducing IPv4 Allocations to a /24) In-Reply-To: <1549286099.28715.34.camel@aspl.es> References: <20190204124140.GV56439@carcass.ledeuns.net> <1549286099.28715.34.camel@aspl.es> Message-ID: <4f7af783-c21e-69ec-9d0d-da2f3fdc18bc@danysek.cz> Hello, On 2/4/19 2:14 PM, Francis Brosnan Bl?zquez wrote: > Sooner or later RIPE IPv4 address space will run out. Moving from /22 > to /24 will not change that, which is the essence of the question, but > doing so will create more fragmentation (BGP, smaller LIRS, cost > unfairness between members...). Fragmentation is here already and it's done even by resource holders having allocations shorter than /22... Some kind of unfairness is also here - some LIRs have only single /22, some LIRs have multiple /16. From this perspective it's nothing bad, when new LIRs will have only /24... As stated in original post "This proposal aims to reduce the IPv4 allocation size to a /24 once the RIPE NCC is unable to allocate contiguous /22 ranges." - that meas, when new allocations will cause fragmentation anyway. - Daniel From dfk at ripe.net Mon Feb 4 16:26:17 2019 From: dfk at ripe.net (Daniel Karrenberg) Date: Mon, 4 Feb 2019 16:26:17 +0100 Subject: [address-policy-wg] 2019-02 New Policy Proposal (Reducing IPv4 Allocations to a /24) In-Reply-To: References: Message-ID: This policy assumes that once the RIPE NCC pool gets 'exhausted' it will never be very large. Are we OK to continue allocating /24s in the unlikely, but possible, event that the RIPE NCC ever gets back a larger chunk? If not, it would be better to re-write the policy to do two independent separate things: re-emphasize first-come-first-served principle including a waiting list and specify an allocation size that is dependent on the size of the pool. Just food for thought ... Daniel From boggits at gmail.com Mon Feb 4 17:30:14 2019 From: boggits at gmail.com (boggits) Date: Mon, 4 Feb 2019 16:30:14 +0000 Subject: [address-policy-wg] 2019-02 New Policy Proposal (Reducing IPv4 Allocations to a /24) In-Reply-To: References: Message-ID: On Mon, 4 Feb 2019 at 12:04, Marco Schmidt wrote: > > This proposal aims to reduce the IPv4 allocation size to a /24 once the > RIPE NCC is unable to allocate contiguous /22 ranges. > Is it worth having a period of handing out two or three (potentially non-contiguous) /24s when the last complete /22 disappears, before moving to just a single /24 (with a step at 2 if we start at 3)? I can see the logic between the change in sizes, I'm just wondering if there was a case for intermediatory steps to reduce the pain Either way, I support the proposal with or without this change Thx J -- James Blessing 07989 039 476 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jim at rfc1035.com Mon Feb 4 17:14:40 2019 From: jim at rfc1035.com (Jim Reid) Date: Mon, 4 Feb 2019 16:14:40 +0000 Subject: [address-policy-wg] 2019-02 New Policy Proposal (Reducing IPv4 Allocations to a /24) In-Reply-To: References: <20190204124140.GV56439@carcass.ledeuns.net> <1549286099.28715.34.camel@aspl.es> <43861F5C-D338-4907-B092-DA528EA97155@steffann.nl> <97ABDD02-4D99-4167-8363-66C0B5AAA18C@rfc1035.com> <34189379-6FFE-4607-9B31-F076E12B703B@rfc1035.com> Message-ID: <7088A18D-4C6F-4892-B85B-34E28745FBFF@rfc1035.com> > On 4 Feb 2019, at 14:20, garry at nethinks.com wrote: > >> But how long does that discussion last? Perhaps 5-10 years from now we?ll be debating policies on how the NCC allocates /30s or /31s of v4. :-) > > No, because (hopefully) the prefix filters on the v4 Internet will never EVER allow anything smaller than a /24 to be routed on the open Internet ... That may well be true Garry. But just think of all the fine dinners and exotic travel that can be had as we talk and talk and talk about IPv4 allocation policy for ever more useless allocation units of ever smaller amounts of v4 space at the NCC. We can't allow reality to intrude on those sorts of policy discussions. :-) From randy at psg.com Mon Feb 4 20:34:23 2019 From: randy at psg.com (Randy Bush) Date: Mon, 04 Feb 2019 11:34:23 -0800 Subject: [address-policy-wg] 2019-02 New Policy Proposal (Reducing IPv4 Allocations to a /24) In-Reply-To: References: <20190204124140.GV56439@carcass.ledeuns.net> <1549286099.28715.34.camel@aspl.es> <43861F5C-D338-4907-B092-DA528EA97155@steffann.nl> <97ABDD02-4D99-4167-8363-66C0B5AAA18C@rfc1035.com> Message-ID: > But how tenable is it both in principle and in 'Internet governance' > terms for the NCC to collect fragmentlets of IPv4 and just sit on > them? not. many will have sharp edges. :) > So we need a policy to allocate them in a useful manner. > > The question before us is: What is the minimum useful allocation? today, that is a /24, as we all know. an experiment has shown issues with propagation of longer prefixes, no surprise. but, as i have suggested for some years, we will eventually have to remove that barrier. but this proposal just speaks to /24s. and it makes sense for now. randy From wusel+ml at uu.org Tue Feb 5 02:04:23 2019 From: wusel+ml at uu.org (Kai 'wusel' Siering) Date: Tue, 5 Feb 2019 02:04:23 +0100 Subject: [address-policy-wg] 2019-02 New Policy Proposal (Reducing IPv4 Allocations to a /24) In-Reply-To: <01594E1D-ECBF-4E70-844A-71F76291A981@steffann.nl> References: <01594E1D-ECBF-4E70-844A-71F76291A981@steffann.nl> Message-ID: Moin, am 04.02.2019 um 16:02 schrieb Sander Steffann: > The first comments I got back on this proposal all seemed to miss the point of it. Let me explicitly state what this policy is NOT about: Thanks for the clarification, but ... > - it is NOT about conserving IPv4 addresses > - it is NOT about postponing the runout date > - it is NOT about extending the lifetime of IPv4 ... while this might not be the intention, it's basically the outcome. > It's purpose is solely about: > - dealing with the returned address space the NCC will get over the years > > Under the current policy: > - the waiting list will grow indefinitely Well, first come, first served. It's not a wise move to start developing Diesel engines these days, nor is it to rely on IPv4. As others already pointed out, even a /22 is tough to start a new ISP business, due to the huge amount of services that still are only available via IPv4 (github.com, pagerduty.com ? two random checks, two hits; happily adding the MX for outlook.com to this list of shame). The waiting list may grow "indefinitely", but only in relation to new LIRs being created. If one will have to bear the costs of an LIR without even roughly knowing when one will receive IPv4 addresses, or if at all, becoming an LIR to farm v4 hopefully will be less appealing. And while being #9999 on the waiting list might sound like a high number, 100k entries should be easy to serve even with sqlite on an Raspberry Pi 1. Read: this can't be a technical issue for the RIPE NCC. > - the allocations given out will consist of tiny fragments > - it will therefore not be of any practical use If the RIPE NCC continues to hand out /24s and /23s up to the equivalent of an /22, i. e. worst cast 4 random /24s, where's the issue? Ok, I admit that ripe-708 neglects to specify the minimal size of an allocation: "In case an allocation of a single /22 as per clause 1 can no longer be made, multiple allocations up to an equivalent of a /22 in address space will be made to fulfill a request." Thus, *technically* RIPE NCC could fulfill the /22 requirement by allocating 1024 /32s. But to fix _that_, only "not larger than /24" needs to be added after "allocations". So, yes, ripe-708 needs two updates: 1. Specify "multiple allocations up to an equivalent of a /22" means multiple /24 or /23 only. 2. Define that if no /22-equivalent is available at the time of request, the request is appended to an ever-growing FIFO-queue. But 2019-02 is going too far, it *will* help prolong IPv4 usability, and that must be avoided at all cost. Only if v4-only-services do loose customers because of v6-only, IPv6 adoption may speed up again. +1 for being *against* 2019-02. Regards, -kai -- Kai Siering Schal?ckstra?e 107, 33332 G?tersloh eMail: Kai.Siering at uu.org Fon: +49 172 863 5608 & +1 781 312 8733 ---------------------------------------------------------------------- "Getdate firmly believes that years after 1999 do not exist; getdate will have to be killed by the year 2000." -- From the "Bugs" section of cnews-020592/libc/getdate.3 From tore at fud.no Tue Feb 5 08:34:33 2019 From: tore at fud.no (Tore Anderson) Date: Tue, 5 Feb 2019 08:34:33 +0100 Subject: [address-policy-wg] 2019-02 New Policy Proposal (Reducing IPv4 Allocations to a /24) In-Reply-To: References: Message-ID: <3a24cca4-02e0-b1c3-6a23-98d47d207436@fud.no> * Marco Schmidt > A new RIPE Policy proposal, 2019-02, "Reducing IPv4 Allocations to a /24" > is now available for discussion. > > This proposal aims to reduce the IPv4 allocation size to a /24 once the > RIPE NCC is unable to allocate contiguous /22 ranges. I support this proposal. Some random thoughts about it: - It is good to have the policy explicitly say there is a waiting list. Current policy says nothing about this. If the NCC would simply close allocation tickets with ?sorry, fresh out, try later?, that could encourage LIRs to spam repeated allocation requests in the hope that theirs was the first request to be received after an IPv4 fragment was returned to the allocation pool. - I don't quite believe that the waiting list would grow indefinitely (regardless of the allocation size being /22 or /24). Keep in mind that only new and IPv4-less LIRs would be able to join the waiting list. Once it is known that simply joining the NCC won't guarantee a /22, but that you'd have to wait for one with no certainty as to how long, I expect that the sign-up rate of new LIRs will drop dramatically (and by extension the amount of LIRs queuing up in the waiting list). - It seems reasonable to lower the allocation unit to the de facto smallest usable on the public Internet at a point in time when we can no longer allocate /22s (which are already pretty small). Otherwise recovered /23 and /24 fragments (e.g., PI assignments) will just end up rotting away in the NCC inventory, which serves no good purpose at all. - It seems reasonable to trigger this policy at precisely at a watershed moment like the policy aims to do (unlike 2017-03, which would have changed the rules in the middle of the game). - The authors should clarify how this new policy interacts with the /16 set aside in ?5.2 Unforeseen circumstances?. In which order does the 5.2 and 5.1bis policies get triggered? Tore From tore at fud.no Tue Feb 5 08:43:50 2019 From: tore at fud.no (Tore Anderson) Date: Tue, 5 Feb 2019 08:43:50 +0100 Subject: [address-policy-wg] 2019-02 New Policy Proposal (Reducing IPv4 Allocations to a /24) In-Reply-To: <97ABDD02-4D99-4167-8363-66C0B5AAA18C@rfc1035.com> References: <20190204124140.GV56439@carcass.ledeuns.net> <1549286099.28715.34.camel@aspl.es> <43861F5C-D338-4907-B092-DA528EA97155@steffann.nl> <97ABDD02-4D99-4167-8363-66C0B5AAA18C@rfc1035.com> Message-ID: <683748ee-66ce-2235-176c-0160d19ee40e@fud.no> * Jim Reid > I?m not convinced there?s any point in having a waiting list or maintaining an expensive bureauracy to oversee the dregs of the dregs of v4. IMO, once the NCC is unable to allocate /22s to new LIRs, it?s game over. v4 is finally exhausted. Get over it. That's a fair point of view, but that's not what current policy actually says, so you'd need to change the policy to get that in any case. Should be a simple proposal: Any returned/reclaimed IPv4 space should simply be passed on to the IANA Recovered IPv4 Pool, and the NCC should say ?no thanks? to any further allocations from the IANA (or instantly return them if declining them outright is not possible). At least we'd be finally free of the multi-LIR abusers and their bitching about having to pay their invoices on members-discuss that way... Tore From garry at nethinks.com Tue Feb 5 08:53:21 2019 From: garry at nethinks.com (garry at nethinks.com) Date: Tue, 5 Feb 2019 08:53:21 +0100 Subject: [address-policy-wg] 2019-02 New Policy Proposal (Reducing IPv4 Allocations to a /24) In-Reply-To: <683748ee-66ce-2235-176c-0160d19ee40e@fud.no> References: <20190204124140.GV56439@carcass.ledeuns.net> <1549286099.28715.34.camel@aspl.es> <43861F5C-D338-4907-B092-DA528EA97155@steffann.nl> <97ABDD02-4D99-4167-8363-66C0B5AAA18C@rfc1035.com> <683748ee-66ce-2235-176c-0160d19ee40e@fud.no> Message-ID: <387ff9aa-f98e-4be7-2904-a20a0c04e29c@nethinks.com> > * Jim Reid > >> I?m not convinced there?s any point in having a waiting list or maintaining an expensive bureauracy to oversee the dregs of the dregs of v4. IMO, once the NCC is unable to allocate /22s to new LIRs, it?s game over. v4 is finally exhausted. Get over it. > Should be a simple proposal: Any returned/reclaimed IPv4 space should > simply be passed on to the IANA Recovered IPv4 Pool, and the NCC should > say ?no thanks? to any further allocations from the IANA (or instantly > return them if declining them outright is not possible). > > At least we'd be finally free of the multi-LIR abusers and their bitching > about having to pay their invoices on members-discuss that way... That is an option. But in order to not punish late entries to the market, it should also include a fixed timeframe when EVERYBODY has to stop using v4 (at least on the public Internet) ... I don't see any technical reason why providers all over the world still aren't able (or willing) to do v6 ... of course I know you can't force customers to provide services on v6 (or even to use v6 - I believe of our customers, maybe 1% actively use v6, and another few percent use it unknowingly :) ). >From our point of view, we could drop external v4 pretty quickly if it weren't required to reach (or be reached) by v4-only users/services ... -garry -- Garry Glendown * Professional Services & Solutions NETHINKS GmbH | Bahnhofstra?e 16 | 36037 Fulda T +49 661 25 000 0 | F +49 661 25 000 49 | garry.glendown at nethinks.com Gesch?ftsf?hrer: Uwe Bergmann, Bastian Marmetschke Vorsitzender des Aufsichtsrats: Garry Glendown | AG Fulda HRB 2546 PGP Fingerprint: B1CF 4952 F6EB E060 8A10 B957 700E F97F B412 DD32 ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From cfriacas at fccn.pt Tue Feb 5 08:58:42 2019 From: cfriacas at fccn.pt (=?ISO-8859-15?Q?Carlos_Fria=E7as?=) Date: Tue, 5 Feb 2019 07:58:42 +0000 (WET) Subject: [address-policy-wg] 2019-02 New Policy Proposal (Reducing IPv4 Allocations to a /24) In-Reply-To: <3a24cca4-02e0-b1c3-6a23-98d47d207436@fud.no> References: <3a24cca4-02e0-b1c3-6a23-98d47d207436@fud.no> Message-ID: On Tue, 5 Feb 2019, Tore Anderson wrote: > * Marco Schmidt > >> A new RIPE Policy proposal, 2019-02, "Reducing IPv4 Allocations to a /24" >> is now available for discussion. >> >> This proposal aims to reduce the IPv4 allocation size to a /24 once the >> RIPE NCC is unable to allocate contiguous /22 ranges. > > I support this proposal. Some random thoughts about it: Hi, Some comments inline: > - It is good to have the policy explicitly say there is a waiting list. > Current policy says nothing about this. If the NCC would simply close > allocation tickets with ?sorry, fresh out, try later?, that could > encourage LIRs to spam repeated allocation requests in the hope that > theirs was the first request to be received after an IPv4 fragment > was returned to the allocation pool. Yes, and that "randomness" would be everything except "fair". > - I don't quite believe that the waiting list would grow indefinitely > (regardless of the allocation size being /22 or /24). Keep in mind > that only new and IPv4-less LIRs would be able to join the waiting > list. Once it is known that simply joining the NCC won't guarantee > a /22, but that you'd have to wait for one with no certainty as to > how long, I expect that the sign-up rate of new LIRs will drop > dramatically (and by extension the amount of LIRs queuing up in the > waiting list). If getting a /24 is still cheaper than getting a /24 from "the market", people will queue up, because there will be still a bit of profit... On a personal viewpoint, i also hope newcomers come to the RIPE NCC for IPv4, so they can be flooded with information about IPv6 :-) > - It seems reasonable to lower the allocation unit to the de facto > smallest usable on the public Internet at a point in time when we > can no longer allocate /22s (which are already pretty small). > Otherwise recovered /23 and /24 fragments (e.g., PI assignments) > will just end up rotting away in the NCC inventory, which serves > no good purpose at all. Yes, growing up the NCC's IPv4 inventory will serve noone, except if a policy is accepted in the future to re-open IPv4 distribution, when the inventory reaches some level. I clearly prefer to see /24s distributed to those who want them. > - It seems reasonable to trigger this policy at precisely at a > watershed moment like the policy aims to do (unlike 2017-03, which > would have changed the rules in the middle of the game). As you may have noticed i was also one of the co-authors of 2017-03, and that one was withdrawn. But the current proposal is not 2017-03, and i feel this is needed especially after getting input from the NCC about the amount of address space they are getting back -- due to several reasons. > - The authors should clarify how this new policy interacts with the > /16 set aside in ?5.2 Unforeseen circumstances?. In which order > does the 5.2 and 5.1bis policies get triggered? I wouldn't touch that. Would let the NCC decide what are "unforeseen circumstances" or wait for a new, different, policy proposal. We might tackle this issue at v2.0, but i would like to keep changes at a minimum, in this proposal's scope. Best Regards, Carlos > Tore > From phessler at theapt.org Tue Feb 5 09:01:52 2019 From: phessler at theapt.org (Peter Hessler) Date: Tue, 5 Feb 2019 09:01:52 +0100 Subject: [address-policy-wg] 2019-02 New Policy Proposal (Reducing IPv4 Allocations to a /24) In-Reply-To: <387ff9aa-f98e-4be7-2904-a20a0c04e29c@nethinks.com> References: <20190204124140.GV56439@carcass.ledeuns.net> <1549286099.28715.34.camel@aspl.es> <43861F5C-D338-4907-B092-DA528EA97155@steffann.nl> <97ABDD02-4D99-4167-8363-66C0B5AAA18C@rfc1035.com> <683748ee-66ce-2235-176c-0160d19ee40e@fud.no> <387ff9aa-f98e-4be7-2904-a20a0c04e29c@nethinks.com> Message-ID: <20190205080152.GS34686@gir.theapt.org> On 2019 Feb 05 (Tue) at 08:53:21 +0100 (+0100), garry at nethinks.com wrote: :That is an option. But in order to not punish late entries to the :market, it should also include a fixed timeframe when EVERYBODY has to :stop using v4 (at least on the public Internet) ... I don't see any :technical reason why providers all over the world still aren't able (or :willing) to do v6 ... of course I know you can't force customers to :provide services on v6 (or even to use v6 - I believe of our customers, :maybe 1% actively use v6, and another few percent use it unknowingly :) ). :From our point of view, we could drop external v4 pretty quickly if it :weren't required to reach (or be reached) by v4-only users/services ... Then come back when you have a solution to force GitHub, Twitter, Amazon, and a lot more, to launch an IPv6 version of their website. -- Command, n.: Statement presented by a human and accepted by a computer in such a manner as to make the human feel as if he is in control. From tore at fud.no Tue Feb 5 09:14:28 2019 From: tore at fud.no (Tore Anderson) Date: Tue, 5 Feb 2019 09:14:28 +0100 Subject: [address-policy-wg] 2019-02 New Policy Proposal (Reducing IPv4 Allocations to a /24) In-Reply-To: References: <3a24cca4-02e0-b1c3-6a23-98d47d207436@fud.no> Message-ID: <0b677cc5-4f75-2f07-707e-67ce795f9d9a@fud.no> * Carlos Fria?as via address-policy-wg > > On Tue, 5 Feb 2019, Tore Anderson wrote: > >> - I don't quite believe that the waiting list would grow indefinitely >> ?(regardless of the allocation size being /22 or /24). Keep in mind >> ?that only new and IPv4-less LIRs would be able to join the waiting >> ?list. Once it is known that simply joining the NCC won't guarantee >> ?a /22, but that you'd have to wait for one with no certainty as to >> ?how long, I expect that the sign-up rate of new LIRs will drop >> ?dramatically (and by extension the amount of LIRs queuing up in the >> ?waiting list). > > If getting a /24 is still cheaper than getting a /24 from "the market", people will queue up, because there will be still a bit of profit... Except that you wouldn't be able to know the price in advance and compare it to market price, because you simply don't know how long you'll have to wait in line (while paying full membership fees from day one). This uncertainty will certainly also discourage LIRs from signing up as member just to get IPv4 - regardless of the economics. Say, if you need IPv4 to deliver a project due in six months, then getting it from the market will be the only way that would give you sufficient certainty that you can deliver on time. Tore From tore at fud.no Tue Feb 5 09:19:41 2019 From: tore at fud.no (Tore Anderson) Date: Tue, 5 Feb 2019 09:19:41 +0100 Subject: [address-policy-wg] 2019-02 New Policy Proposal (Reducing IPv4 Allocations to a /24) In-Reply-To: <387ff9aa-f98e-4be7-2904-a20a0c04e29c@nethinks.com> References: <20190204124140.GV56439@carcass.ledeuns.net> <1549286099.28715.34.camel@aspl.es> <43861F5C-D338-4907-B092-DA528EA97155@steffann.nl> <97ABDD02-4D99-4167-8363-66C0B5AAA18C@rfc1035.com> <683748ee-66ce-2235-176c-0160d19ee40e@fud.no> <387ff9aa-f98e-4be7-2904-a20a0c04e29c@nethinks.com> Message-ID: * garry at nethinks.com > But in order to not punish late entries to the market, it should also include a fixed timeframe when EVERYBODY has to stop using v4 (at least on the public Internet) ... We don't have the authority to impose such a timeframe on ?EVERYBODY?. Late entrants are going to feel punished no matter what we do in this working group. C'est la vie. Tore From uros at ub330.net Tue Feb 5 10:03:50 2019 From: uros at ub330.net (Uros Gaber) Date: Tue, 5 Feb 2019 10:03:50 +0100 Subject: [address-policy-wg] 2019-02 New Policy Proposal (Reducing IPv4 Allocations to a /24) In-Reply-To: <0b677cc5-4f75-2f07-707e-67ce795f9d9a@fud.no> References: <3a24cca4-02e0-b1c3-6a23-98d47d207436@fud.no> <0b677cc5-4f75-2f07-707e-67ce795f9d9a@fud.no> Message-ID: > This uncertainty will certainly also discourage LIRs from signing > up as member just to get IPv4 - regardless of the economics. Say, > if you need IPv4 to deliver a project due in six months, then > getting it from the market will be the only way that would give > you sufficient certainty that you can deliver on time. > > Depending on the project, AFAIK temporary allocations are/will still be possible. Uros -------------- next part -------------- An HTML attachment was scrubbed... URL: From cfriacas at fccn.pt Tue Feb 5 10:37:08 2019 From: cfriacas at fccn.pt (=?ISO-8859-15?Q?Carlos_Fria=E7as?=) Date: Tue, 5 Feb 2019 09:37:08 +0000 (WET) Subject: [address-policy-wg] 2019-02 New Policy Proposal (Reducing IPv4 Allocations to a /24) In-Reply-To: <387ff9aa-f98e-4be7-2904-a20a0c04e29c@nethinks.com> References: <20190204124140.GV56439@carcass.ledeuns.net> <1549286099.28715.34.camel@aspl.es> <43861F5C-D338-4907-B092-DA528EA97155@steffann.nl> <97ABDD02-4D99-4167-8363-66C0B5AAA18C@rfc1035.com> <683748ee-66ce-2235-176c-0160d19ee40e@fud.no> <387ff9aa-f98e-4be7-2904-a20a0c04e29c@nethinks.com> Message-ID: Hi, please see inline. On Tue, 5 Feb 2019, garry at nethinks.com wrote: > That is an option. But in order to not punish late entries to the market, Some "late entries" are/will not be market driven. Some companies/organisations could only be searching for a way to become independent from their ISPs/suppliers, and the only way they can do that (IPv4-wise) is to become a LIR and get their own chunk. I also hope that by doing so, they will also be flooded with information about IPv6. > it should also include a fixed timeframe when > EVERYBODY has to stop using v4 (at least on the public Internet) ... A flag day won't work. There are simply too many networks. > I don't see any technical reason why providers all over > the world still aren't able (or willing) to do v6 ... of course I know > you can't force customers to provide services on v6 (or even to use v6 - Yes, that's the main point. People use what they know it works, and they need to be comfortable about what they are using/managing. If all networks in the world were run by 10 or 100 people, then yes, an agreed change would be possible. However, that's not the case, so co-existence for a long period is unavoidable. >I believe of our customers, maybe 1% actively use v6, and another few > percent use it unknowingly :) ). Yes, people should be using IPv6 unknowingly (in a transparent way), but it's useful that network managers and sysadmins know about it :-) > From our point of view, we could drop external v4 pretty quickly if it > weren't required to reach (or be reached) by v4-only users/services ... That's everyone's case, i'm afraid :-)) I've been deploying and advocating IPv6 since 2001. Others have been doing it for a longer period. Within this timespan, i have only read about *one* organisation which publicly expressed plans to scrap IPv4 from their network/services, but they have dropped that in the meanwhile... IPv6 will not happen by decree, it is happenning, slowly, due to need and a vision for Internet's growth (imho). Best Regards, Carlos > -garry > > -- > > Garry Glendown * Professional Services & Solutions > > NETHINKS GmbH | Bahnhofstra?e 16 | 36037 Fulda T +49 661 25 000 0 | F +49 661 25 000 49 | garry.glendown at nethinks.com > Gesch?ftsf?hrer: Uwe Bergmann, Bastian Marmetschke Vorsitzender des Aufsichtsrats: Garry Glendown | AG Fulda HRB 2546 > > PGP Fingerprint: B1CF 4952 F6EB E060 8A10 B957 700E F97F B412 DD32 From sander at steffann.nl Tue Feb 5 11:15:55 2019 From: sander at steffann.nl (Sander Steffann) Date: Tue, 5 Feb 2019 11:15:55 +0100 Subject: [address-policy-wg] 2019-02 New Policy Proposal (Reducing IPv4 Allocations to a /24) In-Reply-To: <74a744065016eec40761b0406345e35f@klaver.it> References: <01594E1D-ECBF-4E70-844A-71F76291A981@steffann.nl> <74a744065016eec40761b0406345e35f@klaver.it> Message-ID: Hi Michiel, > Just another point for discussion: what to do when this /24-only policy is in effect and RIPE NCC happens to recover a large chunk (e.g. /16 or more) and is able to hand-out multiple /22's again? The policy explicitly states that once the waiting list policy is in effect the old policy is removed. So the large block would be used to process requests from the waiting list. Cheers, Sander -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: Message signed with OpenPGP URL: From cfriacas at fccn.pt Tue Feb 5 11:21:27 2019 From: cfriacas at fccn.pt (=?ISO-8859-15?Q?Carlos_Fria=E7as?=) Date: Tue, 5 Feb 2019 10:21:27 +0000 (WET) Subject: [address-policy-wg] 2019-02 New Policy Proposal (Reducing IPv4 Allocations to a /24) In-Reply-To: References: <3a24cca4-02e0-b1c3-6a23-98d47d207436@fud.no> <0b677cc5-4f75-2f07-707e-67ce795f9d9a@fud.no> Message-ID: On Tue, 5 Feb 2019, Uros Gaber wrote: > > This uncertainty will certainly also discourage LIRs from signing > up as member just to get IPv4 - regardless of the economics. Say, > if you need IPv4 to deliver a project due in six months, then > getting it from the market will be the only way that would give > you sufficient certainty that you can deliver on time. > > > Depending on the project, AFAIK temporary allocations are/will still be possible. Yes... people do lease ip address space... Carlos > Uros > > From frettled at gmail.com Tue Feb 5 11:22:15 2019 From: frettled at gmail.com (Jan Ingvoldstad) Date: Tue, 5 Feb 2019 11:22:15 +0100 Subject: [address-policy-wg] 2019-02 New Policy Proposal (Reducing IPv4 Allocations to a /24) In-Reply-To: References: <01594E1D-ECBF-4E70-844A-71F76291A981@steffann.nl> <74a744065016eec40761b0406345e35f@klaver.it> Message-ID: On Tue, Feb 5, 2019 at 11:16 AM Sander Steffann wrote: > Hi Michiel, > > > Just another point for discussion: what to do when this /24-only policy > is in effect and RIPE NCC happens to recover a large chunk (e.g. /16 or > more) and is able to hand-out multiple /22's again? > > The policy explicitly states that once the waiting list policy is in > effect the old policy is removed. So the large block would be used to > process requests from the waiting list. > > Yup, and also: a /16 isn't a large chunk in comparison to the waiting list. It's only 256x /24 blocks. If I read the graphs right, it would be gone in less than a month. -- Jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From michiel at klaver.it Tue Feb 5 11:14:02 2019 From: michiel at klaver.it (Michiel Klaver) Date: Tue, 05 Feb 2019 11:14:02 +0100 Subject: [address-policy-wg] 2019-02 New Policy Proposal (Reducing IPv4 Allocations to a /24) In-Reply-To: <01594E1D-ECBF-4E70-844A-71F76291A981@steffann.nl> References: <01594E1D-ECBF-4E70-844A-71F76291A981@steffann.nl> Message-ID: <74a744065016eec40761b0406345e35f@klaver.it> Sander Steffann wrote at 2019-02-04 16:02: > Hello working group, > > The first comments I got back on this proposal all seemed to miss the > point of it. Let me explicitly state what this policy is NOT about: > - it is NOT about conserving IPv4 addresses > - it is NOT about postponing the runout date > - it is NOT about extending the lifetime of IPv4 > > It's purpose is solely about: > - dealing with the returned address space the NCC will get over the > years > > Under the current policy: > - the waiting list will grow indefinitely > - the allocations given out will consist of tiny fragments > - it will therefore not be of any practical use > > This proposal proposes: > - keeping /22 until we run out of /22s > - give out /24s only after that > - this helps to keep the waiting list manageable [1] > - declare everything smaller (longer prefix) than a /24 unusable > - this helps against people getting unusable dust > > [1]: see > https://ripe77.ripe.net/presentations/71-Andrea_Cima_RIPE_77_APWG.pdf > slide 14 > > Please forget about previous attempts to change allocation sizes. > Those were about changing the current allocation policy. This proposal > only looks forward to what to do after the current policy becomes > unusable. Please focus on that. > > Cheers, > Sander Just another point for discussion: what to do when this /24-only policy is in effect and RIPE NCC happens to recover a large chunk (e.g. /16 or more) and is able to hand-out multiple /22's again? From cfriacas at fccn.pt Tue Feb 5 11:35:28 2019 From: cfriacas at fccn.pt (=?ISO-8859-15?Q?Carlos_Fria=E7as?=) Date: Tue, 5 Feb 2019 10:35:28 +0000 (WET) Subject: [address-policy-wg] 2019-02 New Policy Proposal (Reducing IPv4 Allocations to a /24) In-Reply-To: References: Message-ID: On Mon, 4 Feb 2019, Jetten Raymond wrote: > > Hi, Hi Raymond, > I strongly oppose this proposal, a similar proposal was mode before, (2017-03) , > and I agree with the arguments opposing the proposal. It's really not the same proposal, although i'm the common link between 2019-02 and 2017-03. Maybe the title could be more explicit about the moment when the proposed changes would kick in. Which specific opposing arguments (to 2019-02) do you agree with? Each one has a written counter-argument/mitigation. Can you please point out which ones do you think are not valid? Best Regards, Carlos > Rgds, > > Ray > > -----Original Message----- > From: address-policy-wg On Behalf Of Marco Schmidt > Sent: 4. helmikuuta 2019 14:04 > To: address-policy-wg at ripe.net > Subject: [address-policy-wg] 2019-02 New Policy Proposal (Reducing IPv4 Allocations to a /24) > > Dear colleagues, > > A new RIPE Policy proposal, 2019-02, "Reducing IPv4 Allocations to a /24" > is now available for discussion. > > This proposal aims to reduce the IPv4 allocation size to a /24 once the > RIPE NCC is unable to allocate contiguous /22 ranges. > > You can find the full proposal at: > https://www.ripe.net/participate/policies/proposals/2019-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 proposer. > > At the end of the Discussion Phase, the proposer, with the agreement of > the WG Chairs, will decide how to proceed with the proposal. > > We encourage you to review this proposal and send your comments to > before 5 March 2019. > > Regards, > > Marco Schmidt > Policy Officer > > > From alex at vpsville.ru Tue Feb 5 13:25:36 2019 From: alex at vpsville.ru (Alexey Galaev) Date: Tue, 5 Feb 2019 15:25:36 +0300 (MSK) Subject: [address-policy-wg] 2019-02 New Policy Proposal (Reducing IPv4 Allocations to a /24) In-Reply-To: References: Message-ID: <1014795753.1241.1549369536064.JavaMail.zimbra@vpsville.ru> Hello. I strongly oppose this proposal. Why there are no proposal with increasing IPv4 Allocations to /19, for example? Why many years ago new LIRs get /19 for free, but today we need to reduce new members? Let check how many IPv4 not announce by BGP or return 250.0.0.0/8 to the free pool. BR, Alexey Galaev +7 985 3608004, http://vpsville.ru http://cloudville.ru ----- ???????? ????????? ----- ??: "Marco Schmidt" ????: "address-policy-wg" ????????????: ???????????, 4 ??????? 2019 ? 15:04:26 ????: [address-policy-wg] 2019-02 New Policy Proposal (Reducing IPv4 Allocations to a /24) Dear colleagues, A new RIPE Policy proposal, 2019-02, "Reducing IPv4 Allocations to a /24" is now available for discussion. This proposal aims to reduce the IPv4 allocation size to a /24 once the RIPE NCC is unable to allocate contiguous /22 ranges. You can find the full proposal at: https://www.ripe.net/participate/policies/proposals/2019-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 proposer. At the end of the Discussion Phase, the proposer, with the agreement of the WG Chairs, will decide how to proceed with the proposal. We encourage you to review this proposal and send your comments to before 5 March 2019. Regards, Marco Schmidt Policy Officer From frettled at gmail.com Tue Feb 5 13:59:17 2019 From: frettled at gmail.com (Jan Ingvoldstad) Date: Tue, 5 Feb 2019 13:59:17 +0100 Subject: [address-policy-wg] 2019-02 New Policy Proposal (Reducing IPv4 Allocations to a /24) In-Reply-To: <1014795753.1241.1549369536064.JavaMail.zimbra@vpsville.ru> References: <1014795753.1241.1549369536064.JavaMail.zimbra@vpsville.ru> Message-ID: On Tue, Feb 5, 2019 at 1:26 PM Alexey Galaev wrote: > Hello. > I strongly oppose this proposal. > Why there are no proposal with increasing IPv4 Allocations to /19, for > example? > Because you and others who think this is possible and desirable, have not bothered to do so. Put up the proposal, with a clear analysis that shows how this can be realistically implemented. -- Jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From jim at rfc1035.com Tue Feb 5 14:07:58 2019 From: jim at rfc1035.com (Jim Reid) Date: Tue, 5 Feb 2019 13:07:58 +0000 Subject: [address-policy-wg] Bad Ideas in Address Policy In-Reply-To: <1014795753.1241.1549369536064.JavaMail.zimbra@vpsville.ru> References: <1014795753.1241.1549369536064.JavaMail.zimbra@vpsville.ru> Message-ID: On 5 Feb 2019, at 12:25, Alexey Galaev wrote: > > Let check how many IPv4 not announce by BGP IP addresses can be used without them being routed on the public Internet. It?s also possible to make BGP announcements that tell lies. It?s not feasible for an RIR to recover address space from an LIR (unless the LIR voluntarily hands it over), assuming there was a suitable policy in place. Which there isn?t. > return 250.0.0.0/8 to the free pool That?s not going to help either. [Assuming we knew for sure there?s absolutely nothing deployed today that won?t fail or misbehave if that ~40 year old reserved address range was brought into use.] Activating 250/8 would just postpone the exhaustion point by a few months. And then we?d be back to where we are today. No matter what we do to conserve or reclaim IPv4 addresses, there simply isn?t enough of them. Our planet has 7-8 billion people and there are only 4 billion IPv4 addresses. From cfriacas at fccn.pt Tue Feb 5 14:12:23 2019 From: cfriacas at fccn.pt (=?ISO-8859-15?Q?Carlos_Fria=E7as?=) Date: Tue, 5 Feb 2019 13:12:23 +0000 (WET) Subject: [address-policy-wg] 2019-02 New Policy Proposal (Reducing IPv4 Allocations to a /24) In-Reply-To: <1014795753.1241.1549369536064.JavaMail.zimbra@vpsville.ru> References: <1014795753.1241.1549369536064.JavaMail.zimbra@vpsville.ru> Message-ID: On Tue, 5 Feb 2019, Alexey Galaev wrote: > Hello. Hello, > I strongly oppose this proposal. > Why there are no proposal with increasing IPv4 Allocations to /19, for example? Everyone is free to submit any proposal, following the PDP. 2019-02 is not about adjustements to the past. It's mainly about clarifying rules for the upcoming "waiting list age". If a proposal to move from /22 to /19 is accepted, the "waiting list age" will arrive a lot sooner... :-) > Why many years ago new LIRs get /19 for free, but today we need to reduce new members? It wasn't "for free". Existing (and new LIRs) received allocations based on needs they were able to demonstrate. That was the current policy, before Sept/2012. > Let check how many IPv4 not announce by BGP Allocations (present, past or future) don't depend on the criteria of global routing visibility. Company X and company Z might want to communicate over a private channel without using private addressing space. The keyword here is "uniqueness". > or return 250.0.0.0/8 to the free pool. You mean 240.0.0.0/4? (i.e. 16x /8s) I've asked that question myself. The answer from knowledgeable people didn't really change anything :-) Cheers, Carlos > > BR, > Alexey Galaev > +7 985 3608004, http://vpsville.ru http://cloudville.ru > > ----- ???????? ????????? ----- > ??: "Marco Schmidt" > ????: "address-policy-wg" > ????????????: ???????????, 4 ??????? 2019 ? 15:04:26 > ????: [address-policy-wg] 2019-02 New Policy Proposal (Reducing IPv4 Allocations to a /24) > > Dear colleagues, > > A new RIPE Policy proposal, 2019-02, "Reducing IPv4 Allocations to a /24" > is now available for discussion. > > This proposal aims to reduce the IPv4 allocation size to a /24 once the > RIPE NCC is unable to allocate contiguous /22 ranges. > > You can find the full proposal at: > https://www.ripe.net/participate/policies/proposals/2019-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 proposer. > > At the end of the Discussion Phase, the proposer, with the agreement of > the WG Chairs, will decide how to proceed with the proposal. > > We encourage you to review this proposal and send your comments to > before 5 March 2019. > > Regards, > > Marco Schmidt > Policy Officer > From mika at net-cat.at Tue Feb 5 19:18:45 2019 From: mika at net-cat.at (Michael Kafka) Date: Tue, 05 Feb 2019 19:18:45 +0100 Subject: [address-policy-wg] New on this list, cannot reply to old topic Message-ID: <5C59D385.7050808@net-cat.at> Hi everyone, I'd like to join the discussion here on the list but I just registered so I can't reply to the existing topic and I don't want to start a new thread. For the sake of a clean thread, can someone please reply to: [address-policy-wg] 2019-02 New Policy Proposal (Reducing IPv4 Allocations to a /24) Thanks, MiKa From cfriacas at fccn.pt Wed Feb 6 00:19:21 2019 From: cfriacas at fccn.pt (=?ISO-8859-15?Q?Carlos_Fria=E7as?=) Date: Tue, 5 Feb 2019 23:19:21 +0000 (WET) Subject: [address-policy-wg] 2019-02 New Policy Proposal (Reducing IPv4 Allocations to a /24) (fwd) Message-ID: I was unaware about this list limitation, but hope this helps... :-) Regards, Carlos ========= Date: Tue, 5 Feb 2019 18:18:45 From: Michael Kafka To: address-policy-wg at ripe.net Subject: [address-policy-wg] New on this list, cannot reply to old topic Hi everyone, I'd like to join the discussion here on the list but I just registered so I can't reply to the existing topic and I don't want to start a new thread. For the sake of a clean thread, can someone please reply to: [address-policy-wg] 2019-02 New Policy Proposal (Reducing IPv4 Allocations to a /24) Thanks, MiKa ---------- Forwarded message ---------- Date: Mon, 4 Feb 2019 12:04:26 From: Marco Schmidt To: "address-policy-wg at ripe.net" Subject: [address-policy-wg] 2019-02 New Policy Proposal (Reducing IPv4 Allocations to a /24) Dear colleagues, A new RIPE Policy proposal, 2019-02, "Reducing IPv4 Allocations to a /24" is now available for discussion. This proposal aims to reduce the IPv4 allocation size to a /24 once the RIPE NCC is unable to allocate contiguous /22 ranges. You can find the full proposal at: https://www.ripe.net/participate/policies/proposals/2019-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 proposer. At the end of the Discussion Phase, the proposer, with the agreement of the WG Chairs, will decide how to proceed with the proposal. We encourage you to review this proposal and send your comments to before 5 March 2019. Regards, Marco Schmidt Policy Officer From cfriacas at fccn.pt Wed Feb 6 00:21:30 2019 From: cfriacas at fccn.pt (=?ISO-8859-15?Q?Carlos_Fria=E7as?=) Date: Tue, 5 Feb 2019 23:21:30 +0000 (WET) Subject: [address-policy-wg] 2019-02 New Policy Proposal (Reducing IPv4 Allocations to a /24) In-Reply-To: References: Message-ID: Forward didn't work, so trying "Reply". :-) Carlos On Mon, 4 Feb 2019, Marco Schmidt wrote: > Dear colleagues, > > A new RIPE Policy proposal, 2019-02, "Reducing IPv4 Allocations to a /24" > is now available for discussion. > > This proposal aims to reduce the IPv4 allocation size to a /24 once the > RIPE NCC is unable to allocate contiguous /22 ranges. > > You can find the full proposal at: > https://www.ripe.net/participate/policies/proposals/2019-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 proposer. > > At the end of the Discussion Phase, the proposer, with the agreement of > the WG Chairs, will decide how to proceed with the proposal. > > We encourage you to review this proposal and send your comments to > before 5 March 2019. > > Regards, > > Marco Schmidt > Policy Officer > > From ml at servperso.com Wed Feb 6 00:25:48 2019 From: ml at servperso.com (Cedric R) Date: Wed, 6 Feb 2019 00:25:48 +0100 Subject: [address-policy-wg] 2019-02 New Policy Proposal (Reducing IPv4 Allocations to a /24) (fwd) In-Reply-To: References: Message-ID: <0318b606-15dd-52be-861f-251d61e7bc27@servperso.com> Hello, After reading the prupose and some archive on this mailing (you can over ripe website) , i have an idea about the reason of prupose. The /24 proposal is for emergency when ripe run out of V4 (5M address now, aprox 5K new LIR). Why not doing a prupose based on LIR, a first lir account receive a /22, if a same entity open a second account, they only receive a /24. That prupose is to avoid some LIR with huge amount take all space and let's nothing for small LIR wo can't do. Actualy a /22 from RIPE cost 4800? VAT EXCL (2 year + setup) , on market it's 15- 20K? I know some company can have multiple entity to buy extra range. Some company is cheap to register like in UK. Maybe use company UBO registry obligation in EU can fight that ? Best regards Cedric Le 06-02-19 ? 00:19, Carlos Fria?as via address-policy-wg a ?crit?: > > I was unaware about this list limitation, but hope this helps... :-) > > Regards, > Carlos > > ========= > Date: Tue, 5 Feb 2019 18:18:45 > From: Michael Kafka > To: address-policy-wg at ripe.net > Subject: [address-policy-wg] New on this list, cannot reply to old topic > > Hi everyone, > > I'd like to join the discussion here on the list but I just registered > so I can't reply to the existing topic and I don't want to start a new > thread. > > For the sake of a clean thread, can someone please reply to: > [address-policy-wg] 2019-02 New Policy Proposal (Reducing IPv4 > Allocations to a /24) > > Thanks, MiKa > > > ---------- Forwarded message ---------- > Date: Mon, 4 Feb 2019 12:04:26 > From: Marco Schmidt > To: "address-policy-wg at ripe.net" > Subject: [address-policy-wg] 2019-02 New Policy Proposal (Reducing IPv4 > ??? Allocations to a /24) > > Dear colleagues, > > A new RIPE Policy proposal, 2019-02, "Reducing IPv4 Allocations to a /24" > is now available for discussion. > > This proposal aims to reduce the IPv4 allocation size to a /24 once the > RIPE NCC is unable to allocate contiguous /22 ranges. > > You can find the full proposal at: > https://www.ripe.net/participate/policies/proposals/2019-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 proposer. > > At the end of the Discussion Phase, the proposer, with the agreement of > the WG Chairs, will decide how to proceed with the proposal. > > We encourage you to review this proposal and send your comments to > before 5 March 2019. > > Regards, > > Marco Schmidt > Policy Officer > > From wusel+ml at uu.org Wed Feb 6 01:42:11 2019 From: wusel+ml at uu.org (Kai 'wusel' Siering) Date: Wed, 6 Feb 2019 01:42:11 +0100 Subject: [address-policy-wg] 2019-02 New Policy Proposal (Reducing IPv4 Allocations to a /24) (fwd) In-Reply-To: <0318b606-15dd-52be-861f-251d61e7bc27@servperso.com> References: <0318b606-15dd-52be-861f-251d61e7bc27@servperso.com> Message-ID: Moin, am 06.02.2019 um 00:25 schrieb Cedric R via address-policy-wg: > Why not doing a prupose based on LIR, a first lir account receive a /22, if a same entity open a second account, they only receive a /24. First: it just won't be "the same entity". While it may be the same actors, it's usually a separate legal entity, so no cookies. Second: as soon as the currently available IPv4 resources fell dry, there's an issue: by current policy, a new LIR is entitled to receive a /22 worth of addresses. If RIPE NCC cannot serve this at registration time, what happens then? AFAIKS this ist not yet covered by policy. > That prupose is to avoid some LIR with huge amount take all space and let's nothing for small LIR wo can't do. Sorry to say this, but: that has been tried to avoid and proved to be "difficult" at best. One cannot prevent others from going corporate a dozen of times, each time setting up an LIR, each time taking a /something IPv4. Not easily, not without hurting legitimate newcomers. > Actualy a /22 from RIPE cost 4800? VAT EXCL (2 year + setup) , on market it's 15- 20K? Yes, but raising the RIPE membership fee to 10k/year would face other issues (like, being a non-profit, what to do with the surplus? Redistributing it to the members would just mean _entry_ is expensive, not _staying_) ... > I know some company can have multiple entity to buy extra range. Some company is cheap to register like in UK. > Maybe use company UBO registry obligation in EU can fight that ? RIPE Region does cover more than just EU (EU28 or EU27 doesn't matter here). Regards, -kai From dfk at ripe.net Wed Feb 6 10:39:24 2019 From: dfk at ripe.net (Daniel Karrenberg) Date: Wed, 6 Feb 2019 10:39:24 +0100 Subject: [address-policy-wg] 2019-02 New Policy Proposal (Reducing IPv4 Allocations to a /24) In-Reply-To: References: Message-ID: After reading and thinking I arrive at the following principles: a) It is not tenable for the RIPE NCC to stop allocating IPv4 addresses as long as it has blocks that are useful to route packets. Note: As an individual I would very much like to just stop with this silliness. However I do not think this is tenable for us as a community. b) Once the pool decreases below that threshold the RIPE NCC has to maintain a waiting list in order to establish a sequence in case space becomes availble. Reason: see (a) c) It is not tenable for the RIPE NCC to require the first LIR on the waiting list to wait for more address space than a minimal usfeful block to accumulate. d) The length of the waiting list and other practicalities should be secondary considerations after these principles above. For instance, the RIPE NCC can always recover the costs incurred by the process from those using it. The policy captures these principles. The policy can be improved in a number of ways. Here are some considerations for the proposers in case they would wish to revise it: 1) Motivate the choice for /24 in terms of being the smallest block useful to route packets considering current routing practice. 2) Explicitly mention the non-goals of the policy as discussed. 3) Keep in mind our good experience with using concrete dates for policy changes. Consider to make the change on a specific date. This is more predictable than an event sometime in the future. "Run Out Fairly" worked pretty well. Specifically why not just say "This polixy into effect on September 1st 2019"? 4) The policy could be made more adaptable to future scenarios. This would prevent more ad-hoc policy changes which are a pain and do not look very professional to the world outside RIPE. Maybe the policy could be 'parameterised' so that the community can decide to change parameters rather than re-write the policy text. 4a) Consider the possibility that future routing practice may change the longest useful routing prefix away from a /24 as Randy alluded to. This should be a parameter. 4b) Consider the possibility, however unlikely, that the RIPE NCC receives a significant amount of address space to re-distribute. Would this policy still be supported by the community in this event? Should the allocation size be a parameter that can increase above the either by community choice or automatically if a certain pool size is exceeded? 4c) What happens down the road when IPv4 really becomes legacy? Can we make the policy applicable even then? Would (4) and (5) above do the trick? 5) Maybe mention explicitly that one has to be a LIR in good standing to be on the waiting list. Daniel From dfk at ripe.net Wed Feb 6 10:46:50 2019 From: dfk at ripe.net (Daniel Karrenberg) Date: Wed, 6 Feb 2019 10:46:50 +0100 Subject: [address-policy-wg] 2019-02 New Policy Proposal (Reducing IPv4 Allocations to a /24) In-Reply-To: References: Message-ID: <1e29f869-b10b-0f1b-26fd-354e6a169b27@ripe.net> Oh my! I kept revising this and introduced crap while doing so. For clarity: On 06/02/2019 10:39, Daniel Karrenberg wrote: > ... Specifically why not just say "This polixy into > effect on September 1st 2019"? "This policy comes into effect om Spetember 1st 2019." > ... Would (4) and (5) above do the trick? Would (4a) and (4b) above do the trick? Daniel From cfriacas at fccn.pt Wed Feb 6 11:06:37 2019 From: cfriacas at fccn.pt (=?ISO-8859-15?Q?Carlos_Fria=E7as?=) Date: Wed, 6 Feb 2019 10:06:37 +0000 (WET) Subject: [address-policy-wg] 2019-02 New Policy Proposal (Reducing IPv4 Allocations to a /24) (fwd) In-Reply-To: References: <0318b606-15dd-52be-861f-251d61e7bc27@servperso.com> Message-ID: On Wed, 6 Feb 2019, Kai 'wusel' Siering wrote: (...) > >> I know some company can have multiple entity to buy extra range. Some company is cheap to register like in UK. >> Maybe use company UBO registry obligation in EU can fight that ? > > RIPE Region does cover more than just EU (EU28 or EU27 doesn't matter here). Precisely. As i understand it, any company in the world just needs to declare that has infrastructure within the RIPE NCC service region in order to access RIPE NCC services. I didn't check, but i've heard this doesn't work in the same way on the other four RIRs... I think changes to this can be addressed through the PDP, but someone has to issue the proposal for this to happen. Cheers, Carlos > Regards, > -kai > > > From jim at rfc1035.com Wed Feb 6 11:19:15 2019 From: jim at rfc1035.com (Jim Reid) Date: Wed, 6 Feb 2019 10:19:15 +0000 Subject: [address-policy-wg] 2019-02 New Policy Proposal (Reducing IPv4 Allocations to a /24) In-Reply-To: References: Message-ID: On 6 Feb 2019, at 09:39, Daniel Karrenberg wrote: > > a) It is not tenable for the RIPE NCC to stop allocating IPv4 addresses > as long as it has blocks that are useful to route packets. In principle, yes. In practice, no. There will come a point where it will be more bother than it?s worth to allocate teeny blocks from the dregs of the dregs. [Do we really want to one day be issuing each new LIR with exactly 1 IPv4 address so they can plug in to a v4-only IXP or transit provider?] When that tipping point is reached, I would hope the NCC makes an orderly exit from its IPv4 allocation business instead of trying to keep it alive at all costs. The question here I think is what should be the trigger event. And then what happens to the remaining v4 addresses that fell down the back of the sofa, slipped through the cracks in the floorboards and ended up in a disused basement behind a locked door that has a ?beware of the leopard? sign. Well OK. That?s two questions. :-) How much v4 space would the NCC be holding once it?s no longer got /22s to allocate? That?s three questions. :-) From hunekm at gmail.com Wed Feb 6 11:23:53 2019 From: hunekm at gmail.com (Martin =?utf-8?B?SHVuxJtr?=) Date: Wed, 06 Feb 2019 11:23:53 +0100 Subject: [address-policy-wg] 2019-02 New Policy Proposal (Reducing IPv4 Allocations to a /24) In-Reply-To: References: Message-ID: <2555823.qEnKSUCqr2@hunator-ntb.local> Hi, just a small reaction to what you have written (in line). Dne st?eda 6. ?nora 2019 10:39:24 CET, Daniel Karrenberg napsal(a): > After reading and thinking I arrive at the following principles: > > a) It is not tenable for the RIPE NCC to stop allocating IPv4 addresses > as long as it has blocks that are useful to route packets. > > Note: As an individual I would very much like to just stop with this > silliness. However I do not think this is tenable for us as a community. No problem here. I would be one of them, but I know that there won't be consensus. > > b) Once the pool decreases below that threshold the RIPE NCC has to > maintain a waiting list in order to establish a sequence in case space > becomes availble. Reason: see (a) I also agree with that. > > c) It is not tenable for the RIPE NCC to require the first LIR on the > waiting list to wait for more address space than a minimal usfeful block > to accumulate. Here it starts. I would say get such a LIR what you have got (to /22 of course). Even by means of multiple /24s. But not blocks smaller than /24, as it would be useless. Maybe let them decide if they would like to wait for whole /22 where there would be less then 4x /24 (in that one case). > > d) The length of the waiting list and other practicalities should be > secondary considerations after these principles above. For instance, the > RIPE NCC can always recover the costs incurred by the process from those > using it. No dispute here. > > 1) Motivate the choice for /24 in terms of being the smallest block > useful to route packets considering current routing practice. Also no issue here. Motivate yes, require no. Keep /22 possibility so the complete runout of IPv4 won't be postponed. > > 2) Explicitly mention the non-goals of the policy as discussed. I think that those were discused here in the list. I don't think that it should be written in the policy itself. > > 3) Keep in mind our good experience with using concrete dates for policy > changes. Consider to make the change on a specific date. This is more > predictable than an event sometime in the future. "Run Out Fairly" > worked pretty well. Specifically why not just say "This polixy into > effect on September 1st 2019"? You cannot be sure where it would happen. > > 4) The policy could be made more adaptable to future scenarios. This > would prevent more ad-hoc policy changes which are a pain and do not > look very professional to the world outside RIPE. Maybe the policy could > be 'parameterised' so that the community can decide to change parameters > rather than re-write the policy text. Sure, add there the waiting list if needed, but do not change the /22. This way it will be consistent. > > 4a) Consider the possibility that future routing practice may change the > longest useful routing prefix away from a /24 as Randy alluded to. This > should be a parameter. I'm strongly agains that. Let's keep there explicitly /24 as the longest routable prefix. Allowing a longer one would give a signal to other RIRs that it is fine with us. That would bring yet another deagregation so more junk in routing tables. I'm not sure that we would all agree on changing our BGP filters to allow that. And if so, someone whom will be given such small pool would have problem with reachability. > > 4b) Consider the possibility, however unlikely, that the RIPE NCC > receives a significant amount of address space to re-distribute. Would > this policy still be supported by the community in this event? Should > the allocation size be a parameter that can increase above the usable prefix> either by community choice or automatically if a certain > pool size is exceeded? If you keep there /22 and /24 as an option, than there would be no problem. > > 4c) What happens down the road when IPv4 really becomes legacy? Can we > make the policy applicable even then? Would (4) and (5) above do the trick? Then it would be wise to pass a policy that would say that. Like: "IPv4 is considered to be a legacy protocol. RIPE would not provide any allocation/ assignment of IPv4 resources." Or what ever. > > 5) Maybe mention explicitly that one has to be a LIR in good standing to > be on the waiting list. More LIRs on the list means smaller chance that anyone would get an address pool. So let them wait there, it just as easely may work as a motivation torward IPv6. Like: "Just look at that list! IPv4 is gone for good." Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: This is a digitally signed message part. URL: From jim at rfc1035.com Wed Feb 6 11:40:41 2019 From: jim at rfc1035.com (Jim Reid) Date: Wed, 6 Feb 2019 10:40:41 +0000 Subject: [address-policy-wg] 2019-02 New Policy Proposal (Reducing IPv4 Allocations to a /24) In-Reply-To: References: Message-ID: > On 6 Feb 2019, at 09:39, Daniel Karrenberg wrote: > > d) The length of the waiting list and other practicalities should be > secondary considerations after these principles above. For instance, the > RIPE NCC can always recover the costs incurred by the process from those > using it. That could be awkward Daniel. For instance fair and equitable treatment. Or raising barriers to entry. Then there are the overheads of all that extra bean counting. Passing these costs along is all very well, but why go to the trouble of creating them in the first place? This would also be the start of a slippery slope. Once the NCC introduces hypothecated fees for specific services, it?ll have to do that for everything it does. Which would lead to the membership micromanaging budgets and declining to pay for the stuff they don?t want/support. From ripe at liopen.fr Wed Feb 6 12:32:41 2019 From: ripe at liopen.fr (Denis Fondras) Date: Wed, 6 Feb 2019 12:32:41 +0100 Subject: [address-policy-wg] 2019-02 New Policy Proposal (Reducing IPv4 Allocations to a /24) In-Reply-To: <2555823.qEnKSUCqr2@hunator-ntb.local> References: <2555823.qEnKSUCqr2@hunator-ntb.local> Message-ID: <20190206113241.GP56439@carcass.ledeuns.net> On Wed, Feb 06, 2019 at 11:23:53AM +0100, Martin Hun?k wrote: > Here it starts. I would say get such a LIR what you have got (to /22 of > course). Even by means of multiple /24s. But not blocks smaller than /24, as > it would be useless. Maybe let them decide if they would like to wait for > whole /22 where there would be less then 4x /24 (in that one case). > [...] > If you keep there /22 and /24 as an option, than there would be no problem. No please, don't let LIR choose. This will only complicate management of resources. In a FIFO, a LIR asking for /22 would delay a LIR who only needs a /24. From wusel+ml at uu.org Wed Feb 6 13:10:43 2019 From: wusel+ml at uu.org (Kai 'wusel' Siering) Date: Wed, 6 Feb 2019 13:10:43 +0100 Subject: [address-policy-wg] 2019-02 New Policy Proposal (Reducing IPv4 Allocations to a /24) In-Reply-To: <20190206113241.GP56439@carcass.ledeuns.net> References: <2555823.qEnKSUCqr2@hunator-ntb.local> <20190206113241.GP56439@carcass.ledeuns.net> Message-ID: <60d17022-bc9c-7b4c-080d-50eb410e78c8@uu.org> On 06.02.2019 12:32, Denis Fondras wrote: >> If you keep there /22 and /24 as an option, than there would be no problem. > No please, don't let LIR choose. This will only complicate management of > resources. It's a simple flag, "/24 sufficienct: yes/no". > In a FIFO, a LIR asking for /22 would delay a LIR who only > needs a /24. Yes, that would be the case. Since that second LIR won't have the slightest idea when it would receive IPv4 anyway, I fail to seen an issue with that. On the contrary, it emphasis the fact that IPv4 is over. Regards, -kai -------------- next part -------------- An HTML attachment was scrubbed... URL: From frettled at gmail.com Wed Feb 6 13:21:02 2019 From: frettled at gmail.com (Jan Ingvoldstad) Date: Wed, 6 Feb 2019 13:21:02 +0100 Subject: [address-policy-wg] 2019-02 New Policy Proposal (Reducing IPv4 Allocations to a /24) In-Reply-To: <60d17022-bc9c-7b4c-080d-50eb410e78c8@uu.org> References: <2555823.qEnKSUCqr2@hunator-ntb.local> <20190206113241.GP56439@carcass.ledeuns.net> <60d17022-bc9c-7b4c-080d-50eb410e78c8@uu.org> Message-ID: On Wed, Feb 6, 2019 at 1:10 PM Kai 'wusel' Siering wrote: > On 06.02.2019 12:32, Denis Fondras wrote: > > If you keep there /22 and /24 as an option, than there would be no problem. > > No please, don't let LIR choose. This will only complicate management of > resources. > > > It's a simple flag, "/24 sufficienct: yes/no". > The flag is simple, and most people will then select "no", because they want to ensure that they get the most. Imagine if you were a Dropbox customer, and Dropbox offered two paid storage plans for $200/mo: 1) 250 GB 2) 1 TB and then you were presented with the simple flag, "250 GB sufficient: yes/no" What would you choose? My bet is that you would choose "no" and request 1 TB. -- Jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From garry at nethinks.com Wed Feb 6 13:46:37 2019 From: garry at nethinks.com (garry at nethinks.com) Date: Wed, 6 Feb 2019 13:46:37 +0100 Subject: [address-policy-wg] 2019-02 New Policy Proposal (Reducing IPv4 Allocations to a /24) In-Reply-To: References: <2555823.qEnKSUCqr2@hunator-ntb.local> <20190206113241.GP56439@carcass.ledeuns.net> <60d17022-bc9c-7b4c-080d-50eb410e78c8@uu.org> Message-ID: > > and then you were presented with the simple flag, "250 GB sufficient: > yes/no" > > What would you choose? > > My bet is that you would choose "no" and request 1 TB. > -- Slight difference: we're talking about a scarce resource here, which - depending on your choice - might or might not be available. So the choice is rather: 1) packs of 250GB, 500GB or 1TB up to a total of 1TB (packs might not be available at the same time) 2) 1TB in on pack of 1TB Though, thinking about the billing, RIPE has to (or should) define how to do the billing based on the number of resources ... currently, billing is per resource, not sure if this will be kept if due to availability issues this would remain (in essence, increasing the price for LIRs that have to take multiple /24 instead of one /22) or whether they would still receive their initial fragmented /22 amount of IPs included as "first resource" ... -garry -- Garry Glendown * Professional Services & Solutions NETHINKS GmbH | Bahnhofstra?e 16 | 36037 Fulda T +49 661 25 000 0 | F +49 661 25 000 49 | garry.glendown at nethinks.com Gesch?ftsf?hrer: Uwe Bergmann, Bastian Marmetschke Vorsitzender des Aufsichtsrats: Garry Glendown | AG Fulda HRB 2546 PGP Fingerprint: B1CF 4952 F6EB E060 8A10 B957 700E F97F B412 DD32 ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From wusel+ml at uu.org Wed Feb 6 14:20:12 2019 From: wusel+ml at uu.org (Kai 'wusel' Siering) Date: Wed, 6 Feb 2019 14:20:12 +0100 Subject: [address-policy-wg] 2019-02 New Policy Proposal (Reducing IPv4 Allocations to a /24) In-Reply-To: References: <2555823.qEnKSUCqr2@hunator-ntb.local> <20190206113241.GP56439@carcass.ledeuns.net> <60d17022-bc9c-7b4c-080d-50eb410e78c8@uu.org> Message-ID: <420bf676-10f1-8946-4e02-b6a72cc51f45@uu.org> Am 06.02.2019 um 13:46 schrieb garry at nethinks.com: >> >> and then you were presented with the simple flag, "250 GB sufficient: yes/no" >> >> What would you choose? >> >> My bet is that you would choose "no" and request 1 TB. > > Slight difference: we're talking about a scarce resource here, which - depending on your choice - might or might not be available. So the choice is rather: > > 1) packs of 250GB, 500GB or 1TB up to a total of 1TB (packs might not be available at the same time) > 2) 1TB in on pack of 1TB That's one thing. The other: what's the amount of recovered space becoming available for redistribution by the RIPE NCC within which timeframe? I've read in some document that RIRs might receive a tenth of IANA's recovered space every 6 months, thus the inital waiting time for a /22 or /24 will be up to 6 months anyway? If e. g. IANA is down to a /17, this makes a /21 for RIPE for that six month period. I'd rather hand that /21 as two /22 to two new LIRs instead of eight /24 to eight new LIRs, since a /24 is basically useless anyway. Especially if you have to wait 6 or more months for it. (Of course, /22 (in up to /24 slices) will mean a much longer waiting time, which makes IPv6 just more interessting. Or IPv4 brokers.) > Though, thinking about the billing, RIPE has to (or should) define how to do the billing based on the number of resources ... currently, billing is per resource, not sure if this will be kept if due to availability issues this would remain (in essence, increasing the price for LIRs that have to take multiple /24 instead of one /22) or whether they would still receive their initial fragmented /22 amount of IPs included as "first resource" ... IIRC, billing discussions are out of scope for the APWG. Besides, billing is not per resource currently, is it? Regards, -kai -------------- next part -------------- An HTML attachment was scrubbed... URL: From dfk at ripe.net Wed Feb 6 14:27:14 2019 From: dfk at ripe.net (Daniel Karrenberg) Date: Wed, 6 Feb 2019 14:27:14 +0100 Subject: [address-policy-wg] 2019-02 New Policy Proposal (Reducing IPv4 Allocations to a /24) In-Reply-To: References: Message-ID: <18d0b307-c08e-7741-aeee-8ad877d998e5@ripe.net> On 06/02/2019 11:40, Jim Reid wrote: > > >> On 6 Feb 2019, at 09:39, Daniel Karrenberg wrote: >> >> d) The length of the waiting list and other practicalities should be >> secondary considerations after these principles above. For instance, the >> RIPE NCC can always recover the costs incurred by the process from those >> using it. > > That could be awkward Daniel. For instance fair and equitable treatment. Or raising barriers to entry. Then there are the overheads of all that extra bean counting. Passing these costs along is all very well, but why go to the trouble of creating them in the first place? > > This would also be the start of a slippery slope. Once the NCC introduces hypothecated fees for specific services, it?ll have to do that for everything it does. Which would lead to the membership micromanaging budgets and declining to pay for the stuff they don?t want/support. Apologies for being unclear. I did not propose a specific fee. Just the normal LIR fee that covers all NCC services. It should more than pay for a process that can be highly automated. Daniel From dfk at ripe.net Wed Feb 6 14:35:22 2019 From: dfk at ripe.net (Daniel Karrenberg) Date: Wed, 6 Feb 2019 14:35:22 +0100 Subject: [address-policy-wg] 2019-02 New Policy Proposal (Reducing IPv4 Allocations to a /24) In-Reply-To: <2555823.qEnKSUCqr2@hunator-ntb.local> References: <2555823.qEnKSUCqr2@hunator-ntb.local> Message-ID: <1f66c0f8-5a2b-aabc-45f4-e582a7ccd1d1@ripe.net> On 06/02/2019 11:23, Martin Hun?k wrote: >> ... >> c) It is not tenable for the RIPE NCC to require the first LIR on the >> waiting list to wait for more address space than a minimal usfeful block >> to accumulate. > > Here it starts. I would say get such a LIR what you have got (to /22 of > course). Even by means of multiple /24s. But not blocks smaller than /24, as > it would be useless. That is exactly what I wrote. > Maybe let them decide if they would like to wait for > whole /22 where there would be less then 4x /24 (in that one case). That is where the implementation would become very complicated since it needs to be perceived as 'fair'. I see no good reason for this complication. > ... Keep /22 possibility so the > complete runout of IPv4 won't be postponed. See above. I do not see the point about 'complete runout'. We *have* run out already. This is about the very very tail end. Daniel -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From garry at nethinks.com Wed Feb 6 14:36:56 2019 From: garry at nethinks.com (garry at nethinks.com) Date: Wed, 6 Feb 2019 14:36:56 +0100 Subject: [address-policy-wg] 2019-02 New Policy Proposal (Reducing IPv4 Allocations to a /24) In-Reply-To: <420bf676-10f1-8946-4e02-b6a72cc51f45@uu.org> References: <2555823.qEnKSUCqr2@hunator-ntb.local> <20190206113241.GP56439@carcass.ledeuns.net> <60d17022-bc9c-7b4c-080d-50eb410e78c8@uu.org> <420bf676-10f1-8946-4e02-b6a72cc51f45@uu.org> Message-ID: > That's? one thing. The other: what's the amount of recovered space > becoming available for redistribution by the RIPE NCC within which > timeframe? I've read in some document that RIRs might receive a tenth > of IANA's recovered space every 6 months, thus the inital waiting time > for a /22 or /24 will be up to 6 months anyway? If e. g. IANA is down > to a /17, this makes a /21 for RIPE for that six month period. I'd > rather hand that /21 as two /22 to two new LIRs instead of eight /24 > to eight new LIRs, since a /24 is basically useless anyway. Especially > if you have to wait 6 or more months for it. (Of course, /22 (in up to > /24 slices) will mean a much longer waiting time, which makes? IPv6 > just more interessting. Or IPv4 brokers.) Why is a /24 useless? It's routable on the internet and fully usable. Yes, you can't aggregate it to form larger blocks, but considering the number of /24 already present in the global routing table (many/most of which are de-aggregated prefixes, presumably for multi-homed purposes), if anybody decides to filter them generally would cause major problems ... > >> Though, thinking about the billing, RIPE has to (or should) define >> how to do the billing based on the number of resources ... currently, >> billing is per resource, not sure if this will be kept if due to >> availability issues this would remain (in essence, increasing the >> price for LIRs that have to take multiple /24 instead of one /22) or >> whether they would still receive their initial fragmented /22 amount >> of IPs included as "first resource" ... > > IIRC, billing discussions are out of scope for the APWG. Besides, > billing is not per resource currently, is it? True. Just thought I'd throw it in there as "fairness" was mentioned earlier. From the last time I looked at the RIPE bill we were charged for every network block we have - with the same yearly recurring price per resource no matter if it's the /16, /19 or a /24 ... (formerly, this had been a one-time assignment fee, but in order to allow for easier recovery of unused IPs, RIPE changed this some time back ...) According to the 2019 billing scheme, this is still unchanged, though I reckon it does not apply to PA space: "The separate charge of EUR 50 per Independent Number resource assignment will be continued. Independent number resources are: IPv4 and IPv6 PI assignments; Anycasting assignments; IPv4 and IPv6 IXP assignments;" So fragmenting the /22 into /24s would not be of consequence to an LIR anyway, at least not financially. So strike my argument about that part. -garry From wusel+ml at uu.org Wed Feb 6 15:16:19 2019 From: wusel+ml at uu.org (Kai 'wusel' Siering) Date: Wed, 6 Feb 2019 15:16:19 +0100 Subject: [address-policy-wg] 2019-02 New Policy Proposal (Reducing IPv4 Allocations to a /24) In-Reply-To: References: <2555823.qEnKSUCqr2@hunator-ntb.local> <20190206113241.GP56439@carcass.ledeuns.net> <60d17022-bc9c-7b4c-080d-50eb410e78c8@uu.org> <420bf676-10f1-8946-4e02-b6a72cc51f45@uu.org> Message-ID: On 06.02.2019 14:36, garry at nethinks.com wrote: >> [?] I'd >> rather hand that /21 as two /22 to two new LIRs instead of eight /24 >> to eight new LIRs, since a /24 is basically useless anyway. Especially >> if you have to wait 6 or more months for it. (Of course, /22 (in up to >> /24 slices) will mean a much longer waiting time, which makes? IPv6 >> just more interessting. Or IPv4 brokers.) > Why is a /24 useless? Sorry for beeing too brief here: From my perspective, becoming an LIR implies the intend to provide service a lot of customers, and I don't see how a single /24 would suffice there. That's what I meant with "basically useless" (from a business point of view). > According to the 2019 billing scheme, this is still unchanged, though I > reckon it does not apply to PA space: > > "The separate charge of EUR 50 per Independent Number resource > assignment will be continued. Independent number resources are: IPv4 and > IPv6 PI assignments; Anycasting assignments; IPv4 and IPv6 IXP > assignments;" > > So fragmenting the /22 into /24s would not be of consequence to an LIR > anyway, at least not financially. So strike my argument about that part. Well, I'd like to debate whether a charge per /24 block held (so a /16 counts as 256 blocks) even for PA would "encourage" to return unnused space, but I doubt this is the place nor would this be approved by the GM anyway ;) -kai From frettled at gmail.com Wed Feb 6 15:24:44 2019 From: frettled at gmail.com (Jan Ingvoldstad) Date: Wed, 6 Feb 2019 15:24:44 +0100 Subject: [address-policy-wg] 2019-02 New Policy Proposal (Reducing IPv4 Allocations to a /24) In-Reply-To: References: <2555823.qEnKSUCqr2@hunator-ntb.local> <20190206113241.GP56439@carcass.ledeuns.net> <60d17022-bc9c-7b4c-080d-50eb410e78c8@uu.org> <420bf676-10f1-8946-4e02-b6a72cc51f45@uu.org> Message-ID: On Wed, Feb 6, 2019 at 3:16 PM Kai 'wusel' Siering wrote: > On 06.02.2019 14:36, garry at nethinks.com wrote: > >> [?] I'd > >> rather hand that /21 as two /22 to two new LIRs instead of eight /24 > >> to eight new LIRs, since a /24 is basically useless anyway. Especially > >> if you have to wait 6 or more months for it. (Of course, /22 (in up to > >> /24 slices) will mean a much longer waiting time, which makes IPv6 > >> just more interessting. Or IPv4 brokers.) > > Why is a /24 useless? > > Sorry for beeing too brief here: From my perspective, becoming an LIR > implies the intend to provide service a lot of customers, and I don't > see how a single /24 would suffice there. That's what I meant with > "basically useless" (from a business point of view). > In that case, IPv4 is "basically useless" from a business point of view. But that statement is provably false. Additionally, a lot of business is about providing services that are *not* connectivity-based, to a lot of customers. Additionally, a lot of connectivity services can be provided via NAT. And so on. This line of argument is not fruitful, sorry. Please abandon it. -- Jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From tasic at hostmaster.ua Wed Feb 6 15:50:39 2019 From: tasic at hostmaster.ua (Taras Heichenko) Date: Wed, 6 Feb 2019 16:50:39 +0200 Subject: [address-policy-wg] 2019-02 New Policy Proposal (Reducing IPv4 Allocations to a /24) In-Reply-To: References: <2555823.qEnKSUCqr2@hunator-ntb.local> <20190206113241.GP56439@carcass.ledeuns.net> <60d17022-bc9c-7b4c-080d-50eb410e78c8@uu.org> <420bf676-10f1-8946-4e02-b6a72cc51f45@uu.org> Message-ID: <3793E423-F66F-4403-A713-257C4BD1C552@hostmaster.ua> > On Feb 6, 2019, at 16:24, Jan Ingvoldstad wrote: > > In that case, IPv4 is "basically useless" from a business point of view. > > But that statement is provably false. > > Additionally, a lot of business is about providing services that are *not* connectivity-based, to a lot of customers. > > Additionally, a lot of connectivity services can be provided via NAT. > > And so on. If I am right we talk about resources that can be obtained by new LIR. If a LIR already has some IPv4 block it cannot claim to get some other block from RIPE NCC according to the policy. And what does the LIR status give to the LIR? It gives possibility to get IP addresses. So a LIR is been registering to obtain IPs. Anything else? So a new LIR must pay $1400 annually to have ghostly possibility to obtain IPv4 addresses. May be. Later. After years (multiply by $1400). It has not these addresses and his/her busyness will suffer from lack of IPv4 addresses. As for me in this case I would not wait IPv4 addresses from RIPE NCC. Either I make busyness only on IPv6 or I buy IPv4 addresses on the market (after this I cannot claim to get addresses from RIPE NCC, right?). What are we talking about? Show me please use case for participant of the waitlist. Who is he/she? > > This line of argument is not fruitful, sorry. Please abandon it. > -- > Jan -- Best regards Taras Heichenko tasic at hostmaster.ua From hunekm at gmail.com Wed Feb 6 17:52:13 2019 From: hunekm at gmail.com (Martin =?utf-8?B?SHVuxJtr?=) Date: Wed, 06 Feb 2019 17:52:13 +0100 Subject: [address-policy-wg] 2019-02 New Policy Proposal (Reducing IPv4 Allocations to a /24) In-Reply-To: <1f66c0f8-5a2b-aabc-45f4-e582a7ccd1d1@ripe.net> References: <2555823.qEnKSUCqr2@hunator-ntb.local> <1f66c0f8-5a2b-aabc-45f4-e582a7ccd1d1@ripe.net> Message-ID: <11644052.abS1xHs4WV@rumburak.ite.tul.cz> Reply inline. Dne st?eda 6. ?nora 2019 14:35:22 CET, Daniel Karrenberg napsal(a): > > On 06/02/2019 11:23, Martin Hun?k wrote: > > Maybe let them decide if they would like to wait for > > whole /22 where there would be less then 4x /24 (in that one case). > > That is where the implementation would become very complicated since it > needs to be perceived as 'fair'. I see no good reason for this complication. Not necessary. Simple question would do: "We have got 3x /24 right now or /22 in 3 months. Do you want to get them right away or do you want to wait for whole /22?". RIPE NCC knows where next prefixes would leave 6 months quarantine, so at least a first few LIRs on the list would know where to expect IPv4 prefixes. It could be seen as a complication of process, but it is important to mention that we are talking about one LIR per each batch of returned IP space. And even that could be automated trough LIR portal. > > > ... Keep /22 possibility so the > > complete runout of IPv4 won't be postponed. > > See above. I do not see the point about 'complete runout'. We *have* run > out already. This is about the very very tail end. What I'm afraid of is pressure for further deaggregation of those last /24s. Even now in the mailing list there was opinion that just one /24 is useless because you can't assign from it to another entity. Not talking about fact that if you have same amount of LIR on waiting list when everybody wants 4x more, the waiting list is 4x longer time-wise. Longer list = less probability of getting IPv4 ~ no more IPv4 -> had to go for IPv6. If you have /22 you can do that, if you could have /22 but you have chosen /24 (now instead of waiting for /22) - you could have done that and if there won't be enough IPv4 for you that would be just a fact and there would be nothing to do about it. So there won't be such pressure for further deaggregation. At least if IANA won't distribute to RIRs smaller prefixes anyway. And just why is such deaggregation problem for me? Because we would be spending even more RAM and computation effort on "walking dead" IPv4. And if we start to allow such deaggregation we would end up on single /32 in our routing table. At least for now we all know that if we try to announce /25+ we would have reachability issues. Let's keep it that way. Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: This is a digitally signed message part. URL: From cfriacas at fccn.pt Thu Feb 7 08:49:56 2019 From: cfriacas at fccn.pt (=?ISO-8859-15?Q?Carlos_Fria=E7as?=) Date: Thu, 7 Feb 2019 07:49:56 +0000 (WET) Subject: [address-policy-wg] 2019-02 New Policy Proposal (Reducing IPv4 Allocations to a /24) In-Reply-To: <420bf676-10f1-8946-4e02-b6a72cc51f45@uu.org> References: <2555823.qEnKSUCqr2@hunator-ntb.local> <20190206113241.GP56439@carcass.ledeuns.net> <60d17022-bc9c-7b4c-080d-50eb410e78c8@uu.org> <420bf676-10f1-8946-4e02-b6a72cc51f45@uu.org> Message-ID: On Wed, 6 Feb 2019, Kai 'wusel' Siering wrote: (...) > I'd rather hand that /21 as two /22 to two new LIRs instead of eight /24 > to eight new LIRs, since a /24 is basically useless anyway. I really don't agree with the former. The spirit of 2019-02 is precisely that a /24 is the minimum usable allocation, mostly due to global routability. An ORG/LIR might get a second /24 if needed (through a new LIR account), but it needs to go back into the queue... (if there is any at some point). (...) > IIRC, billing discussions are out of scope for the APWG. Besides, billing is not per resource currently, is it? Here we are 200% in agreement :-) Cheers, Carlos > Regards, > -kai > > > From cfriacas at fccn.pt Thu Feb 7 08:59:09 2019 From: cfriacas at fccn.pt (=?ISO-8859-15?Q?Carlos_Fria=E7as?=) Date: Thu, 7 Feb 2019 07:59:09 +0000 (WET) Subject: [address-policy-wg] 2019-02 New Policy Proposal (Reducing IPv4 Allocations to a /24) In-Reply-To: <1f66c0f8-5a2b-aabc-45f4-e582a7ccd1d1@ripe.net> References: <2555823.qEnKSUCqr2@hunator-ntb.local> <1f66c0f8-5a2b-aabc-45f4-e582a7ccd1d1@ripe.net> Message-ID: On Wed, 6 Feb 2019, Daniel Karrenberg wrote: (...) >> ... Keep /22 possibility so the >> complete runout of IPv4 won't be postponed. > > See above. I do not see the point about 'complete runout'. We *have* run > out already. This is about the very very tail end. Allow me to disagree. People are still getting IPv4 addresses from the NCC. "Declaring runout" is not exactly the same as stopping handing out IPv4 addresses. Even when the pools reach ZERO, if 1000 LIRs stop paying fees (and that's only one example/route), the "runout" will be temporarily reverted, and handing out IPv4 addresses will be again, in theory, possible. The "reversion" won't happen if there is a policy in place stating RIPE NCC will not allocate any more IPv4 addresses -- who wants to propose that? I don't. Disclaimer: I have been advocating and deploying IPv6 since ~2001. I just think reducing by decree/policy the ability of people to use/deploy IPv4 is not the correct way to go. Cheers, Carlos > Daniel > > From cfriacas at fccn.pt Thu Feb 7 09:04:19 2019 From: cfriacas at fccn.pt (=?ISO-8859-15?Q?Carlos_Fria=E7as?=) Date: Thu, 7 Feb 2019 08:04:19 +0000 (WET) Subject: [address-policy-wg] 2019-02 New Policy Proposal (Reducing IPv4 Allocations to a /24) In-Reply-To: References: <2555823.qEnKSUCqr2@hunator-ntb.local> <20190206113241.GP56439@carcass.ledeuns.net> <60d17022-bc9c-7b4c-080d-50eb410e78c8@uu.org> <420bf676-10f1-8946-4e02-b6a72cc51f45@uu.org> Message-ID: On Wed, 6 Feb 2019, Kai 'wusel' Siering wrote: > On 06.02.2019 14:36, garry at nethinks.com wrote: >>> [?] I'd >>> rather hand that /21 as two /22 to two new LIRs instead of eight /24 >>> to eight new LIRs, since a /24 is basically useless anyway. Especially >>> if you have to wait 6 or more months for it. (Of course, /22 (in up to >>> /24 slices) will mean a much longer waiting time, which makes? IPv6 >>> just more interessting. Or IPv4 brokers.) >> Why is a /24 useless? > > Sorry for beeing too brief here: From my perspective, becoming an LIR > implies the intend to provide service a lot of customers, and I don't > see how a single /24 would suffice there. That's what I meant with > "basically useless" (from a business point of view). > An organisation can still use the /22 (or a /24) to become independent in terms of addressing from transit suppliers... >> According to the 2019 billing scheme, this is still unchanged, though I >> reckon it does not apply to PA space: >> >> "The separate charge of EUR 50 per Independent Number resource >> assignment will be continued. Independent number resources are: IPv4 and >> IPv6 PI assignments; Anycasting assignments; IPv4 and IPv6 IXP >> assignments;" >> >> So fragmenting the /22 into /24s would not be of consequence to an LIR >> anyway, at least not financially. So strike my argument about that part. > > Well, I'd like to debate whether a charge per /24 block held (so a /16 > counts as 256 blocks) even for PA would "encourage" to return unnused > space, but I doubt this is the place nor would this be approved by the > GM anyway ;) Yup :-) Cheers, Carlos > -kai > > > From cfriacas at fccn.pt Thu Feb 7 09:14:39 2019 From: cfriacas at fccn.pt (=?ISO-8859-15?Q?Carlos_Fria=E7as?=) Date: Thu, 7 Feb 2019 08:14:39 +0000 (WET) Subject: [address-policy-wg] 2019-02 New Policy Proposal (Reducing IPv4 Allocations to a /24) In-Reply-To: <3793E423-F66F-4403-A713-257C4BD1C552@hostmaster.ua> References: <2555823.qEnKSUCqr2@hunator-ntb.local> <20190206113241.GP56439@carcass.ledeuns.net> <60d17022-bc9c-7b4c-080d-50eb410e78c8@uu.org> <420bf676-10f1-8946-4e02-b6a72cc51f45@uu.org> <3793E423-F66F-4403-A713-257C4BD1C552@hostmaster.ua> Message-ID: Hi, Please see inline. On Wed, 6 Feb 2019, Taras Heichenko wrote: > > >> On Feb 6, 2019, at 16:24, Jan Ingvoldstad wrote: >> >> In that case, IPv4 is "basically useless" from a business point of view. >> >> But that statement is provably false. >> >> Additionally, a lot of business is about providing services that are *not* connectivity-based, to a lot of customers. >> >> Additionally, a lot of connectivity services can be provided via NAT. >> >> And so on. > > If I am right we talk about resources that can be obtained by new LIR. If a LIR already has some > IPv4 block it cannot claim to get some other block from RIPE NCC according to the policy. And > what does the LIR status give to the LIR? It gives possibility to get IP addresses. So a LIR is been > registering to obtain IPs. Anything else? And keep it. And access NCC services like certification (RPKI), training, ... > So a new LIR must pay $1400 annually to have ghostly > possibility to obtain IPv4 addresses. May be. Later. After years (multiply by $1400). Don't forget about "keeping it". If you only pay on the 1st year, the resources go back into the pool (de-registered) if the 2nd year is not payed... it's called "maintenance". :-) > It has not these > addresses and his/her busyness will suffer from lack of IPv4 addresses. As for me in this case I > would not wait IPv4 addresses from RIPE NCC. Either I make busyness only on IPv6 or I buy IPv4 > addresses on the market (after this I cannot claim to get addresses from RIPE NCC, right?). My interpretation is that you could. Currently, a /22 per LIR account... > What are we talking about? Show me please use case for participant of > the waitlist. Who is he/she? Potentially ORGs that wish to be independent (IPv4 addressing wise) from their transit providers, also allowing them to peer at IXPs, ... The easy part is IPv6, which doesn't involve any waiting list -- it's just a matter of becoming a LIR or getting service from one. :-)) Cheers, Carlos > > -- > Best regards > > Taras Heichenko > tasic at hostmaster.ua From cfriacas at fccn.pt Thu Feb 7 09:40:25 2019 From: cfriacas at fccn.pt (=?ISO-8859-15?Q?Carlos_Fria=E7as?=) Date: Thu, 7 Feb 2019 08:40:25 +0000 (WET) Subject: [address-policy-wg] 2019-02 New Policy Proposal (Reducing IPv4 Allocations to a /24) In-Reply-To: <11644052.abS1xHs4WV@rumburak.ite.tul.cz> References: <2555823.qEnKSUCqr2@hunator-ntb.local> <1f66c0f8-5a2b-aabc-45f4-e582a7ccd1d1@ripe.net> <11644052.abS1xHs4WV@rumburak.ite.tul.cz> Message-ID: Hi, (please see inline) On Wed, 6 Feb 2019, Martin Hun?k wrote: > What I'm afraid of is pressure for further deaggregation of those last > /24s. Even now in the mailing list there was opinion that just one /24 > is useless because you can't assign from it to another entity. Not > talking about fact that if you have same amount of LIR on waiting list > when everybody wants 4x more, the waiting list is 4x longer time-wise. > Longer list = less probability of getting IPv4 ~ no more IPv4 -> had to > go for IPv6. Or go to "the IPv4 market". > If you have /22 you can do that, if you could have /22 but you have > chosen /24 (now instead of waiting for /22) - you could have done that > and if there won't be enough IPv4 for you that would be just a fact and > there would be nothing to do about it. So there won't be such pressure > for further deaggregation. At least if IANA won't distribute to RIRs > smaller prefixes anyway. > > And just why is such deaggregation problem for me? Because we would be > spending even more RAM and computation effort on "walking dead" IPv4. > And if we start to allow such deaggregation we would end up on single > /32 in our routing table. At least for now we all know that if we try to > announce /25+ we would have reachability issues. Let's keep it that way. I agree global routability must remain at /24. IPv4 is NOT "walking dead". It's the Internet's dominant protocol version, whether we like it or not! How many orgs have gone public about plans to completely drop IPv4? IPv4 has a serious limitation about "future growth", which IPv6 doesn't have. But people are making (a lot of?) money pushing IPv4 numbers from hand to hand, so it is hard for me (at this point, from a research & education network background!) to see how IPv4 will stop being the dominant version... Cheers, Carlos > Martin From hunekm at gmail.com Thu Feb 7 10:49:13 2019 From: hunekm at gmail.com (Martin =?utf-8?B?SHVuxJtr?=) Date: Thu, 07 Feb 2019 10:49:13 +0100 Subject: [address-policy-wg] 2019-02 New Policy Proposal (Reducing IPv4 Allocations to a /24) In-Reply-To: References: <11644052.abS1xHs4WV@rumburak.ite.tul.cz> Message-ID: <5616462.SLD2YgNs04@asclepius> Hi, (reply inline) Dne ?tvrtek 7. ?nora 2019 9:40:25 CET jste napsal(a): > Hi, > (please see inline) > > On Wed, 6 Feb 2019, Martin Hun?k wrote: > > What I'm afraid of is pressure for further deaggregation of those last > > /24s. Even now in the mailing list there was opinion that just one /24 > > is useless because you can't assign from it to another entity. Not > > talking about fact that if you have same amount of LIR on waiting list > > when everybody wants 4x more, the waiting list is 4x longer time-wise. > > Longer list = less probability of getting IPv4 ~ no more IPv4 -> had to > > go for IPv6. > > Or go to "the IPv4 market". Also a possibility, but it would cost additional money. > > IPv4 is NOT "walking dead". It's the Internet's dominant protocol version, > whether we like it or not! > > How many orgs have gone public about plans to completely drop IPv4? > > IPv4 has a serious limitation about "future growth", which IPv6 doesn't > have. But people are making (a lot of?) money pushing IPv4 numbers > from hand to hand, so it is hard for me (at this point, from a research & > education network background!) to see how IPv4 will stop being the > dominant version... Yes it is still dominant, no dispute here. But as well we (theoretically) buried it long time ago. That's why the "walking dead" thing. Point is that with up to /32 in routing tables we would be investing RAM on IPv4 instead of for IPv6 deployment (if not done already). And yes, there is quite a lot of money in IPv4. In hypothetical IPv6-only world, IP brokers would starve to death. :-) Regards, Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: This is a digitally signed message part. URL: From phessler at theapt.org Thu Feb 7 11:05:49 2019 From: phessler at theapt.org (Peter Hessler) Date: Thu, 7 Feb 2019 11:05:49 +0100 Subject: [address-policy-wg] 2019-02 New Policy Proposal (Reducing IPv4 Allocations to a /24) In-Reply-To: References: Message-ID: <20190207100548.GU34686@gir.theapt.org> I support this proposal. 1) the intent of the last /8 policy is for new participants to go from 0 to not-0 IPv4 addresses. While not-0 IPv4 addresses may not be enough for a limited number of business cases, it *is* enough to bootstrap a company (e.g. website, dns, email, nat64, etc). 2) When RIPE NCC is unable to allocate a contiguous /22, we are scraping the bottom of the barrel. A single /24 allocation helps the not-0 participants. 3) A /24 is the smallest allocation that is actually usable on the internet. 4) While there is a belief The Internet(tm) should just up and migrate to IPv6, that is unrealistic. E.g. Twitter, Amazon, Reddit, Github, and *many* home/business ISPs around the world do not even IPv6. Whinging about it in policy groups doesn't change that *fact*. Yes, I prefer that people use IPv6. But reality says IPv4 is still important for new participants. On 2019 Feb 04 (Mon) at 13:04:26 +0100 (+0100), Marco Schmidt wrote: :Dear colleagues, : :A new RIPE Policy proposal, 2019-02, "Reducing IPv4 Allocations to a /24" :is now available for discussion. : :This proposal aims to reduce the IPv4 allocation size to a /24 once the :RIPE NCC is unable to allocate contiguous /22 ranges. : :You can find the full proposal at: :https://www.ripe.net/participate/policies/proposals/2019-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 proposer. : :At the end of the Discussion Phase, the proposer, with the agreement of :the WG Chairs, will decide how to proceed with the proposal. : :We encourage you to review this proposal and send your comments to : before 5 March 2019. : :Regards, : :Marco Schmidt :Policy Officer : : -- Bacchus, n.: A convenient deity invented by the ancients as an excuse for getting drunk. -- Ambrose Bierce, "The Devil's Dictionary" From jim at rfc1035.com Thu Feb 7 11:14:18 2019 From: jim at rfc1035.com (Jim Reid) Date: Thu, 7 Feb 2019 10:14:18 +0000 Subject: [address-policy-wg] can deadbeat LIRs reverse IPv4 exhaustion? In-Reply-To: References: <2555823.qEnKSUCqr2@hunator-ntb.local> <1f66c0f8-5a2b-aabc-45f4-e582a7ccd1d1@ripe.net> Message-ID: <00F69AC1-5D84-424E-92E3-1312DB55629F@rfc1035.com> > On 7 Feb 2019, at 07:59, Carlos Fria?as via address-policy-wg wrote: > > Even when the pools reach ZERO, if 1000 LIRs stop paying fees (and that's only one example/route), the "runout" will be temporarily reverted, and handing out IPv4 addresses will be again, in theory, possible. How is that possible? Once the pools reach zero, there are no more addresses to hand out. An RIR can't conjure up IPv4 address space out of thin air. If it was able to do that, we could just continue forever with business as usual and allocate v4 until the heat death of the universe. Besides, there?s no mechanism or policy for the NCC to recover addresses from LIRs that don?t pay their bills. If such mechanisms or policies existed, they?d be unworkable. There?s no way of knowing for sure that those addresses weren?t being used. So if they were reclaimed, the addresses couldn?t be allocated to someone else. From tasic at hostmaster.ua Thu Feb 7 12:20:13 2019 From: tasic at hostmaster.ua (Taras Heichenko) Date: Thu, 7 Feb 2019 13:20:13 +0200 Subject: [address-policy-wg] 2019-02 New Policy Proposal (Reducing IPv4 Allocations to a /24) In-Reply-To: References: <2555823.qEnKSUCqr2@hunator-ntb.local> <20190206113241.GP56439@carcass.ledeuns.net> <60d17022-bc9c-7b4c-080d-50eb410e78c8@uu.org> <420bf676-10f1-8946-4e02-b6a72cc51f45@uu.org> <3793E423-F66F-4403-A713-257C4BD1C552@hostmaster.ua> Message-ID: > On Feb 7, 2019, at 10:14, Carlos Fria?as wrote: > > > Hi, Hi, [skip some text] >> If I am right we talk about resources that can be obtained by new LIR. If a LIR already has some >> IPv4 block it cannot claim to get some other block from RIPE NCC according to the policy. And >> what does the LIR status give to the LIR? It gives possibility to get IP addresses. So a LIR is been >> registering to obtain IPs. Anything else? > > And keep it. And access NCC services like certification (RPKI), training, ... All that you added is derived from "obtain IPs". Of course you are right but until you get IPs you do not need AS, RPKI and so on. Training may be useful without IPs but you can find a way to go to training without LIR status. > > >> So a new LIR must pay $1400 annually to have ghostly >> possibility to obtain IPv4 addresses. May be. Later. After years (multiply by $1400). > > Don't forget about "keeping it". If you only pay on the 1st year, the resources go back into the pool (de-registered) if the 2nd year is not payed... it's called "maintenance". :-) You must obtain IPs at first. All your answer is built on assumption that organization already has some IPs. Of course in this case it will pay annual fee for all service. But we talk about new LIR. I came to RIPE NCC to get IPs. RIPE NCC is telling me: We put you in waitlist and may be later you will get /24. But to get to the waitlist I must pay now 1400 (of course euros not $ as I mistype in previous letter). I pay 1400 euros annually for the right to be in the waitlist. > > >> It has not these >> addresses and his/her busyness will suffer from lack of IPv4 addresses. As for me in this case I >> would not wait IPv4 addresses from RIPE NCC. Either I make busyness only on IPv6 or I buy IPv4 >> addresses on the market (after this I cannot claim to get addresses from RIPE NCC, right?). > > My interpretation is that you could. Currently, a /22 per LIR account... I hope someone who take decision will answer. Would new LIR have right on the block from RIPE NCC if it had bought some IPv4 from the market? > > >> What are we talking about? Show me please use case for participant of the waitlist. Who is he/she? > > Potentially ORGs that wish to be independent (IPv4 addressing wise) from their transit providers, also allowing them to peer at IXPs, ... > > The easy part is IPv6, which doesn't involve any waiting list -- it's just a matter of becoming a LIR or getting service from one. :-)) > > > Cheers, > Carlos > >> >> -- >> Best regards >> >> Taras Heichenko >> tasic at hostmaster.ua -- Best regards Taras Heichenko tasic at hostmaster.ua From cfriacas at fccn.pt Thu Feb 7 12:44:13 2019 From: cfriacas at fccn.pt (=?ISO-8859-15?Q?Carlos_Fria=E7as?=) Date: Thu, 7 Feb 2019 11:44:13 +0000 (WET) Subject: [address-policy-wg] 2019-02 New Policy Proposal (Reducing IPv4 Allocations to a /24) In-Reply-To: <5616462.SLD2YgNs04@asclepius> References: <11644052.abS1xHs4WV@rumburak.ite.tul.cz> <5616462.SLD2YgNs04@asclepius> Message-ID: On Thu, 7 Feb 2019, Martin Hun?k wrote: >> Or go to "the IPv4 market". > > Also a possibility, but it would cost additional money. Sure, but that's life. And it doesn't mean IPv4 is being abandoned. :/ >> IPv4 is NOT "walking dead". It's the Internet's dominant protocol version, >> whether we like it or not! >> >> How many orgs have gone public about plans to completely drop IPv4? >> >> IPv4 has a serious limitation about "future growth", which IPv6 doesn't >> have. But people are making (a lot of?) money pushing IPv4 numbers >> from hand to hand, so it is hard for me (at this point, from a research & >> education network background!) to see how IPv4 will stop being the >> dominant version... > > Yes it is still dominant, no dispute here. But as well we (theoretically) > buried it long time ago. That's why the "walking dead" thing. Point is that > with up to /32 in routing tables we would be investing RAM on IPv4 instead of > for IPv6 deployment (if not done already). Maybe. But that will be each ORG's choice, -if- prefixes longer than /24 start to get accepted. > And yes, there is quite a lot of money in IPv4. In hypothetical IPv6-only > world, IP brokers would starve to death. :-) Businesses are born, they get mature and eventually they stop making sense. It's a normal lifecycle... Regards, Carlos > Regards, > Martin From cfriacas at fccn.pt Thu Feb 7 12:49:09 2019 From: cfriacas at fccn.pt (=?ISO-8859-15?Q?Carlos_Fria=E7as?=) Date: Thu, 7 Feb 2019 11:49:09 +0000 (WET) Subject: [address-policy-wg] 2019-02 New Policy Proposal (Reducing IPv4 Allocations to a /24) In-Reply-To: <20190207100548.GU34686@gir.theapt.org> References: <20190207100548.GU34686@gir.theapt.org> Message-ID: On Thu, 7 Feb 2019, Peter Hessler wrote: (...) > 4) While there is a belief The Internet(tm) should just up and migrate > to IPv6, that is unrealistic. E.g. Twitter, Amazon, Reddit, Github, and > *many* home/business ISPs around the world do not even IPv6. Whinging > about it in policy groups doesn't change that *fact*. (...) What can we, as a community, do which has not been already tried...? Will it be just a matter of sitting and waiting that people deploying/managing networks & services for those companies are replaced by other people with a different view about IPv6 (or their companies' needs)? >From the *extremely* small list above, Github was recently bought from Microsoft right...? Maybe by talking with the right folks... Regards, Carlos From mschmidt at ripe.net Thu Feb 7 13:12:36 2019 From: mschmidt at ripe.net (Marco Schmidt) Date: Thu, 7 Feb 2019 13:12:36 +0100 Subject: [address-policy-wg] can deadbeat LIRs reverse IPv4 exhaustion? In-Reply-To: <00F69AC1-5D84-424E-92E3-1312DB55629F@rfc1035.com> References: <2555823.qEnKSUCqr2@hunator-ntb.local> <1f66c0f8-5a2b-aabc-45f4-e582a7ccd1d1@ripe.net> <00F69AC1-5D84-424E-92E3-1312DB55629F@rfc1035.com> Message-ID: <35200659-0c33-0fdc-2558-258c333f29fb@ripe.net> Dear Jim, all, I would just like to provide some clarification regarding your point below. On 07/02/2019 11:14, Jim Reid wrote: > >> On 7 Feb 2019, at 07:59, Carlos Fria?as via address-policy-wg wrote: >> >> Even when the pools reach ZERO, if 1000 LIRs stop paying fees (and that's only one example/route), the "runout" will be temporarily reverted, and handing out IPv4 addresses will be again, in theory, possible. > How is that possible? Once the pools reach zero, there are no more addresses to hand out. > > An RIR can't conjure up IPv4 address space out of thin air. If it was able to do that, we could just continue forever with business as usual and allocate v4 until the heat death of the universe. > > Besides, there?s no mechanism or policy for the NCC to recover addresses from LIRs that don?t pay their bills. If such mechanisms or policies existed, they?d be unworkable. There?s no way of knowing for sure that those addresses weren?t being used. So if they were reclaimed, the addresses couldn?t be allocated to someone else. > > > Section 9.0 of the IPv4 policy states that an LIR may be closed if it does not pay money it owes to the RIPE NCC. The policy also states that the RIPE NCC takes on responsibility for the address space of LIRs that are closed: https://www.ripe.net/publications/docs/ripe-708#9 Based on the policy, we have existing procedures to de-register IPv4 address space and re-issue the addresses. Our procedure in these cases includes announcement checks and a quarantine period to minimise routablity issues for future resource holders. In fact, many of the allocations we are currently making have gone through such a recycling process. We expect that we will continue to receive IPv4 addresses due to LIR closures and other reasons for some time after the current IPv4 pool has been exhausted. Kind regards, Marco Schmidt Policy Officer RIPE NCC From cfriacas at fccn.pt Thu Feb 7 13:12:47 2019 From: cfriacas at fccn.pt (=?ISO-8859-15?Q?Carlos_Fria=E7as?=) Date: Thu, 7 Feb 2019 12:12:47 +0000 (WET) Subject: [address-policy-wg] can deadbeat LIRs reverse IPv4 exhaustion? In-Reply-To: <00F69AC1-5D84-424E-92E3-1312DB55629F@rfc1035.com> References: <2555823.qEnKSUCqr2@hunator-ntb.local> <1f66c0f8-5a2b-aabc-45f4-e582a7ccd1d1@ripe.net> <00F69AC1-5D84-424E-92E3-1312DB55629F@rfc1035.com> Message-ID: On Thu, 7 Feb 2019, Jim Reid wrote: > > >> On 7 Feb 2019, at 07:59, Carlos Fria?as via address-policy-wg wrote: >> >> Even when the pools reach ZERO, if 1000 LIRs stop paying fees (and that's only one example/route), the "runout" will be temporarily reverted, and handing out IPv4 addresses will be again, in theory, possible. > > How is that possible? Once the pools reach zero, there are no more addresses to hand out. At that point in the timeline, YES. zero means zero. > An RIR can't conjure up IPv4 address space out of thin air. If it was > able to do that, we could just continue forever with business as usual > and allocate v4 until the heat death of the universe. Yes, that's correct. But a set of foreseeable events might pour down -some- IPv4 space, growing the stock from zero. The NCC registration services tell us they are getting addresses back *every* year (yes, that was a surprise for me too). Even if that doesn't happen during a full year, it doesn't mean it won't happen in subsequent years. If i didn't get it wrong, that depends on a variety of factors. Of course the "yearly recovered numbering assets" are not enough to cope with all the demand -- that's when the waiting list might be useful... > Besides, there?s no mechanism or policy for the NCC to recover > addresses from LIRs that don?t pay their bills. I think you are wrong. Apart from the financial side, if a LIR doesn't comply with policies (falsified data, and so on...) there is a service termination process and resources go back into the pool after some time -- please someone at the NCC, tell me if i got it wrong. > If such mechanisms or policies existed, they?d be unworkable. There?s no > way of knowing for sure that those addresses weren?t being used. Bad luck. Rules breaking means revokation... The higher risk (as i see it) goes to new recipients of the space, after some quarentine. > So if they were reclaimed, the addresses couldn?t be allocated to > someone else. I think the NCC and current policy might disagree -- please tell me if i'm wrong. Best Regards, Carlos From info at servereasy.it Thu Feb 7 13:17:05 2019 From: info at servereasy.it (Servereasy) Date: Thu, 7 Feb 2019 13:17:05 +0100 Subject: [address-policy-wg] 2019-02 New Policy Proposal (Reducing IPv4 Allocations to a /24) In-Reply-To: References: Message-ID: <2b7f70d2-835c-913c-5dbc-5636104594c5@servereasy.it> Hi, /Rationale:// //[...]// //By extending the availability of IPv4 addresses to newcomers, the RIPE community demonstrates goodwill towards competition laws and regulations. It is recognised that even with the ongoing implementation of IPv6 the global internet is going to need some IPv4 resources for another decade or two./ /[...]/ Maybe I'm missing something here. Is it fair that a LIR with multiple /12 pays the same fee of a LIR with a single /22? Is this how RIPE NCC/"//demonstrates goodwill towards competition laws and regulations." /? I oppose this proposal, unless at least RIPE NCC will charge members based on how much IPv4 space they have. I find that this will be the only way to really boost IPv6 adoption. Regards -- Saverio Giuntini Servereasy Srl Il 04/02/2019 13:04, Marco Schmidt ha scritto: > Dear colleagues, > > A new RIPE Policy proposal, 2019-02, "Reducing IPv4 Allocations to a /24" > is now available for discussion. > > This proposal aims to reduce the IPv4 allocation size to a /24 once the > RIPE NCC is unable to allocate contiguous /22 ranges. > > You can find the full proposal at: > https://www.ripe.net/participate/policies/proposals/2019-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 proposer. > > At the end of the Discussion Phase, the proposer, with the agreement of > the WG Chairs, will decide how to proceed with the proposal. > > We encourage you to review this proposal and send your comments to > before 5 March 2019. > > Regards, > > Marco Schmidt > Policy Officer > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cfriacas at fccn.pt Thu Feb 7 13:22:05 2019 From: cfriacas at fccn.pt (=?ISO-8859-15?Q?Carlos_Fria=E7as?=) Date: Thu, 7 Feb 2019 12:22:05 +0000 (WET) Subject: [address-policy-wg] 2019-02 New Policy Proposal (Reducing IPv4 Allocations to a /24) In-Reply-To: References: <2555823.qEnKSUCqr2@hunator-ntb.local> <20190206113241.GP56439@carcass.ledeuns.net> <60d17022-bc9c-7b4c-080d-50eb410e78c8@uu.org> <420bf676-10f1-8946-4e02-b6a72cc51f45@uu.org> <3793E423-F66F-4403-A713-257C4BD1C552@hostmaster.ua> Message-ID: On Thu, 7 Feb 2019, Taras Heichenko wrote: (...) > All that you added is derived from "obtain IPs". Of course you are right but until you get IPs you > do not need AS, RPKI and so on. Training may be useful without IPs but you can find a way > to go to training without LIR status. Yes, but addresses can also be obtained from "the market", and maintenance will be required anyway... Oh, and you can get IPv6 addressing also! (...) >> Don't forget about "keeping it". If you only pay on the 1st year, the resources go back into the pool (de-registered) if the 2nd year is not payed... it's called "maintenance". :-) > > You must obtain IPs at first. All your answer is built on assumption that organization already > has some IPs. Of course in this case it will pay annual fee for all service. But we talk about > new LIR. I came to RIPE NCC to get IPs. RIPE NCC is telling me: We put you in waitlist and > may be later you will get /24. But to get to the waitlist I must pay now 1400 (of course euros > not $ as I mistype in previous letter). I pay 1400 euros annually for the right to be in the waitlist. Sounds a bit expensive, yes, i agree. Stock market futures come to mind. But if you can't get space immediately from the NCC, some brokers will certainly help you (for their right price...), and you can associate the space you buy with your new fresh LIR -- and still be on the waitlist (if i'm not wrong)! >>> It has not these >>> addresses and his/her busyness will suffer from lack of IPv4 addresses. As for me in this case I >>> would not wait IPv4 addresses from RIPE NCC. Either I make busyness only on IPv6 or I buy IPv4 >>> addresses on the market (after this I cannot claim to get addresses from RIPE NCC, right?). >> >> My interpretation is that you could. Currently, a /22 per LIR account... > > I hope someone who take decision will answer. Would new LIR have right on the block from RIPE NCC > if it had bought some IPv4 from the market? Even if the answer now is "No.", i believe that could eventually be changed by a new policy proposal into "Yes.". If this is the case i would support such proposal. Regards, Carlos From jim at rfc1035.com Thu Feb 7 13:47:25 2019 From: jim at rfc1035.com (Jim Reid) Date: Thu, 7 Feb 2019 12:47:25 +0000 Subject: [address-policy-wg] can deadbeat LIRs reverse IPv4 exhaustion? In-Reply-To: <35200659-0c33-0fdc-2558-258c333f29fb@ripe.net> References: <2555823.qEnKSUCqr2@hunator-ntb.local> <1f66c0f8-5a2b-aabc-45f4-e582a7ccd1d1@ripe.net> <00F69AC1-5D84-424E-92E3-1312DB55629F@rfc1035.com> <35200659-0c33-0fdc-2558-258c333f29fb@ripe.net> Message-ID: <6464F9FA-6A92-4949-9D02-DAB7302A24B4@rfc1035.com> > On 7 Feb 2019, at 12:12, Marco Schmidt wrote: > > In fact, many of the allocations we are currently making have gone through such a recycling process. > We expect that we will continue to receive IPv4 addresses due to LIR closures and other reasons for some time after the current IPv4 pool has been exhausted. Thanks for correcting my mistake Marco. From gert at space.net Thu Feb 7 14:30:52 2019 From: gert at space.net (Gert Doering) Date: Thu, 7 Feb 2019 14:30:52 +0100 Subject: [address-policy-wg] can deadbeat LIRs reverse IPv4 exhaustion? In-Reply-To: <532M4MO8.TGYOX4DH@mobil.space.net> References: <2555823.qEnKSUCqr2@hunator-ntb.local> <1f66c0f8-5a2b-aabc-45f4-e582a7ccd1d1@ripe.net> <532M4MO8.TGYOX4DH@mobil.space.net> Message-ID: Hi, On Thu, Feb 07, 2019 at 10:14:18AM +0000, Jim Reid wrote: > Besides, there???s no mechanism or policy for the NCC to recover addresses from LIRs that don???t pay their bills. If such mechanisms or policies existed, they???d be unworkable. There???s no way of knowing for sure that those addresses weren???t being used. So if they were reclaimed, the addresses couldn???t be allocated to someone else. Uh. There actually is - if a LIR stops paying their NCC member fees, the LIR account will be closed, and the address space will be reclaimed. After sufficient quarantaine, the addresses will be allocated to someone else. (There is no mechanism to reclaim addresses from LIR that "do not use them", because they were given out under policies that had no such clause - but that's different from "LIRs that don't pay their bills") Gert Doering -- APWG chair -- 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 sander at steffann.nl Thu Feb 7 15:52:21 2019 From: sander at steffann.nl (Sander Steffann) Date: Thu, 7 Feb 2019 15:52:21 +0100 Subject: [address-policy-wg] 2019-02 New Policy Proposal (Reducing IPv4 Allocations to a /24) In-Reply-To: <2b7f70d2-835c-913c-5dbc-5636104594c5@servereasy.it> References: <2b7f70d2-835c-913c-5dbc-5636104594c5@servereasy.it> Message-ID: <0093F93A-DB0A-4C4F-A59D-6E316A858BB6@steffann.nl> Hi, > I oppose this proposal, unless at least RIPE NCC will charge members based on how much IPv4 space they have. Sorry, membership fee structure is out of scope there. The NCC members decided years ago to adopt a membership-based-fee instead of a resource-based-fee. It's not up to this working group to decide on that. Cheers, Sander -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: Message signed with OpenPGP URL: From danny at danysek.cz Thu Feb 7 18:34:54 2019 From: danny at danysek.cz (Daniel Suchy) Date: Thu, 7 Feb 2019 18:34:54 +0100 Subject: [address-policy-wg] 2019-02 New Policy Proposal (Reducing IPv4 Allocations to a /24) In-Reply-To: <2b7f70d2-835c-913c-5dbc-5636104594c5@servereasy.it> References: <2b7f70d2-835c-913c-5dbc-5636104594c5@servereasy.it> Message-ID: <2e5b5e52-c849-694c-e35c-eb3a6b6c0ec6@danysek.cz> Hello, On 2/7/19 1:17 PM, Servereasy via address-policy-wg wrote: > I oppose this proposal, unless at least RIPE NCC will charge members > based on how much IPv4 space they have. I find that this will be the > only way to really boost IPv6 adoption. this is problem maily due to law and related taxes. Such diversification was here and this changed few years back. I think only one reason, which will really boost IPv6 adoption is real exhaustion of IPv4 pool within our (RIPE) region. 2019-02 proposal is just delay this (and allowing more newcomers to start their bussiness), nothing else. - Daniel From ripe-wgs at radu-adrian.feurdean.net Thu Feb 7 20:46:46 2019 From: ripe-wgs at radu-adrian.feurdean.net (Radu-Adrian FEURDEAN) Date: Thu, 07 Feb 2019 14:46:46 -0500 Subject: [address-policy-wg] =?utf-8?q?2019-02_New_Policy_Proposal_=28Red?= =?utf-8?q?ucing_IPv4_Allocations_to_a_/24=29?= In-Reply-To: References: Message-ID: <94aafe96-dd1b-45de-8034-6ec3e23d696c@www.fastmail.com> On Wed, Feb 6, 2019, at 11:19, Jim Reid wrote: > The question here I think is what should be the trigger event. And then > what happens to the remaining v4 addresses that fell down the back of > the sofa, slipped through the cracks in the floorboards and ended up in > a disused basement behind a locked door that has a ?beware of the > leopard? sign. > > Well OK. That?s two questions. :-) Concerning the trigger, it seems pretty clear : Cannot allocate a single /22. The second, I would rewrite into "What is the amount of recovered space every year? When does recovery happens (all year or specific period of the year) ?". Plus estimations for the future if any. However there are some questions on what does the NCC do *before* getting there. Let's remember there still are temporary allocations. How much space do they usually take out of the /13 reserved for them ? Should be move temporary allocations to standard pool (and merge their pool into the main one) ? If yes, when ? Now ? When there are no more /22 in the regular pool (preventing the switch to /24 for a few months) ? when there is only /xx (/13 suggested) free space in the regular pool ? Do we need a policy for that of is it just "NCC bookkeeping stuff" ? There's the quarantine (returned/recovered blocks) : what happens when there's not a single /22 in the "free" pool, but there is space in the "Reserved pool" (quarantine + temp allocations). > How much v4 space would the NCC be holding once it?s no longer got /22s > to allocate? > > That?s three questions. :-) That's about 10 questions. An answer before the impact analysis (I'm confident this will at least reach "impact analysis") would be greatly appreciated. I will be able to give an opinion based on the answers to those questions. For the moment I'm half for (because the waiting list is something that will be needed at some point in the future), and half against (the "let's end the IPv4 madness" stuff). Regards, -- Radu-Adrian FEURDEAN From cfriacas at fccn.pt Fri Feb 8 09:15:09 2019 From: cfriacas at fccn.pt (=?ISO-8859-15?Q?Carlos_Fria=E7as?=) Date: Fri, 8 Feb 2019 08:15:09 +0000 (WET) Subject: [address-policy-wg] 2019-02 New Policy Proposal (Reducing IPv4 Allocations to a /24) In-Reply-To: <2e5b5e52-c849-694c-e35c-eb3a6b6c0ec6@danysek.cz> References: <2b7f70d2-835c-913c-5dbc-5636104594c5@servereasy.it> <2e5b5e52-c849-694c-e35c-eb3a6b6c0ec6@danysek.cz> Message-ID: Dear Daniel, All, On Thu, 7 Feb 2019, Daniel Suchy wrote: > Hello, > > On 2/7/19 1:17 PM, Servereasy via address-policy-wg wrote: >> I oppose this proposal, unless at least RIPE NCC will charge members >> based on how much IPv4 space they have. I find that this will be the >> only way to really boost IPv6 adoption. > > this is problem maily due to law and related taxes. Such diversification > was here and this changed few years back. Exactly! And apart from that, RIPE NCC also distributes other numbering resources apart from IPv4 addresses, and has a broader set of services. :-) > I think only one reason, which will really boost IPv6 adoption is real > exhaustion of IPv4 pool within our (RIPE) region. Please, that is leading nowhere. I also would like to see a stronger IPv6 adoption, and reach the point where IPv6 packets become dominant (i.e. >50%) and at a later stage reach a point where IPv4 routers/services/everything could be disconnected because they weren't useful anymore. Imho, it doesn't help to repeat to exhaustion that IPv4 is legacy. That's not the way people are doing IPv4-only today will feel they *need* to deploy IPv6. Please let us focus on reality: IPv6 adoption depends on a multitude of scenarios. For ORGs that already have their own fair share of IPv4 addresses (suitable for their needs) IPv6 will always be "low priority". For those ORGs, IPv4 exhaustion can be *irrelevant* -- it doesn't affect *them*, only 3rd parties are impacted. Their IPv4 addresses will still be usable (and useful). > 2019-02 proposal is just delay this (and allowing more newcomers to > start their bussiness), nothing else. No. That's completely not the idea. The core purpose of 2019-02 is to allow (more) newcomers to access a tiny bit of IPv4 address space so their (hopefully IPv6-enabled) infrastructure will have path to the IPv4-only world (without going to the market). I would happilly include a "you have prove the NCC you have deployed IPv6"-type clause on this proposal's v2.0, but i'm 99,9% sure that would be a problem for a lot of people. :-( This way, if newcomers just become a LIR and grab a /24, they can become independent (routing policy-wise, etc...) from their upstream(s) -- and i openly expect their engagement/exposure with the NCC will improve their knowledge about IPv6, and their future willingness to deploy it. ;-) I hope this helps you understand my motivation to have kickstarted this 2019-02 work jointly with Sander. Best Regards, Carlos > - Daniel > From cfriacas at fccn.pt Fri Feb 8 09:43:33 2019 From: cfriacas at fccn.pt (=?ISO-8859-15?Q?Carlos_Fria=E7as?=) Date: Fri, 8 Feb 2019 08:43:33 +0000 (WET) Subject: [address-policy-wg] 2019-02 New Policy Proposal (Reducing IPv4 Allocations to a /24) In-Reply-To: <94aafe96-dd1b-45de-8034-6ec3e23d696c@www.fastmail.com> References: <94aafe96-dd1b-45de-8034-6ec3e23d696c@www.fastmail.com> Message-ID: Hi Radu-Adrian, All, On Thu, 7 Feb 2019, Radu-Adrian FEURDEAN wrote: > On Wed, Feb 6, 2019, at 11:19, Jim Reid wrote: >> The question here I think is what should be the trigger event. And then >> what happens to the remaining v4 addresses that fell down the back of >> the sofa, slipped through the cracks in the floorboards and ended up in >> a disused basement behind a locked door that has a ?beware of the >> leopard? sign. >> >> Well OK. That?s two questions. :-) > > Concerning the trigger, it seems pretty clear : Cannot allocate a single /22. > The second, I would rewrite into "What is the amount of recovered space > every year? When does recovery happens (all year or specific period of > the year) ?". That's really for the NCC's Registration Services Dept. to answer, i think :-) > Plus estimations for the future if any. Oh, that will be a hard exercise. > However there are some questions on what does the NCC do *before* getting there. > > Let's remember there still are temporary allocations. How much space do > they usually take out of the /13 reserved for them ? Should be move > temporary allocations to standard pool (and merge their pool into the > main one) ? If yes, when ? Now ? When there are no more /22 in the > regular pool (preventing the switch to /24 for a few months) ? when > there is only /xx (/13 suggested) free space in the regular pool ? Do > we need a policy for that of is it just "NCC bookkeeping stuff" ? I would say: Don't touch that /13. Keep it simple :-) > There's the quarantine (returned/recovered blocks) : what happens when > there's not a single /22 in the "free" pool, but there is space in the > "Reserved pool" (quarantine + temp allocations). Imho, that's a different pool. >> How much v4 space would the NCC be holding once it?s no longer got /22s >> to allocate? >> >> That?s three questions. :-) > > That's about 10 questions. An answer before the impact analysis (I'm > confident this will at least reach "impact analysis") would be greatly > appreciated. > > I will be able to give an opinion based on the answers to those > questions. For the moment I'm half for (because the waiting list is > something that will be needed at some point in the future), Fully agree :-) > and half against (the "let's end the IPv4 madness" stuff). Please see my previous e-mail. Unfortunately IPv4 *usage* is not going away anytime soon... :( Regards, Carlos > Regards, > -- > Radu-Adrian FEURDEAN > From danny at danysek.cz Fri Feb 8 10:11:28 2019 From: danny at danysek.cz (Daniel Suchy) Date: Fri, 8 Feb 2019 10:11:28 +0100 Subject: [address-policy-wg] 2019-02 New Policy Proposal (Reducing IPv4 Allocations to a /24) In-Reply-To: References: <2b7f70d2-835c-913c-5dbc-5636104594c5@servereasy.it> <2e5b5e52-c849-694c-e35c-eb3a6b6c0ec6@danysek.cz> Message-ID: <59b97318-e18a-ab5d-d4ab-9dad468e4ac2@danysek.cz> Hello, On 2/8/19 9:15 AM, Carlos Fria?as via address-policy-wg wrote: >> I think only one reason, which will really boost IPv6 adoption is real >> exhaustion of IPv4 pool within our (RIPE) region. > I also would like to see a stronger IPv6 adoption, and reach the point > where IPv6 packets become dominant (i.e. >50%) and at a later stage > reach a point where IPv4 routers/services/everything could be > disconnected because they weren't useful anymore. Since there're happy-eyeball RFC implementations, it's somewhat harder to perform such measurments. But I think IPv6 adoption was boosted in regions, where IPv4 pool dried. >> 2019-02 proposal is just delay this (and allowing more newcomers to >> start their bussiness), nothing else. > The core purpose of 2019-02 is to allow (more) newcomers to access a > tiny bit of IPv4 address space so their (hopefully IPv6-enabled) > infrastructure will have path to the IPv4-only world (without going to > the market). Yes, I understand this purpose and to be clear - I'm not against this proposal (that means, I support it). /24 allocations for newcomers are also used within ARIN region (since 2015 depletetion), so this cannot be any problem with such limitation within our (RIPE) region. - Daniel From cfriacas at fccn.pt Fri Feb 8 10:25:16 2019 From: cfriacas at fccn.pt (=?ISO-8859-15?Q?Carlos_Fria=E7as?=) Date: Fri, 8 Feb 2019 09:25:16 +0000 (WET) Subject: [address-policy-wg] 2019-02 New Policy Proposal (Reducing IPv4 Allocations to a /24) In-Reply-To: <59b97318-e18a-ab5d-d4ab-9dad468e4ac2@danysek.cz> References: <2b7f70d2-835c-913c-5dbc-5636104594c5@servereasy.it> <2e5b5e52-c849-694c-e35c-eb3a6b6c0ec6@danysek.cz> <59b97318-e18a-ab5d-d4ab-9dad468e4ac2@danysek.cz> Message-ID: On Fri, 8 Feb 2019, Daniel Suchy wrote: > Hello, Hello again, > On 2/8/19 9:15 AM, Carlos Fria?as via address-policy-wg wrote: >>> I think only one reason, which will really boost IPv6 adoption is real >>> exhaustion of IPv4 pool within our (RIPE) region. >> I also would like to see a stronger IPv6 adoption, and reach the point >> where IPv6 packets become dominant (i.e. >50%) and at a later stage >> reach a point where IPv4 routers/services/everything could be >> disconnected because they weren't useful anymore. > > Since there're happy-eyeball RFC implementations, it's somewhat harder > to perform such measurments. But I think IPv6 adoption was boosted in > regions, where IPv4 pool dried. It's difficult to measure accurately, and even harder to establish a cause/effect link from IPv4 dried pools. :-( Google is currently measuring (globally) around 25%, from 15% 2 years ago, and from 5% 4 years ago. I also read that as a "boost", yes :-) But unfortunately it's still a bit away from 50%... and we must not forget that Google is only one (big) content provider. There is still a lot of IPv4-only content around, and access to it naturally measures at 0%. >>> 2019-02 proposal is just delay this (and allowing more newcomers to >>> start their bussiness), nothing else. >> The core purpose of 2019-02 is to allow (more) newcomers to access a >> tiny bit of IPv4 address space so their (hopefully IPv6-enabled) >> infrastructure will have path to the IPv4-only world (without going to >> the market). > > Yes, I understand this purpose and to be clear - I'm not against this > proposal (that means, I support it). /24 allocations for newcomers are > also used within ARIN region (since 2015 depletetion), so this cannot be > any problem with such limitation within our (RIPE) region. Thank You! Regards, Carlos > - Daniel > From ripe-wgs at radu-adrian.feurdean.net Fri Feb 8 14:32:36 2019 From: ripe-wgs at radu-adrian.feurdean.net (Radu-Adrian FEURDEAN) Date: Fri, 08 Feb 2019 08:32:36 -0500 Subject: [address-policy-wg] =?utf-8?q?2019-02_New_Policy_Proposal_=28Red?= =?utf-8?q?ucing_IPv4_Allocations_to_a_/24=29?= In-Reply-To: References: <94aafe96-dd1b-45de-8034-6ec3e23d696c@www.fastmail.com> Message-ID: On Fri, Feb 8, 2019, at 09:43, Carlos Fria?as wrote: > > The second, I would rewrite into "What is the amount of recovered space > > every year? When does recovery happens (all year or specific period of > > the year) ?". > > That's really for the NCC's Registration Services Dept. to answer, i think > :-) Exactly ! > > Plus estimations for the future if any. > > Oh, that will be a hard exercise. They (the NCC) are pretty good at this kind of stuff. > > However there are some questions on what does the NCC do *before* getting there. > > > > Let's remember there still are temporary allocations. How much space do > > they usually take out of the /13 reserved for them ? Should be move > > temporary allocations to standard pool (and merge their pool into the > > main one) ? If yes, when ? Now ? When there are no more /22 in the > > regular pool (preventing the switch to /24 for a few months) ? when > > there is only /xx (/13 suggested) free space in the regular pool ? Do > > we need a policy for that of is it just "NCC bookkeeping stuff" ? > > I would say: Don't touch that /13. Keep it simple :-) That may get some people angry. A /13 is 512 /22s (5-6 weeks worth of allocations at current rate) or 2048 /24s (I expect that to be more than 6 months worth with the current proposal). That is beginning to be a little too much. Let's remember that with the current proposal, the price of a /24 via "additional LIR" will be pretty much in line with the market one (unless the market prices spike within one year). That will definitely reduce the LIR creation and in consequence the allocation rate. As for users of temporary allocations, there's the "conference" guys that should be kicked a little bit to do more IPv6 and less IPv4 (last years CiscoLive Barcelona was a pretty big fail for this matter - I understand they finally fixed it this year). > > There's the quarantine (returned/recovered blocks) : what happens when > > there's not a single /22 in the "free" pool, but there is space in the > > "Reserved pool" (quarantine + temp allocations). > > Imho, that's a different pool. It's different, but after a few months address blocks go from quarantine pool to the allocation pool. Reason to get some people angry. > > and half against (the "let's end the IPv4 madness" stuff). > > Please see my previous e-mail. Unfortunately IPv4 *usage* is not going > away anytime soon... :( No, it's not going away, but we should to everything necessary to move from a stance "IPv6 guys area savage geeks, the normal is IPv4" to one of "IPv4 is outdated retrograde stuff, IPv6 is normal". As long as "you can still get your tiny piece of IPv4" I don't think the general mindset will change. Then we could get to a situation similar with one we had with current policy : almost 3 years into the "last /8" we had more than a /8 available for a few months. I wouldn't like something similar to happen again. I would like to have the waiting list "populated" permanently starting from 2021 (even late 2020). -- Radu-Adrian FEURDEAN From ripe-wgs at radu-adrian.feurdean.net Fri Feb 8 15:37:38 2019 From: ripe-wgs at radu-adrian.feurdean.net (Radu-Adrian FEURDEAN) Date: Fri, 08 Feb 2019 09:37:38 -0500 Subject: [address-policy-wg] =?utf-8?q?2019-02_New_Policy_Proposal_=28Red?= =?utf-8?q?ucing_IPv4_Allocations_to_a_/24=29?= In-Reply-To: References: Message-ID: <0873dbaa-0c51-49de-a03b-f5edf8a53dcc@www.fastmail.com> Meanwhile, in ARIN-Land: https://www.mail-archive.com/nanog at nanog.org/msg98840.html Fwd: [arin-announce] ARIN Board Suspends Waiting List Issuance Policy -- Radu-Adrian FEURDEAN From cfriacas at fccn.pt Fri Feb 8 16:09:23 2019 From: cfriacas at fccn.pt (=?ISO-8859-15?Q?Carlos_Fria=E7as?=) Date: Fri, 8 Feb 2019 15:09:23 +0000 (WET) Subject: [address-policy-wg] 2019-02 New Policy Proposal (Reducing IPv4 Allocations to a /24) In-Reply-To: <0873dbaa-0c51-49de-a03b-f5edf8a53dcc@www.fastmail.com> References: <0873dbaa-0c51-49de-a03b-f5edf8a53dcc@www.fastmail.com> Message-ID: >From the minutes: "The President presented a slide deck to the Board with details of the issue." I guess that slide deck is not public...? Carlos On Fri, 8 Feb 2019, Radu-Adrian FEURDEAN wrote: > Meanwhile, in ARIN-Land: > > https://www.mail-archive.com/nanog at nanog.org/msg98840.html > Fwd: [arin-announce] ARIN Board Suspends Waiting List Issuance Policy > > -- > Radu-Adrian FEURDEAN > From noc at netskin.com Fri Feb 8 16:28:42 2019 From: noc at netskin.com (Corin Langosch) Date: Fri, 08 Feb 2019 16:28:42 +0100 Subject: [address-policy-wg] 2019-02 New Policy Proposal (Reducing IPv4 Allocations to a /24) In-Reply-To: <2e5b5e52-c849-694c-e35c-eb3a6b6c0ec6@danysek.cz> References: <2b7f70d2-835c-913c-5dbc-5636104594c5@servereasy.it> <2e5b5e52-c849-694c-e35c-eb3a6b6c0ec6@danysek.cz> Message-ID: <1a1ac62a37244bf6cd33fcf6fb5c3140d0f1dffd.camel@netskin.com> Hello On Thu, 2019-02-07 at 18:34 +0100, Daniel Suchy wrote: > I oppose this proposal, unless at least RIPE NCC will charge > > members > > based on how much IPv4 space they have. I find that this will be > > the > > only way to really boost IPv6 adoption. > > this is problem maily due to law and related taxes. Such > diversification > was here and this changed few years back. > I'm really curious about this argument. Could you please elaborate further why this should be a problem? Usage based billing is very much common for almost every service. Just bill a base fee (might include some training, ...), XXX EUR per /24 Ipv4, XXX EUR per /32 Ipv6 and XXX EUR per AS, XXX EUR per ... Changes are very high that this would lead to a quick return of lots of Ipv4 addresses, if the price for Ipv4 is high enough. As a nice side effect the fees would be much fairer distributed among the members. Thanks Corin From farmer at umn.edu Fri Feb 8 16:33:42 2019 From: farmer at umn.edu (David Farmer) Date: Fri, 8 Feb 2019 09:33:42 -0600 Subject: [address-policy-wg] 2019-02 New Policy Proposal (Reducing IPv4 Allocations to a /24) In-Reply-To: References: <0873dbaa-0c51-49de-a03b-f5edf8a53dcc@www.fastmail.com> Message-ID: I can't speak to a public version of the slides that went to the ARIN Board of Trustees, John Curran will have to do that. However, this section of ARIN policy was the subject of the Policy Experience Report at the previous ARIN meeting and that is public. >From the ARIN 42 meeting report; Transcript; https://www.arin.net/vault/participate/meetings/reports/ARIN_42/ppm1_transcript.html#anchor_5 Youtube; https://www.youtube.com/watch?v=MJHgs4wWO58 Presentation; https://www.arin.net/vault/participate/meetings/reports/ARIN_42/PDF/PPM/sweeting-policy.pdf Hope that helps. On Fri, Feb 8, 2019 at 9:09 AM Carlos Fria?as via address-policy-wg < address-policy-wg at ripe.net> wrote: > > > From the minutes: > > "The President presented a slide deck to the Board with details of the > issue." > > I guess that slide deck is not public...? > > > Carlos > > > On Fri, 8 Feb 2019, Radu-Adrian FEURDEAN wrote: > > > Meanwhile, in ARIN-Land: > > > > https://www.mail-archive.com/nanog at nanog.org/msg98840.html > > Fwd: [arin-announce] ARIN Board Suspends Waiting List Issuance Policy > > > > -- > > Radu-Adrian FEURDEAN > > > > -- =============================================== 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 gert at space.net Fri Feb 8 16:34:24 2019 From: gert at space.net (Gert Doering) Date: Fri, 8 Feb 2019 16:34:24 +0100 Subject: [address-policy-wg] 2019-02 New Policy Proposal (Reducing IPv4 Allocations to a /24) In-Reply-To: <8MHMNYKG.V7FUO071@mobil.space.net> References: <2b7f70d2-835c-913c-5dbc-5636104594c5@servereasy.it> <2e5b5e52-c849-694c-e35c-eb3a6b6c0ec6@danysek.cz> <8MHMNYKG.V7FUO071@mobil.space.net> Message-ID: <20190208153424.GH71606@Space.Net> Hi, On Fri, Feb 08, 2019 at 04:28:42PM +0100, Corin Langosch wrote: > further why this should be a problem? Usage based billing is very much "usage based" is "you pay for the amount of work and other costs you create at the NCC", which is about what we have now. What you are describing is "sale of goods" - and that is a problem because it would make the addresses the NCC has in stock a taxable asset. 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 jim at rfc1035.com Fri Feb 8 16:39:58 2019 From: jim at rfc1035.com (Jim Reid) Date: Fri, 8 Feb 2019 15:39:58 +0000 Subject: [address-policy-wg] irrelevant and meaningless Subject header goes here In-Reply-To: <20190208153424.GH71606@Space.Net> References: <2b7f70d2-835c-913c-5dbc-5636104594c5@servereasy.it> <2e5b5e52-c849-694c-e35c-eb3a6b6c0ec6@danysek.cz> <8MHMNYKG.V7FUO071@mobil.space.net> <20190208153424.GH71606@Space.Net> Message-ID: > On 8 Feb 2019, at 15:34, Gert Doering wrote: > > "usage based" is "you pay for the amount of work and other costs you create > at the NCC", which is about what we have now. I think we need a new thread or two. What?s now being discussed is far removed from 2019-02. From npediaditi at ripe.net Fri Feb 8 17:24:26 2019 From: npediaditi at ripe.net (Nikolas Pediaditis) Date: Fri, 8 Feb 2019 17:24:26 +0100 Subject: [address-policy-wg] 2019-02 New Policy Proposal (Reducing IPv4 Allocations to a /24) In-Reply-To: References: <94aafe96-dd1b-45de-8034-6ec3e23d696c@www.fastmail.com> Message-ID: Dear Carlos, Radu-Adrian, all, Following your questions, I have some numbers and other information that might be useful. 1. Currently, there will be 977,408 IPv4 addresses remaining in our free pool once we are no longer able to allocate contiguous /22s. This number excludes prefixes that are smaller than a /24 and those prefixes that have been reserved for IXP assignments or temporary assignments. It might also be slightly larger by then, due to addresses that are recovered in the meantime. 2. Over the past three years, we have recovered the following amounts of IPv4 addresses: 2016: 83,712 2017: 106,368 2018: 53,824 Once an IPv4 allocation or assignment has been de-registered from its holder, it is added to the RIPE NCC?s free pool (after a quarantine period). It is then available to be allocated to another organisation. There are no specific periods of time for recovering IPv4 addresses from resource holders. This can happen at any point and for multiple reasons, all of which are unpredictable. For this reason, any predictions we could make about the number of addresses we expect to recover in the future would be highly unreliable. 3. We have assigned the following amounts of IPv4 addresses as temporary assignments over the past three years: 2016: 205,568 2017: 188,928 2018: 162,048 (Note that these figures represent the sum of all temporary assignments made in that year.) Temporary assignments are made from a /13 that has been reserved for this purpose. When a temporary assignment is returned, it is added back to this pool. Finally, I would like to clarify that IPv4 allocations and temporary assignments come from two separate pools - neither influences the other. I hope this helps. Kind regards, Nikolas Pediaditis Assistant Manager Registration Services & Policy Development RIPE NCC > On 8 Feb 2019, at 14:32, Radu-Adrian FEURDEAN wrote: > > On Fri, Feb 8, 2019, at 09:43, Carlos Fria?as wrote: >>> The second, I would rewrite into "What is the amount of recovered space >>> every year? When does recovery happens (all year or specific period of >>> the year) ?". >> >> That's really for the NCC's Registration Services Dept. to answer, i think >> :-) > > Exactly ! > >>> Plus estimations for the future if any. >> >> Oh, that will be a hard exercise. > > They (the NCC) are pretty good at this kind of stuff. > >>> However there are some questions on what does the NCC do *before* getting there. >>> >>> Let's remember there still are temporary allocations. How much space do >>> they usually take out of the /13 reserved for them ? Should be move >>> temporary allocations to standard pool (and merge their pool into the >>> main one) ? If yes, when ? Now ? When there are no more /22 in the >>> regular pool (preventing the switch to /24 for a few months) ? when >>> there is only /xx (/13 suggested) free space in the regular pool ? Do >>> we need a policy for that of is it just "NCC bookkeeping stuff" ? >> >> I would say: Don't touch that /13. Keep it simple :-) > > That may get some people angry. A /13 is 512 /22s (5-6 weeks worth of allocations at current rate) or 2048 /24s (I expect that to be more than 6 months worth with the current proposal). That is beginning to be a little too much. > > Let's remember that with the current proposal, the price of a /24 via "additional LIR" will be pretty much in line with the market one (unless the market prices spike within one year). That will definitely reduce the LIR creation and in consequence the allocation rate. > > As for users of temporary allocations, there's the "conference" guys that should be kicked a little bit to do more IPv6 and less IPv4 (last years CiscoLive Barcelona was a pretty big fail for this matter - I understand they finally fixed it this year). > >>> There's the quarantine (returned/recovered blocks) : what happens when >>> there's not a single /22 in the "free" pool, but there is space in the >>> "Reserved pool" (quarantine + temp allocations). >> >> Imho, that's a different pool. > > It's different, but after a few months address blocks go from quarantine pool to the allocation pool. Reason to get some people angry. > >>> and half against (the "let's end the IPv4 madness" stuff). >> >> Please see my previous e-mail. Unfortunately IPv4 *usage* is not going >> away anytime soon... :( > > No, it's not going away, but we should to everything necessary to move from a stance "IPv6 guys area savage geeks, the normal is IPv4" to one of "IPv4 is outdated retrograde stuff, IPv6 is normal". As long as "you can still get your tiny piece of IPv4" I don't think the general mindset will change. > > Then we could get to a situation similar with one we had with current policy : almost 3 years into the "last /8" we had more than a /8 available for a few months. I wouldn't like something similar to happen again. I would like to have the waiting list "populated" permanently starting from 2021 (even late 2020). > > -- > Radu-Adrian FEURDEAN > > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2640 bytes Desc: not available URL: From noc at netskin.com Fri Feb 8 17:34:32 2019 From: noc at netskin.com (Corin Langosch) Date: Fri, 08 Feb 2019 17:34:32 +0100 Subject: [address-policy-wg] 2019-02 New Policy Proposal (Reducing IPv4 Allocations to a /24) In-Reply-To: <20190208153424.GH71606@Space.Net> References: <2b7f70d2-835c-913c-5dbc-5636104594c5@servereasy.it> <2e5b5e52-c849-694c-e35c-eb3a6b6c0ec6@danysek.cz> <8MHMNYKG.V7FUO071@mobil.space.net> <20190208153424.GH71606@Space.Net> Message-ID: Hi Gert On Fri, 2019-02-08 at 16:34 +0100, Gert Doering wrote: > On Fri, Feb 08, 2019 at 04:28:42PM +0100, Corin Langosch wrote: > > further why this should be a problem? Usage based billing is very > > much > > "usage based" is "you pay for the amount of work and other costs you > create at the NCC", which is about what we have now. > What's the difference between receiving an allocation from RIPE (= renting IPs from RIPE) and getting an allocation of storage space from some provider (= renting storage space)? > What you are describing is "sale of goods" - and that is a problem > because it would make the addresses the NCC has in stock a taxable > asset. 10.2 of ripe-673 states that allocations are not granting any ownership, thus RIPE is not selling anything but only granting usage. Just like a hosting provider can lend storage space. Imo IPs are already a taxable asset (as are the disks of the hosting provider) just because of the IP market created by RIPE. So closing the IP market and replacing it with a financial model which more or less forces companies to return unused (or otherwise wasted) IPs would be the way to go. Corin From gert at space.net Fri Feb 8 18:04:00 2019 From: gert at space.net (Gert Doering) Date: Fri, 8 Feb 2019 18:04:00 +0100 Subject: [address-policy-wg] 2019-02 New Policy Proposal (Reducing IPv4 Allocations to a /24) In-Reply-To: References: <2b7f70d2-835c-913c-5dbc-5636104594c5@servereasy.it> <2e5b5e52-c849-694c-e35c-eb3a6b6c0ec6@danysek.cz> <8MHMNYKG.V7FUO071@mobil.space.net> <20190208153424.GH71606@Space.Net> Message-ID: <20190208170400.GI71606@Space.Net> Hi, On Fri, Feb 08, 2019 at 04:52:29PM +0100, Bernd Sontheimer wrote: > But i don't see that every RIPE member has to pay exactly the same part > as all others. In the beginning we had different registry sizes, XS, S, > M and L with different fees, according to the hold address space. I > think this can and should reflect the different amount of work for > maintenance and services according to the member size. Why is this no > longer possible? Why do we as an operator with 10000 customers exactly > the same fee as one with 10 Mio. customers and much more adress space > (and much more revenue)? I think fair would be a base fee for every > member and an additional fee which is variable depending on the size of > the hold adress space. That has nothing to do with "selling address" > space, but shares only the yearly cost proportional according to the > size of the members. Not necessarily disagreeing with you that there might be good arguments for "who pays not so much" vs. "who pays more". Now, I doubt that a large carrier that has everything automated causes as much cost at the NCC as a new LIR that opens a support ticket twice a month... so, shall the new LIR pay twice the amount that DTAG pays? But anyway: as Jim Reid correctly remarked, this is a different thread, *and* doesn't belong into APWG anyway. Fees are a member business, and need to be voted on in the member meeting (AGM) and discussed on the ripe-members list. So: please stop this particular sub-discussion on the APWG list. Gert Doering -- APWG chair -- 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 danny at danysek.cz Fri Feb 8 21:52:42 2019 From: danny at danysek.cz (Daniel Suchy) Date: Fri, 8 Feb 2019 21:52:42 +0100 Subject: [address-policy-wg] 2019-02 New Policy Proposal (Reducing IPv4 Allocations to a /24) In-Reply-To: References: <2b7f70d2-835c-913c-5dbc-5636104594c5@servereasy.it> <2e5b5e52-c849-694c-e35c-eb3a6b6c0ec6@danysek.cz> <8MHMNYKG.V7FUO071@mobil.space.net> <20190208153424.GH71606@Space.Net> Message-ID: <059ddf93-1f95-7cbd-04d1-2ce6a9bf7e69@danysek.cz> On 2/8/19 5:34 PM, Corin Langosch wrote: > What's the difference between receiving an allocation from RIPE (= > renting IPs from RIPE) and getting an allocation of storage space from > some provider (= renting storage space)? The main difference is in responsibility of tax payment. Once RIPE will "sell services" with payment diferenciation based od ammount of assets held by each member, taxation will be based od laws valid in one specific country based on HQ location. This is my simplification (I'm not a lawyer), but this was discussed in deep in past - and all relevant mailing-list archives are public.... so if you're interested, you can deep dive into these past discussions - there's no reason to raise them again... I don't see reason to repeat such discussion. >> What you are describing is "sale of goods" - and that is a problem >> because it would make the addresses the NCC has in stock a taxable >> asset. > > 10.2 of ripe-673 states that allocations are not granting any > ownership, thus RIPE is not selling anything but only granting usage. > Just like a hosting provider can lend storage space. Imo IPs are > already a taxable asset (as are the disks of the hosting provider) just > because of the IP market created by RIPE. So closing the IP market and > replacing it with a financial model which more or less forces companies > to return unused (or otherwise wasted) IPs would be the way to go. IP market is not created *only* by RIPE. There're other RIRs, with their own policies.. and also legacy resource holders having their allocations before RIRs scheme were introduced. And of course, legacy resource holders (holding "class A / class B") ranges can sell their assets independently on some RIR policy... this market is more complicated. And also current RIPE policies doesn't break ability to earn more than one allocation (currently limited to /22) to single real entity (represented by multiple legal persons). It's happening already in large scale. In this perspective, limiting new allocations only to /24 (as proposed by 2019-02) introduces additional complication to these "speculative" members violating current policy spirit... simply by making their approach harder to implement. - Daniel From cfriacas at fccn.pt Sat Feb 9 00:34:11 2019 From: cfriacas at fccn.pt (=?ISO-8859-15?Q?Carlos_Fria=E7as?=) Date: Fri, 8 Feb 2019 23:34:11 +0000 (WET) Subject: [address-policy-wg] 2019-02 New Policy Proposal (Reducing IPv4 Allocations to a /24) In-Reply-To: References: <0873dbaa-0c51-49de-a03b-f5edf8a53dcc@www.fastmail.com> Message-ID: Thanks! I think i already got some bits :-)) 2019-02 (currently) doesn't address transfers in any way, though. Cheers, Carlos On Fri, 8 Feb 2019, David Farmer wrote: > I can't speak to a public version of the slides that went to the ARIN Board of Trustees, John Curran will have to do that.? However, this section of ARIN?policy was the subject of the Policy Experience Report at the previous ARIN > meeting and that is public.?? > > From the ARIN 42 meeting report; > > Transcript; > https://www.arin.net/vault/participate/meetings/reports/ARIN_42/ppm1_transcript.html#anchor_5 > > Youtube; > https://www.youtube.com/watch?v=MJHgs4wWO58 > > Presentation; > https://www.arin.net/vault/participate/meetings/reports/ARIN_42/PDF/PPM/sweeting-policy.pdf? > > Hope that helps. > > On Fri, Feb 8, 2019 at 9:09 AM Carlos Fria?as via address-policy-wg wrote: > > > From the minutes: > > "The President presented a slide deck to the Board with details of the > issue." > > I guess that slide deck is not public...? > > > Carlos > > > On Fri, 8 Feb 2019, Radu-Adrian FEURDEAN wrote: > > > Meanwhile, in ARIN-Land: > > > > https://www.mail-archive.com/nanog at nanog.org/msg98840.html > > Fwd: [arin-announce] ARIN Board Suspends Waiting List Issuance Policy > > > > -- > > Radu-Adrian FEURDEAN > > > > > > -- > =============================================== > 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 > =============================================== > > From mangawilly at gmail.com Sat Feb 9 13:59:47 2019 From: mangawilly at gmail.com (Willy MANGA) Date: Sat, 9 Feb 2019 13:59:47 +0100 Subject: [address-policy-wg] 2019-02 New Policy Proposal (Reducing, IPv4 Allocations to a /24) In-Reply-To: References: Message-ID: <3c1a64e9-8e91-9d64-3a19-cc6b8d460200@gmail.com> Hi, >[...] > From: Carlos Fria?as > [...] > I've been deploying and advocating IPv6 since 2001. Others have been doing > it for a longer period. Within this timespan, i have only read about *one* > organisation which publicly expressed plans to scrap IPv4 from their > network/services, but they have dropped that in the meanwhile... Please don't tell me it's the IPv4 disposal technician [1] team :) 1. https://youtu.be/cNMQUCeNW78?t=2176 -- Willy Manga @ongolaboy https://ongola.blogspot.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From mangawilly at gmail.com Sat Feb 9 14:00:35 2019 From: mangawilly at gmail.com (Willy MANGA) Date: Sat, 9 Feb 2019 14:00:35 +0100 Subject: [address-policy-wg] 2019-02 New Policy Proposal (Reducing, IPv4 Allocations to a /24) In-Reply-To: References: Message-ID: <0f802c0e-aeff-901f-d8e0-0c79f22ce45d@gmail.com> Hi, > From: Peter Hessler > Then come back when you have a solution to force GitHub, Twitter, > Amazon, and a lot more, to launch an IPv6 version of their website. Hopefully it will come soon. At least all have already v6 prefixes used 'inside' their own networks .. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From wusel+ml at uu.org Mon Feb 18 12:53:27 2019 From: wusel+ml at uu.org (Kai 'wusel' Siering) Date: Mon, 18 Feb 2019 12:53:27 +0100 Subject: [address-policy-wg] 2019-02 New Policy Proposal (Reducing IPv4 Allocations to a /24) In-Reply-To: References: <94aafe96-dd1b-45de-8034-6ec3e23d696c@www.fastmail.com> Message-ID: <01ad4f1b-05d6-fdc1-9017-908d1e2d7730@uu.org> Moin, am 08.02.2019 um 17:24 schrieb Nikolas Pediaditis: > Following your questions, I have some numbers and other information that might be useful. > > 1. Currently, there will be 977,408 IPv4 addresses remaining in our free pool once we are no longer able to allocate contiguous /22s. This number excludes prefixes that are smaller than a /24 and those prefixes that have been reserved for IXP assignments or temporary assignments. It might also be slightly larger by then, due to addresses that are recovered in the meantime. > > 2. Over the past three years, we have recovered the following amounts of IPv4 addresses: > > 2016: 83,712 > 2017: 106,368 > 2018: 53,824 Thank you, Nikolas, for the figures. So we're still talking about ~3.8k _new_ LIRs that end up with a /22 worth of addresses in /24s or /23s before 2019-02 would kick in and prolongate the infirmity of IPv4. 3.8k new LIRs that happily can consider starting a business based on IPv4, a legacy technology, and ignore the facts. As Carlos Fria?as pointed out on 08.02.2019 at 09:15: > The core purpose of 2019-02 is to allow (more) newcomers to access a tiny bit of IPv4 address space so their (hopefully IPv6-enabled) infrastructure will have path to the IPv4-only world (without going to the market). Let's put this into perspective: "I see 757979 IPv4 prefixes. This is 238 fewer prefixes than 6 hours ago and 1051 more than a week ago. 57.04% of prefixes are /24. There are 63602 unique originating ASNs. 47266 of these ASNs originate IPv4 only" (Source: https://twitter.com/bgp4_table/status/1097420515206152192) With still about 75% ASNs being IPv4 only, there's definitively no point in prolonging the availability of fresh IPv4 space by reducing the hand-out rate. "IPv4 is over", I hear ? so let's be brave and stick to that statement. Regards, -kai From ripe at liopen.fr Mon Feb 18 13:04:52 2019 From: ripe at liopen.fr (Denis Fondras) Date: Mon, 18 Feb 2019 13:04:52 +0100 Subject: [address-policy-wg] 2019-02 New Policy Proposal (Reducing IPv4 Allocations to a /24) In-Reply-To: <01ad4f1b-05d6-fdc1-9017-908d1e2d7730@uu.org> References: <94aafe96-dd1b-45de-8034-6ec3e23d696c@www.fastmail.com> <01ad4f1b-05d6-fdc1-9017-908d1e2d7730@uu.org> Message-ID: <20190218120452.GD71932@carcass.ledeuns.net> On Mon, Feb 18, 2019 at 12:53:27PM +0100, Kai 'wusel' Siering wrote: > 3.8k new LIRs that happily can consider starting a business > based on IPv4, a legacy technology, and ignore the facts. > I find this unfair. This is not "starters" who are ignoring the fact but those already in business (I look at you AWS among many hosters and ISP). Starters are only requesting IPv4 to reach ~80% of the Internet. Denis From hunekm at gmail.com Mon Feb 18 23:59:48 2019 From: hunekm at gmail.com (Martin =?utf-8?B?SHVuxJtr?=) Date: Mon, 18 Feb 2019 23:59:48 +0100 Subject: [address-policy-wg] 2019-02 New Policy Proposal (Reducing IPv4 Allocations to a /24) In-Reply-To: <20190218120452.GD71932@carcass.ledeuns.net> References: <01ad4f1b-05d6-fdc1-9017-908d1e2d7730@uu.org> <20190218120452.GD71932@carcass.ledeuns.net> Message-ID: <8714037.5aXe0z89oL@hunator-ntb.local> Hi Denis, Do you think that most of those "new" LIRs are in fact a new players? As long as we are allowed to transfer those addresses, we cannot be sure about that. Also life isn't fair. There are LIRs with large legacy IPv4 blocks, which could sustain a few dosents LIRs in current policy, but hay, that's the way it is. They got their pools fairly/legaly as well as we are getting it now. Other way of looking at it would be that we all should have possibility to get a same oportunity to get a large pool. But in that case it would be unfair to have 185/8 policy and we would have reached total depletion long time ago. So what is really fair and what is not? Unability to getting IPv4 from RIPE doesn't mean unability to get IPv4 conectivity. But it push the new player to start with IPv6 and get the v4 as a service. It would make v4 as something extra what you are forced to pay extra, perfect mindset to abadon it eventually. So once again, a faster we run out of IPv4 - a better. Martin Dne pond?l? 18. ?nora 2019 13:04:52 CET, Denis Fondras napsal(a): > On Mon, Feb 18, 2019 at 12:53:27PM +0100, Kai 'wusel' Siering wrote: > > 3.8k new LIRs that happily can consider starting a business > > based on IPv4, a legacy technology, and ignore the facts. > > I find this unfair. This is not "starters" who are ignoring the fact but > those already in business (I look at you AWS among many hosters and ISP). > Starters are only requesting IPv4 to reach ~80% of the Internet. > > Denis -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: This is a digitally signed message part. URL: From ripe at liopen.fr Tue Feb 19 08:34:53 2019 From: ripe at liopen.fr (Denis Fondras) Date: Tue, 19 Feb 2019 08:34:53 +0100 Subject: [address-policy-wg] 2019-02 New Policy Proposal (Reducing IPv4 Allocations to a /24) In-Reply-To: <8714037.5aXe0z89oL@hunator-ntb.local> References: <01ad4f1b-05d6-fdc1-9017-908d1e2d7730@uu.org> <20190218120452.GD71932@carcass.ledeuns.net> <8714037.5aXe0z89oL@hunator-ntb.local> Message-ID: <20190219073453.GF71932@carcass.ledeuns.net> Martin, > Do you think that most of those "new" LIRs are in fact a new players? As long > as we are allowed to transfer those addresses, we cannot be sure about that. > These "new LIRs" I consider "already in business", they do not fall into the category I was discussing. > Also life isn't fair. There are LIRs with large legacy IPv4 blocks, which > could sustain a few dosents LIRs in current policy, but hay, that's the way it > is. They got their pools fairly/legaly as well as we are getting it now. > What I called "unfair" was the assumption that "real" new players were happy with starting (and maintaining) a legacy IPv4 network today. Sorry if I was not clear. > Unability to getting IPv4 from RIPE doesn't mean unability to get IPv4 > conectivity. > I agree. Denis From cfriacas at fccn.pt Tue Feb 19 09:07:35 2019 From: cfriacas at fccn.pt (=?ISO-8859-15?Q?Carlos_Fria=E7as?=) Date: Tue, 19 Feb 2019 08:07:35 +0000 (WET) Subject: [address-policy-wg] 2019-02 New Policy Proposal (Reducing IPv4 Allocations to a /24) In-Reply-To: <8714037.5aXe0z89oL@hunator-ntb.local> References: <01ad4f1b-05d6-fdc1-9017-908d1e2d7730@uu.org> <20190218120452.GD71932@carcass.ledeuns.net> <8714037.5aXe0z89oL@hunator-ntb.local> Message-ID: Hello, On Mon, 18 Feb 2019, Martin Hun?k wrote: (...) > Unability to getting IPv4 from RIPE doesn't mean unability to get IPv4 > conectivity. Nor (some) IPv4 addresses, which can be obtained from "the market". > But it push the new player to start with IPv6 and get the v4 as a > service. Please go back and read why "You must deploy IPv6 in order to receive IPv4" (unfortunately) didn't stick... > It would make v4 as something extra what you are forced to pay extra, > perfect mindset to abadon it eventually. Nice plan, but there is just a very tiny detail... 75%-80% of the Internet is IPv4-only. > So once again, a faster we run out of IPv4 - a better. We have "run out of IPv4" (in a context of Internet's growth) since some years now... but people are still able to use it, and a lot of people/companies are NOT deploying IPv6 because they don't *need* it today. RIPE NCC's available IPv4 pool will not be empty everytime (addresses are de-registered by lack of payment, closures, ...), so a complete and *permanent* "run out of IPv4" is highly unlikely. > Martin Best Regards, Carlos From dominik at clouvider.co.uk Tue Feb 19 09:15:31 2019 From: dominik at clouvider.co.uk (Dominik Nowacki) Date: Tue, 19 Feb 2019 08:15:31 +0000 Subject: [address-policy-wg] 2019-02 New Policy Proposal (Reducing IPv4 Allocations to a /24) In-Reply-To: References: <01ad4f1b-05d6-fdc1-9017-908d1e2d7730@uu.org> <20190218120452.GD71932@carcass.ledeuns.net> <8714037.5aXe0z89oL@hunator-ntb.local>, Message-ID: <4F77E28E-F45E-45CE-924E-8B4EC28FB1C4@clouvider.co.uk> Dear Colleagues, We do not support this proposal. RIPE NCC's available IPv4 pool will not be empty everytime (addresses are de-registered by lack of payment, closures, ...), so a complete and *permanent* "run out of IPv4" is highly unlikely. ARIN style never-ending queue that basically means you will never get the addressees you request at this stage is synonymous with a complete and permanent run out of IPv4 to me. You can also observed that, for example, US where they observe a ?complete and permanent run out of IPv4? has more IPv6 traffic, according to Google, already than say UK where the national ISP, BT, and majority of alternative ISP supports IPv6 for ages already, out of the box. No access to V4 - better incentive to have eyeballs on V6 (and granted, some CGNAT probably too). More eyeballs on V6 makes an incentive for content providers to make more services available on V6. That?s my take on it. With Kind Regards, Dominik Nowacki Clouvider Limited is a limited company registered in England and Wales. Registered number: 08750969. Registered office: 88 Wood Street, London, United Kingdom, EC2V 7RS. On 19 Feb 2019, at 08:08, Carlos Fria?as via address-policy-wg > wrote: RIPE NCC's available IPv4 pool will not be empty everytime (addresses are de-registered by lack of payment, closures, ...), so a complete and *permanent* "run out of IPv4" is highly unlikely. -------------- next part -------------- An HTML attachment was scrubbed... URL: From cfriacas at fccn.pt Tue Feb 19 09:36:25 2019 From: cfriacas at fccn.pt (=?ISO-8859-15?Q?Carlos_Fria=E7as?=) Date: Tue, 19 Feb 2019 08:36:25 +0000 (WET) Subject: [address-policy-wg] 2019-02 New Policy Proposal (Reducing IPv4 Allocations to a /24) In-Reply-To: <4F77E28E-F45E-45CE-924E-8B4EC28FB1C4@clouvider.co.uk> References: <01ad4f1b-05d6-fdc1-9017-908d1e2d7730@uu.org> <20190218120452.GD71932@carcass.ledeuns.net> <8714037.5aXe0z89oL@hunator-ntb.local>, <4F77E28E-F45E-45CE-924E-8B4EC28FB1C4@clouvider.co.uk> Message-ID: Hi, On Tue, 19 Feb 2019, Dominik Nowacki wrote: > Dear Colleagues, We do not support this proposal. > > RIPE NCC's available IPv4 pool will not be empty everytime (addresses are de-registered by lack of payment, > closures, ...), so a complete and *permanent* "run out of IPv4" is highly unlikely. > > > ARIN style never-ending queue that basically means you will never get the addressees you request at this stage is synonymous > with a complete and permanent run out of IPv4 to me. That's what 2019-02 is about: We're in scarcity-mode since 2012. "What you request" and "What you need" are completely irrelevant. When the pool reaches 0 for the 1st time, people will still get /22s *when* some addresses are made available. Changing that into /24s will allow more people to get a minimum of IPv4 eventually at some point (smaller lifeboats, but 4x more lifeboats...) When the *need* for a /24 arises, and a company is still in a bad queue position, the answer is obvious: get it from the market! It would be really easy if IPv6 deployment would solve it, but one is only able to control one's infrastructure, there is absolutely no ability in dictacting what (and if when) 3rd party networks are going to deploy. That depends on their judgement and of course, budget :-) > You can also observed that, for example, US where they observe a > ?complete and permanent run out of IPv4? has more IPv6 traffic, > according to Google, already than say UK where the national ISP, BT, and > majority of alternative ISP supports IPv6 for ages already, out of the > box. It's not only traffic volume that matters. The number of networks and how much IPv6 is within each network is also very important. > No access to V4 - better incentive to have eyeballs on V6 (and granted, > some CGNAT probably too). We might not like CGNAT, but noone can stop anybody to use it... :/ > More eyeballs on V6 makes an incentive for > content providers to make more services available on V6. As i see it, content is the easy bit... Regards, Carlos > That?s my take on it. > > With Kind Regards,? > Dominik Nowacki? > ? > Clouvider Limited is a limited company registered in England and Wales. Registered number:?08750969. Registered office:?88 > Wood Street, London, United Kingdom, EC2V 7RS.? > > On 19 Feb 2019, at 08:08, Carlos Fria?as via address-policy-wg wrote: > > RIPE NCC's available IPv4 pool will not be empty everytime (addresses are de-registered by lack of payment, > closures, ...), so a complete and *permanent* "run out of IPv4" is highly unlikely. > > > From ripe-wgs at radu-adrian.feurdean.net Sat Feb 23 10:36:14 2019 From: ripe-wgs at radu-adrian.feurdean.net (Radu-Adrian FEURDEAN) Date: Sat, 23 Feb 2019 04:36:14 -0500 Subject: [address-policy-wg] =?utf-8?q?2019-02_New_Policy_Proposal_=28Red?= =?utf-8?q?ucing_IPv4_Allocations_to_a_/24=29?= In-Reply-To: References: <94aafe96-dd1b-45de-8034-6ec3e23d696c@www.fastmail.com> Message-ID: <5ca3143e-e609-4941-93f1-b1009cfa3ecf@www.fastmail.com> On Fri, Feb 8, 2019, at 17:24, Nikolas Pediaditis wrote: > Dear Carlos, Radu-Adrian, all, > > Following your questions, I have some numbers and other information > that might be useful. Hello and thanks for the rapid response. > 1. Currently, there will be 977,408 IPv4 addresses remaining in our > free pool once we are no longer able to allocate contiguous /22s. This Wow ! that's HUGE ! Under current conditions (equivalent on a /22 allocated at once, between 80 and 100 allocations per week) that would last about 10 weeks/2 months. With the new policy, that would be transformed to 40 weeks/9 months, not counting the almost certain decrease in the LIR creation rate. These numbers are turning me against the proposal the way it is right now. I will find welcome any changes that may help reduce the delay. Maybe the impact analysis will bring a little light. > 2. Over the past three years, we have recovered the following amounts > of IPv4 addresses: > > 2016: 83,712 > 2017: 106,368 > 2018: 53,824 OK, not really important for this matter. 1 week of allocation for a "good year" (like 2017). > 3. We have assigned the following amounts of IPv4 addresses as > temporary assignments over the past three years: > > 2016: 205,568 > 2017: 188,928 > 2018: 162,048 > > (Note that these figures represent the sum of all temporary assignments > made in that year.) So for the last 3 years, a /14 would have been (more than) enough. Probably mixing pools or exchanging blocks between the pools would help avoid reduce the delay of "IPv4 availability". Is a polycy needed for that or is it just NCC internal housekeeping? > Temporary assignments are made from a /13 that has been reserved for > this purpose. When a temporary assignment is returned, it is added back > to this pool. > > Finally, I would like to clarify that IPv4 allocations and temporary > assignments come from two separate pools - neither influences the other. > > I hope this helps. It certainly did. -- Radu-Adrian FEURDEAN From me at cynthia.re Tue Feb 26 23:00:33 2019 From: me at cynthia.re (=?UTF-8?Q?Cynthia_Revstr=c3=b6m?=) Date: Tue, 26 Feb 2019 23:00:33 +0100 Subject: [address-policy-wg] IPv6 PI justification requirements Message-ID: Hello ap-wg, I am in the process of requesting 3x /48 of IPv6 PI for a customer, and what confuses me is that the NCC requires way more justification for 3x /48 of PI than for 2x /29 of PA. I do think that saying something like net1 will be used in the Netherlands, net2 in London, and net3 in New York should be enough. I mean after all, any LIR can get 512K /48s and unlike ASNs, PI space does have a small fee attached with it. I can't think of a good reason why this is the case. Once again to make it clear, if you are a member it is easier to get 1 million /48s than it is for a non member to get 3 /48s. - Cynthia From me at cynthia.re Tue Feb 26 23:13:37 2019 From: me at cynthia.re (=?UTF-8?Q?Cynthia_Revstr=c3=b6m?=) Date: Tue, 26 Feb 2019 23:13:37 +0100 Subject: [address-policy-wg] IPv6 PI justification requirements In-Reply-To: References: Message-ID: I just want to clarify, that the NCC wanted documentation in the form of an addressing plan (over time?) and why PA space would not work. Now I do also want to clarify that I have already told them that the reason for this is that they have multiple physical locations with servers and they want PI for their infrastructure so it is their resources and not the provider's. I have also been informed that this might be a rather unique case in regards to having multiple physical locations requiring PI space. - Cynthia On 2019-02-26 23:00, Cynthia Revstr?m wrote: > Hello ap-wg, > > I am in the process of requesting 3x /48 of IPv6 PI for a customer, > and what confuses me is that the NCC requires way more justification > for 3x /48 of PI than for 2x /29 of PA. > > I do think that saying something like net1 will be used in the > Netherlands, net2 in London, and net3 in New York should be enough. I > mean after all, any LIR can get 512K /48s and unlike ASNs, PI space > does have a small fee attached with it. > > I can't think of a good reason why this is the case. > > Once again to make it clear, if you are a member it is easier to get 1 > million /48s than it is for a non member to get 3 /48s. > > - Cynthia > > From sander at steffann.nl Tue Feb 26 23:14:24 2019 From: sander at steffann.nl (Sander Steffann) Date: Tue, 26 Feb 2019 23:14:24 +0100 Subject: [address-policy-wg] IPv6 PI justification requirements In-Reply-To: References: Message-ID: <6AC31E5C-365F-4ED5-B6F9-7B84DDFD9D8A@steffann.nl> Hi Cynthia, > I am in the process of requesting 3x /48 of IPv6 PI for a customer, and what confuses me is that the NCC requires way more justification for 3x /48 of PI than for 2x /29 of PA. > > I do think that saying something like net1 will be used in the Netherlands, net2 in London, and net3 in New York should be enough. I mean after all, any LIR can get 512K /48s and unlike ASNs, PI space does have a small fee attached with it. > > I can't think of a good reason why this is the case. The policy says: """ The minimum size of the assignment is a /48. Organisations requesting a larger assignment (shorter prefix) must provide documentation justifying the need for additional subnets. Additional assignments may also be made when the need is demonstrated and documented based on address usage, or because different routing requirements exist for additional assignments. """ Your case seems to fit the "different routing requirements" rule. I would ask the NCC why they think that rule doesn't apply. They may have a reason. Without further data I can't judge their decision. > Once again to make it clear, if you are a member it is easier to get 1 million /48s than it is for a non member to get 3 /48s. Aggregatable addresses are indeed strongly preferred :) Cheers, Sander -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: Message signed with OpenPGP URL: From sander at steffann.nl Tue Feb 26 23:20:19 2019 From: sander at steffann.nl (Sander Steffann) Date: Tue, 26 Feb 2019 23:20:19 +0100 Subject: [address-policy-wg] IPv6 PI justification requirements In-Reply-To: References: Message-ID: <3977FE91-11E5-4B00-9F99-B7B23D7DF80D@steffann.nl> Hi Cynthia, > I have also been informed that this might be a rather unique case in regards to having multiple physical locations requiring PI space. Not unique at all. That is why the explicit "different routing requirements" rule was included in the policy :) Cheers, Sander -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: Message signed with OpenPGP URL: From wusel+ml at uu.org Wed Feb 27 02:09:18 2019 From: wusel+ml at uu.org (Kai 'wusel' Siering) Date: Wed, 27 Feb 2019 02:09:18 +0100 Subject: [address-policy-wg] IPv6 PI justification requirements In-Reply-To: References: Message-ID: Am 26.02.2019 um 23:13 schrieb Cynthia Revstr?m: > I have also been informed that this might be a rather unique case in regards to having multiple physical locations requiring PI space. It's not ? been there myself, and got really annoyed by the way the NCC entered spanish-inquisition-mode (like asking for physical location of DCs used, IMHO NOTB, and upstream mail contacts, again NOTB). That was pre-GDPR, these days I'd follow up with "provide legal statement under GDPR that allows you to ask this question, and process any answer". Hrmpft. -kai From jim at rfc1035.com Wed Feb 27 04:27:11 2019 From: jim at rfc1035.com (Jim Reid) Date: Wed, 27 Feb 2019 03:27:11 +0000 Subject: [address-policy-wg] IPv6 PI justification requirements In-Reply-To: References: Message-ID: <8E734284-7F9C-416D-9434-5A03CBCF73D9@rfc1035.com> > On 27 Feb 2019, at 01:09, Kai 'wusel' Siering wrote: > > I .... got really annoyed by the way the NCC entered spanish-inquisition-mode I would have hoped that went away along with the dregs of v4. From cfriacas at fccn.pt Wed Feb 27 08:30:13 2019 From: cfriacas at fccn.pt (=?ISO-8859-15?Q?Carlos_Fria=E7as?=) Date: Wed, 27 Feb 2019 07:30:13 +0000 (WET) Subject: [address-policy-wg] IPv6 PI justification requirements In-Reply-To: References: Message-ID: On Wed, 27 Feb 2019, Kai 'wusel' Siering wrote: > Am 26.02.2019 um 23:13 schrieb Cynthia Revstr?m: >> I have also been informed that this might be a rather unique case in regards to having multiple physical locations requiring PI space. > > It's not ? been there myself, and got really annoyed by the way the NCC > entered spanish-inquisition-mode (like asking for physical location of > DCs used, IMHO NOTB, and upstream mail contacts, again NOTB). That was > pre-GDPR, these days I'd follow up with "provide legal statement under > GDPR that allows you to ask this question, and process any answer". > Hrmpft. Hi, I fail to understand how a DC location could in any way be related to a GDPR violation. I also don't understand how asking for upstream mail contacts (i.e. professional ones, that any ASN should in theory have published, role or individual shouldn't make a difference) can violate GDPR. I guess "purpose" for asking is quite easy to understand -- checking if an upstream really exists at that point in time, which may be part of the process. Cheers, Carlos > -kai > > > From dominik at clouvider.co.uk Wed Feb 27 08:36:32 2019 From: dominik at clouvider.co.uk (Dominik Nowacki) Date: Wed, 27 Feb 2019 07:36:32 +0000 Subject: [address-policy-wg] IPv6 PI justification requirements In-Reply-To: References: , Message-ID: <6DB98C90-BBE2-42C0-A2FF-52BFE423DDDB@clouvider.co.uk> Dear colleagues, I also see nothing wrong with it. A /29 PA allocation is given to a registry for the purpose of re-assigning and use within the policy. End user however is expected to need a /48 PI for multihoming as that?s minimum routable. If someone requires more, I?m more than happy for RIPE to run through checks on any such request, so long as they comply with the policy. I?ve seen enough attempts to send SPAM through large quantities of V6 or to try to circumvent other limitations by attempt to use a large number of IPv6 to know that it is abused, and I appreciate every effort to weed illegitimate cases out by the NCC for the good of the Internet. With Kind Regards, Dominik Nowacki Clouvider Limited is a limited company registered in England and Wales. Registered number: 08750969. Registered office: 88 Wood Street, London, United Kingdom, EC2V 7RS. On 27 Feb 2019, at 07:30, Carlos Fria?as via address-policy-wg > wrote: On Wed, 27 Feb 2019, Kai 'wusel' Siering wrote: Am 26.02.2019 um 23:13 schrieb Cynthia Revstr?m: I have also been informed that this might be a rather unique case in regards to having multiple physical locations requiring PI space. It's not ? been there myself, and got really annoyed by the way the NCC entered spanish-inquisition-mode (like asking for physical location of DCs used, IMHO NOTB, and upstream mail contacts, again NOTB). That was pre-GDPR, these days I'd follow up with "provide legal statement under GDPR that allows you to ask this question, and process any answer". Hrmpft. Hi, I fail to understand how a DC location could in any way be related to a GDPR violation. I also don't understand how asking for upstream mail contacts (i.e. professional ones, that any ASN should in theory have published, role or individual shouldn't make a difference) can violate GDPR. I guess "purpose" for asking is quite easy to understand -- checking if an upstream really exists at that point in time, which may be part of the process. Cheers, Carlos -kai -------------- next part -------------- An HTML attachment was scrubbed... URL: From ganchev at fixity.net Wed Feb 27 09:47:04 2019 From: ganchev at fixity.net (Krasimir Ganchev) Date: Wed, 27 Feb 2019 08:47:04 +0000 Subject: [address-policy-wg] IPv6 PI justification requirements In-Reply-To: <6AC31E5C-365F-4ED5-B6F9-7B84DDFD9D8A@steffann.nl> References: <6AC31E5C-365F-4ED5-B6F9-7B84DDFD9D8A@steffann.nl> Message-ID: Hi folks, I couldn't agree more with Cynthia, policies are too strict and require justification which doesn't allow expansion over time and is just based on immediate needs. All that especially in the era of exhausted IPv4 is practically unbelievable. No offense of course, just the reality. Best, Krasimir -----Original Message----- From: address-policy-wg [mailto:address-policy-wg-bounces at ripe.net] On Behalf Of Sander Steffann Sent: Tuesday, February 26, 2019 2:14 PM To: Cynthia Revstr?m Cc: address-policy-wg at ripe.net Subject: Re: [address-policy-wg] IPv6 PI justification requirements Hi Cynthia, > I am in the process of requesting 3x /48 of IPv6 PI for a customer, and what confuses me is that the NCC requires way more justification for 3x /48 of PI than for 2x /29 of PA. > > I do think that saying something like net1 will be used in the Netherlands, net2 in London, and net3 in New York should be enough. I mean after all, any LIR can get 512K /48s and unlike ASNs, PI space does have a small fee attached with it. > > I can't think of a good reason why this is the case. The policy says: """ The minimum size of the assignment is a /48. Organisations requesting a larger assignment (shorter prefix) must provide documentation justifying the need for additional subnets. Additional assignments may also be made when the need is demonstrated and documented based on address usage, or because different routing requirements exist for additional assignments. """ Your case seems to fit the "different routing requirements" rule. I would ask the NCC why they think that rule doesn't apply. They may have a reason. Without further data I can't judge their decision. > Once again to make it clear, if you are a member it is easier to get 1 million /48s than it is for a non member to get 3 /48s. Aggregatable addresses are indeed strongly preferred :) Cheers, Sander From gert at space.net Wed Feb 27 11:05:05 2019 From: gert at space.net (Gert Doering) Date: Wed, 27 Feb 2019 11:05:05 +0100 Subject: [address-policy-wg] IPv6 PI justification requirements In-Reply-To: References: <6AC31E5C-365F-4ED5-B6F9-7B84DDFD9D8A@steffann.nl> Message-ID: <20190227100504.GS71606@Space.Net> Hi, On Wed, Feb 27, 2019 at 08:47:04AM +0000, Krasimir Ganchev via address-policy-wg wrote: > I couldn't agree more with Cynthia, policies are too strict and require justification which doesn't allow expansion over time and is just based on immediate needs. > > All that especially in the era of exhausted IPv4 is practically unbelievable. > > No offense of course, just the reality. This claim is just not true. There might be some cases where expectations and grandeur plans do not match reality, and in this cases it's reasonable that the NCC is strict and will not hand out a /19 to someone who can fulfill all their expected needs with a /32. There are other cases where the NCC is asking lots of questions, and maybe there are cases where the NCC is too strict. So we need to talk about these and see if it's "lack of reasonable documentation on the user side" or "annoying interpretation on the NCC side". OTOH, a /48 for an end-user site or a /29 for an ISP is pretty huge (we have not even extended our /32 to a /29 as we assume that we will never manage to fill the /32) - and documented reality shows that *if* you need more, you can get it today. Gert Doering -- APWG chair, and IPv6 user from day one, where the policies were *much* stricter than today -- 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 Wed Feb 27 11:08:11 2019 From: me at cynthia.re (=?UTF-8?Q?Cynthia_Revstr=c3=b6m?=) Date: Wed, 27 Feb 2019 11:08:11 +0100 Subject: [address-policy-wg] IPv6 PI justification requirements In-Reply-To: <20190227100504.GS71606@Space.Net> References: <6AC31E5C-365F-4ED5-B6F9-7B84DDFD9D8A@steffann.nl> <20190227100504.GS71606@Space.Net> Message-ID: <3bdc2d6a-8aa6-5dc6-45da-9b35caca6bb9@cynthia.re> Hi Gert, As I attempted to explain this was 3 separate uses that required separate announcements. - Cynthia On 2019-02-27 11:05, Gert Doering wrote: > Hi, > > On Wed, Feb 27, 2019 at 08:47:04AM +0000, Krasimir Ganchev via address-policy-wg wrote: >> I couldn't agree more with Cynthia, policies are too strict and require justification which doesn't allow expansion over time and is just based on immediate needs. >> >> All that especially in the era of exhausted IPv4 is practically unbelievable. >> >> No offense of course, just the reality. > This claim is just not true. > > There might be some cases where expectations and grandeur plans do not > match reality, and in this cases it's reasonable that the NCC is strict > and will not hand out a /19 to someone who can fulfill all their expected > needs with a /32. > > There are other cases where the NCC is asking lots of questions, and maybe > there are cases where the NCC is too strict. So we need to talk about these > and see if it's "lack of reasonable documentation on the user side" or > "annoying interpretation on the NCC side". > > OTOH, a /48 for an end-user site or a /29 for an ISP is pretty huge > (we have not even extended our /32 to a /29 as we assume that we will > never manage to fill the /32) - and documented reality shows that *if* > you need more, you can get it today. > > Gert Doering > -- APWG chair, and IPv6 user from day one, where the policies were > *much* stricter than today From ganchev at fixity.net Wed Feb 27 11:29:04 2019 From: ganchev at fixity.net (Krasimir Ganchev) Date: Wed, 27 Feb 2019 10:29:04 +0000 Subject: [address-policy-wg] IPv6 PI justification requirements In-Reply-To: <20190227100504.GS71606@Space.Net> References: <6AC31E5C-365F-4ED5-B6F9-7B84DDFD9D8A@steffann.nl> <20190227100504.GS71606@Space.Net> Message-ID: Hi Gert, I understand there should be rules. And I am totally for having meaningful rules and those rules to be followed. It is just that from my own personal experience and the shared experience of people I worked with in my network there are sometimes complications with requesting meaningful space for small business with multiple sites planning for additional sites in the near year or two. On your remark about /48 being pretty huge, I do agree it is huge, but unfortunately it is still the case that a /48 is the norm and upstreams would filter smaller prefixes. As per /32 vs /19 I also agree, /32 is more than enough for almost any needs. What I am trying to say is that sometimes people struggle getting the space they need and the one they planned for in future aggregated because they have no immediate needs. You are right, if there is immediate need they will always get it. Best, Krasimir -----Original Message----- From: Gert Doering [mailto:gert at space.net] Sent: Wednesday, February 27, 2019 2:05 AM To: Krasimir Ganchev Cc: Sander Steffann ; Cynthia Revstr?m ; address-policy-wg at ripe.net Subject: Re: [address-policy-wg] IPv6 PI justification requirements Hi, On Wed, Feb 27, 2019 at 08:47:04AM +0000, Krasimir Ganchev via address-policy-wg wrote: > I couldn't agree more with Cynthia, policies are too strict and require justification which doesn't allow expansion over time and is just based on immediate needs. > > All that especially in the era of exhausted IPv4 is practically unbelievable. > > No offense of course, just the reality. This claim is just not true. There might be some cases where expectations and grandeur plans do not match reality, and in this cases it's reasonable that the NCC is strict and will not hand out a /19 to someone who can fulfill all their expected needs with a /32. There are other cases where the NCC is asking lots of questions, and maybe there are cases where the NCC is too strict. So we need to talk about these and see if it's "lack of reasonable documentation on the user side" or "annoying interpretation on the NCC side". OTOH, a /48 for an end-user site or a /29 for an ISP is pretty huge (we have not even extended our /32 to a /29 as we assume that we will never manage to fill the /32) - and documented reality shows that *if* you need more, you can get it today. Gert Doering -- APWG chair, and IPv6 user from day one, where the policies were *much* stricter than today -- 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 Wed Feb 27 11:37:45 2019 From: gert at space.net (Gert Doering) Date: Wed, 27 Feb 2019 11:37:45 +0100 Subject: [address-policy-wg] IPv6 PI justification requirements In-Reply-To: <3bdc2d6a-8aa6-5dc6-45da-9b35caca6bb9@cynthia.re> References: <6AC31E5C-365F-4ED5-B6F9-7B84DDFD9D8A@steffann.nl> <20190227100504.GS71606@Space.Net> <3bdc2d6a-8aa6-5dc6-45da-9b35caca6bb9@cynthia.re> Message-ID: <20190227103745.GT71606@Space.Net> Hi, On Wed, Feb 27, 2019 at 11:08:11AM +0100, Cynthia Revstr?m wrote: > As I attempted to explain this was 3 separate uses that required > separate announcements. I'm not talking your particular case - just the generic statement "the policies are too strict". This is just not true if stated that broadly. As for the particular case, I think some comments from Marco are forthcoming. Gert Doering -- APWG chair -- 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 mschmidt at ripe.net Wed Feb 27 13:41:20 2019 From: mschmidt at ripe.net (Marco Schmidt) Date: Wed, 27 Feb 2019 13:41:20 +0100 Subject: [address-policy-wg] IPv6 PI justification requirements In-Reply-To: <3bdc2d6a-8aa6-5dc6-45da-9b35caca6bb9@cynthia.re> References: <6AC31E5C-365F-4ED5-B6F9-7B84DDFD9D8A@steffann.nl> <20190227100504.GS71606@Space.Net> <3bdc2d6a-8aa6-5dc6-45da-9b35caca6bb9@cynthia.re> Message-ID: <7ca66917-4ea2-3e5b-5bca-2ab495daf542@ripe.net> Dear Cynthia, Thank you for raising this topic. We are seeing more requests from organisations that want separate /48 PI assignments for different locations. We approve these requests if the policy requirements are met - primarily that their different routing requirements are documented. One of the best ways to do this is through an addressing plan. While I can't discuss the specifics of your case on the mailing list, I can state that it wasn't the physical locations that made your request unique. Feel free to contact me offline if you would like any further clarification around the policy requirements as they apply to your situation. It's also worth noting that if an LIR wants to request a second /29, they would need to provide justification in this case as well. Of course, there's always the option to propose a policy change if the current policy appears too strict or in need of improvement, and I am always available to help people get started with this. Kind regards, Marco Schmidt Policy Officer RIPE NCC On 27/02/2019 11:08, Cynthia Revstr?m wrote: > Hi Gert, > > As I attempted to explain this was 3 separate uses that required > separate announcements. > > - Cynthia > > On 2019-02-27 11:05, Gert Doering wrote: >> Hi, >> >> On Wed, Feb 27, 2019 at 08:47:04AM +0000, Krasimir Ganchev via >> address-policy-wg wrote: >>> I couldn't agree more with Cynthia, policies are too strict and >>> require justification which doesn't allow expansion over time and is >>> just based on immediate needs. >>> >>> All that especially in the era of exhausted IPv4 is practically >>> unbelievable. >>> >>> No offense of course, just the reality. >> This claim is just not true. >> >> There might be some cases where expectations and grandeur plans do not >> match reality, and in this cases it's reasonable that the NCC is strict >> and will not hand out a /19 to someone who can fulfill all their >> expected >> needs with a /32. >> >> There are other cases where the NCC is asking lots of questions, and >> maybe >> there are cases where the NCC is too strict.? So we need to talk >> about these >> and see if it's "lack of reasonable documentation on the user side" or >> "annoying interpretation on the NCC side". >> >> OTOH, a /48 for an end-user site or a /29 for an ISP is pretty huge >> (we have not even extended our /32 to a /29 as we assume that we will >> never manage to fill the /32) - and documented reality shows that *if* >> you need more, you can get it today. >> >> Gert Doering >> ???????? -- APWG chair, and IPv6 user from day one, where the >> policies were >> ??????????? *much* stricter than today > > From sander at steffann.nl Wed Feb 27 16:16:04 2019 From: sander at steffann.nl (Sander Steffann) Date: Wed, 27 Feb 2019 16:16:04 +0100 Subject: [address-policy-wg] IPv6 PI justification requirements In-Reply-To: <3bdc2d6a-8aa6-5dc6-45da-9b35caca6bb9@cynthia.re> References: <6AC31E5C-365F-4ED5-B6F9-7B84DDFD9D8A@steffann.nl> <20190227100504.GS71606@Space.Net> <3bdc2d6a-8aa6-5dc6-45da-9b35caca6bb9@cynthia.re> Message-ID: <77B9105D-F9C1-46CC-BF54-D5ACA13C6D0A@steffann.nl> Hi, > As I attempted to explain this was 3 separate uses that required separate announcements. To keep things more clear, maybe it's easier to send three separate requests. Each for a /48 with the description where/how that one is going to be used. Combining things into one request might seem easier, but it tends to obfuscate things :) Cheers, Sander -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: Message signed with OpenPGP URL: