From tjc at ecs.soton.ac.uk Mon Oct 2 10:50:31 2017 From: tjc at ecs.soton.ac.uk (Tim Chown) Date: Mon, 2 Oct 2017 09:50:31 +0100 Subject: [address-policy-wg] 2017-03 New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space) In-Reply-To: References: <2DC2825D-03CF-484B-AC3E-C578162F519F@ecs.soton.ac.uk> Message-ID: Hi Marco, > On 22 Sep 2017, at 15:55, Marco Schmidt wrote: > > Hello Tim, > > On 2017-09-22 15:39:01 CET, Tim Chown wrote: >> There?s an argument to track and follow policies implemented elsewhere, and keep in step with those. LACNIC has adopted /24 it seems, and ARIN have a /10 of IPv4 from which they can hand out /28 to /24. what are the current APNIC or AFRINIC policies? >> > > I am happy to provide some information here. > > In the AFRINIC region, in the final exhaustion phase, the minimum allocation/assignment size will be a /24, and the maximum will be a /22 per allocation/assignment. > https://www.afrinic.net/library/policies/1829-afrinic-consolidated-policy-manual#s5_4 > > In the APNIC region, the minimum allocation size for IPv4 is a /24. > Each APNIC account holder is eligible to receive IPv4 allocations totalling a maximum /22 from the APNIC 103/8 IPv4 address pool (Final /8 Block) and additional allocations up to a maximum of /22 address space from the APNIC non-103/8 IPv4 address pool. > https://www.apnic.net/community/policy/resources#Part-2:-IPv4-Policy > > I hope this clarifies your question. Many thanks. So my question would be whether as a community we have a goal to try to stay in sync with other RIR policies. Tim From noc at ntx.ru Fri Oct 6 19:21:53 2017 From: noc at ntx.ru (NTX NOC) Date: Fri, 6 Oct 2017 20:21:53 +0300 Subject: [address-policy-wg] 2017-03 New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space) In-Reply-To: References: Message-ID: Greetings! I Oppose this proposal. Minimum routing block is /24 and new LIR will be too difficult to build network in different locations. Most new LIR are small companies. For other half of the companies - they will have to route a lot of small block as 24, routing table will grow high. Nothing useful in this case. I wish this allocation should be greater, les say /21 as in apnic. If everybody force IPv6 - then better to distribute IPv4 and go to v6 With current rate of Ipv4 distribution ipv4 will be enough for many years. And we should take in mind that time to time RIPE get Ips back to reserve pool from the closed companies and etc. For people who always care about IPv4 reserved the answer is next - there big Ipv4 reserved space "for future use" according RFC, my opinion that people should look in that direction. I support it too. NTX NOC Yury Bogdanov On 21.09.2017 14:43, Marco Schmidt wrote: > Dear colleagues, > > A new RIPE Policy proposal, 2017-03, "Reducing Initial IPv4 Allocation, > aiming to preserve a minimum of IPv4 space", is now available for discussion. > > The goal of this proposal is to reduce the IPv4 allocations made by the RIPE NCC > to a /24 (currently a /22) and only to LIRs that have not received an IPv4 allocation > directly from the RIPE NCC before. > > You can find the full proposal at: > https://www.ripe.net/participate/policies/proposals/2017-03/ > > 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 RIPE Working Group Chairs, decides how to proceed with the proposal. > > We encourage you to review this proposal and send your comments to > before 20 October 2017. > > Kind regards, > > Marco Schmidt > Policy Development Officer > RIPE NCC > > Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum > From aleksbulgakov at gmail.com Fri Oct 6 22:01:12 2017 From: aleksbulgakov at gmail.com (Aleksey Bulgakov) Date: Fri, 6 Oct 2017 23:01:12 +0300 Subject: [address-policy-wg] 2017-03 New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space) In-Reply-To: References: Message-ID: Hi, all! I agree with Yury and oppose this proposal. It would be better to return unused allocations more than 24 months not from the last /8 pool. Many companies have /16, maybe more for free. 6 ??? 2017 ?. 20:22 ???????????? "NTX NOC" ???????: Greetings! I Oppose this proposal. Minimum routing block is /24 and new LIR will be too difficult to build network in different locations. Most new LIR are small companies. For other half of the companies - they will have to route a lot of small block as 24, routing table will grow high. Nothing useful in this case. I wish this allocation should be greater, les say /21 as in apnic. If everybody force IPv6 - then better to distribute IPv4 and go to v6 With current rate of Ipv4 distribution ipv4 will be enough for many years. And we should take in mind that time to time RIPE get Ips back to reserve pool from the closed companies and etc. For people who always care about IPv4 reserved the answer is next - there big Ipv4 reserved space "for future use" according RFC, my opinion that people should look in that direction. I support it too. NTX NOC Yury Bogdanov On 21.09.2017 14:43, Marco Schmidt wrote: > Dear colleagues, > > A new RIPE Policy proposal, 2017-03, "Reducing Initial IPv4 Allocation, > aiming to preserve a minimum of IPv4 space", is now available for discussion. > > The goal of this proposal is to reduce the IPv4 allocations made by the RIPE NCC > to a /24 (currently a /22) and only to LIRs that have not received an IPv4 allocation > directly from the RIPE NCC before. > > You can find the full proposal at: > https://www.ripe.net/participate/policies/proposals/2017-03/ > > 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 RIPE Working Group Chairs, decides how to proceed with the proposal. > > We encourage you to review this proposal and send your comments to > before 20 October 2017. > > Kind regards, > > Marco Schmidt > Policy Development Officer > RIPE NCC > > Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum > -------------- next part -------------- An HTML attachment was scrubbed... URL: From info at servereasy.it Fri Oct 6 23:46:27 2017 From: info at servereasy.it (Servereasy) Date: Fri, 6 Oct 2017 23:46:27 +0200 Subject: [address-policy-wg] 2017-03 New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space) In-Reply-To: References: Message-ID: <66d7e1b3-2408-e734-9f97-50d3d10adb49@servereasy.it> That is the problem: _for free_. A new LIR who owns a single /22 (current value: ?10k) pays as much as a LIR who owns a /12 (?10M for something that they paid about 0?). There are too many interest behind IPv4 deficiency. This is totally unfair. Simple as that. Il 06/10/2017 22:01, Aleksey Bulgakov ha scritto: > Hi, all! > > I agree with Yury and oppose this proposal. It would be better to > return unused allocations more than 24 months not from the last /8 > pool. Many companies have /16, maybe more *f**or free.* -------------- next part -------------- An HTML attachment was scrubbed... URL: From alex at vpsville.ru Sat Oct 7 02:11:15 2017 From: alex at vpsville.ru (Vpsville) Date: Sat, 07 Oct 2017 03:11:15 +0300 Subject: [address-policy-wg] 2017-03 New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space) In-Reply-To: References: Message-ID: <15ef42bf4b8.2795.ac52436aa45963449bf7a55c77017d57@vpsville.ru> Hi. Agreed with Yury. I oppose this proposal too. ?????????? ?? AquaMail ??? ???????? http://www.aqua-mail.com NTX NOC 6 ??????? 2017 ?. 8:23:00 ?? ???????: > Greetings! > > I Oppose this proposal. Minimum routing block is /24 and new LIR will be > too difficult to build network in different locations. Most new LIR are > small companies. For other half of the companies - they will have to > route a lot of small block as 24, routing table will grow high. > Nothing useful in this case. I wish this allocation should be greater, > les say /21 as in apnic. > > If everybody force IPv6 - then better to distribute IPv4 and go to v6 > With current rate of Ipv4 distribution ipv4 will be enough for many > years. And we should take in mind that time to time RIPE get Ips back to > reserve pool from the closed companies and etc. > > For people who always care about IPv4 reserved the answer is next - > there big Ipv4 reserved space "for future use" according RFC, my opinion > that people should look in that direction. I support it too. > > NTX NOC > Yury Bogdanov > > > > On 21.09.2017 14:43, Marco Schmidt wrote: >> Dear colleagues, >> >> A new RIPE Policy proposal, 2017-03, "Reducing Initial IPv4 Allocation, >> aiming to preserve a minimum of IPv4 space", is now available for discussion. >> >> The goal of this proposal is to reduce the IPv4 allocations made by the >> RIPE NCC >> to a /24 (currently a /22) and only to LIRs that have not received an IPv4 >> allocation >> directly from the RIPE NCC before. >> >> You can find the full proposal at: >> https://www.ripe.net/participate/policies/proposals/2017-03/ >> >> 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 RIPE Working Group Chairs, decides how to proceed with the proposal. >> >> We encourage you to review this proposal and send your comments to >> before 20 October 2017. >> >> Kind regards, >> >> Marco Schmidt >> Policy Development Officer >> RIPE NCC >> >> Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum >> > > From rgori at wirem.net Sat Oct 7 14:19:34 2017 From: rgori at wirem.net (Riccardo Gori) Date: Sat, 7 Oct 2017 14:19:34 +0200 Subject: [address-policy-wg] 2017-03 New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space) In-Reply-To: References: Message-ID: Hi Carlos, sorry for the late reply I was out for work. I'll reply only to your question "> Fix IPv6 rate adoption by policy? " Carlos, this policy proposal aims to fix IPv4 rate depletion... so why don't use a policy for "rate adoption"? do you see any difference? Rest is personal opinion and from my point of view any conservative policy will only last the pain longer. thank you regards Riccardo Il 24/09/2017 15:09, Carlos Fria?as ha scritto: > > Hi Riccardo, All, > > Thanks for your input. > > Please see inline. > > > On Sun, 24 Sep 2017, Riccardo Gori wrote: > >> Dear all, >> >> I started as an ISP early 2015 and I still consider myself a new >> entrant. > > That's not my definition for "new entrant". Strictly i consider a new > entrant as an organization which doesn't own any IPv4 or IPv6 address > space. Loosely, it can be a new LIR (before getting its /22 and an > IPv6 block under current policy)... > > But, luckly the community approved a policy for the last /8 long > before 2015. If that didn't happen, your only solution would have been > to rely on the market. > > >> In the last 2 years I heard about a couple of time "no more IPv4 >> policies let's go over and think how to fix/help IPv6 rate adoption" >> but today we are still here complaining what's the best way to last >> longer with the agony. > > Is "no more IPv4 policies" written in stone somewhere? :-) > > Fix IPv6 rate adoption by policy? > Let's call our countries' telecom regulators, and ask for a policy > that prohibits IPv4 usage from day X onwards? -- i don't think > so........... > > >> For Ipv6 RIPE NCC is doing its best with training and is really >> appreciated > > +1 on that! > > >> and I learned here that we tend to not mix IPv4/6 policies but I >> really expected incentives from the cummunity not obstacles. The >> "IPv6 Requirement for Receiving Space from the Final /8" was >> abandoned 23/10/2014 by the adoption of 2014-04 proposal > > Looking back now, was that a good decision...? > > >> while this 2017-03 proposal aims to last as longer as possible with >> IPv4. > > Should we tweak it, and make it more "stricter", in a way the address > space is (automatically?) returned if it's not being used in v4/v6 > translation mechanisms...? (and do we have means to check that?) > > > >> Looks to me that we are trying to save future generation from ice >> melting saving oil tanks instead of working on research and >> incentives to clean energies. > > Incentives cost money -- taxpayers' or consumers' money (or both!) > > >> I don't see even any reason to save more address space than the >> current policies does 'casue we have "trasfert policies" > > Transfers of last /8 slices are still allowed after 24 months -- > should that possibility end...? (2017-03 v1.0 doesn't address transfers) > > >> for almost any kind of IP resource and if there are some restrictions >> on new allocation there are more flexible for legacy space. > > The RIPE community (through the NCC) only provides services to legacy > space holders (and there was a proprosal for that... 2012-07). > The RIPE community is not able to design policies regarding address > space which was distributed before the NCC's creation. > > > >> Today you can simply choose to go RIPE or market as your feeling to >> get IPv4/6 if needed. > > If the choice is going to the "market" (and if you are in strict sense > a new entrant), the "market" will not advocate you should use/deploy > IPv6. > On the other hand, if the choice is becoming a LIR, you will get > that... :-) > > > >> My small router deals today with more than 2.5 million routes (2 full >> routing tables and some IX) and it really takes time to backup and >> even routing performance are affected by volume of routes. I think we >> should propote IPv6 for route aggregation ability. > > There is also de-aggregation in IPv6-land. :-( > (http://www.cidr-report.org/v6/as2.0/) > People will mess up routing as the rest of the world lets them... > > >> I see this policy as: >> - an obstacle to IPv6 > > That was not the goal. The goal was to extend v4 availability for some > more time, thus making life easier for IPv6 deployments that will > still need to talk with the v4 world. > > >> - a clear side effect of market price rise on IPv4 > > This proposal is not about the "market". a /24 can cost X, Y or Z over > time. The only way we can keep "affordability" for new entrants is by > defining what they get from the NCC, not from any 3rd party. > > > >> - a disincentive to route aggregation > > I don't agree. /22s (and bigger chunks) are already being announced as > /24s. What we consider is that keeping the "affordability" for new > entrants is a bigger priority than keeping the DFZ on 683k (today) > instead of 725k, 750k or even 800k routes. I know 800k routes looks > insane, but two years ago 683k would have been equally insane :-)) > > ps: On 24-09-2015 (two years ago), 572876 routes > https://web.archive.org/web/20150924225101/https://www.cidr-report.org/as2.0/ > > > > Thanks! > > > Best Regards, > Carlos Fria?as > > >> That's why I oppose this policy >> kind regards >> Riccardo >> >> -- >> Riccardo Gori >> -- Ing. Riccardo Gori e-mail: rgori at wirem.net Italia: +39 339 89 25 947 Espa?a: +34 660 11 59 89 Profile: https://it.linkedin.com/in/riccardo-gori-74201943 WIREM Fiber Revolution Net-IT s.r.l. Via Cesare Montanari, 2 47521 Cesena (FC) Tel +39 0547 1955485 Fax +39 0547 1950285 -------------------------------------------------------------------- CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please contact us by re- plying to info at wirem.net Thank you WIREM - Net-IT s.r.l.Via Cesare Montanari, 2 - 47521 Cesena (FC) -------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: From cfriacas at fccn.pt Sun Oct 8 10:19:02 2017 From: cfriacas at fccn.pt (=?ISO-8859-15?Q?Carlos_Fria=E7as?=) Date: Sun, 8 Oct 2017 09:19:02 +0100 (WEST) Subject: [address-policy-wg] 2017-03 New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space) In-Reply-To: References: Message-ID: On Sat, 7 Oct 2017, Riccardo Gori wrote: > Hi Carlos, Hi Riccardo, All, > sorry for the late reply I was out for work. > > I'll reply only to your question "> Fix IPv6 rate adoption by policy? " > Carlos, this policy proposal aims to fix IPv4 rate depletion... so why don't use a policy for "rate adoption"? do you see any difference? Yes, i see a clear difference. The RIPE community can approve/adopt a policy that has some impact on IPv4 rate depletion in the NCC's service Area. How can the RIPE community "enforce" adoption of any new technology? I really don't know. I would certainly prioritize that policy proposal if i had an answer to that question :-) If someone has an answer, i will contribute for such a proposal. Unfortunately, adoption is entirely different from depletion. Depletion is caused by high usage. The need to encourage the adoption of a technology results from low usage. > Rest is personal opinion and from my point of view any conservative > policy will only last the pain longer. Markets are already in place. The "pain" will survive the total exhaustion point in this region, unfortunately. And this is obviously a personal opinion, but you will also see an increased usage of CGN -- which 2017-03 also is NOT addressing. Thanks, Carlos > thank you > regards > Riccardo > > > > Il 24/09/2017 15:09, Carlos Fria?as ha scritto: > > Hi Riccardo, All, > > Thanks for your input. > > Please see inline. > > > On Sun, 24 Sep 2017, Riccardo Gori wrote: > > Dear all, > > I started as an ISP early 2015 and I still consider myself a new entrant. > > > That's not my definition for "new entrant". Strictly i consider a new entrant as an organization which doesn't own any IPv4 or IPv6 address space. > Loosely, it can be a new LIR (before getting its /22 and an IPv6 block under current policy)... > > But, luckly the community approved a policy for the last /8 long before 2015. If that didn't happen, your only solution would have been to rely on the > market. > > > In the last 2 years I heard about a couple of time "no more IPv4 policies let's go over and think how to fix/help IPv6 rate adoption" but > today we are still here complaining what's the best way to last longer with the agony. > > > Is "no more IPv4 policies" written in stone somewhere? :-) > > Fix IPv6 rate adoption by policy? > Let's call our countries' telecom regulators, and ask for a policy that prohibits IPv4 usage from day X onwards? -- i don't think so........... > > > For Ipv6 RIPE NCC is doing its best with training and is really appreciated > > > +1 on that! > > > and I learned here that we tend to not mix IPv4/6 policies but I really expected incentives from the cummunity not obstacles. The "IPv6 > Requirement for Receiving Space from the Final /8" was abandoned 23/10/2014 by the adoption of 2014-04 proposal > > > Looking back now, was that a good decision...? > > > while this 2017-03 proposal aims to last as longer as possible with IPv4. > > > Should we tweak it, and make it more "stricter", in a way the address space is (automatically?) returned if it's not being used in v4/v6 translation > mechanisms...? (and do we have means to check that?) > > > > Looks to me that we are trying to save future generation from ice melting saving oil tanks instead of working on research and incentives to > clean energies. > > > Incentives cost money -- taxpayers' or consumers' money (or both!) > > > I don't see even any reason to save more address space than the current policies does 'casue we have "trasfert policies" > > > Transfers of last /8 slices are still allowed after 24 months -- should that possibility end...? (2017-03 v1.0 doesn't address transfers) > > > for almost any kind of IP resource and if there are some restrictions on new allocation there are more flexible for legacy space. > > > The RIPE community (through the NCC) only provides services to legacy space holders (and there was a proprosal for that... 2012-07). > The RIPE community is not able to design policies regarding address space which was distributed before the NCC's creation. > > > > Today you can simply choose to go RIPE or market as your feeling to get IPv4/6 if needed. > > > If the choice is going to the "market" (and if you are in strict sense a new entrant), the "market" will not advocate you should use/deploy IPv6. > On the other hand, if the choice is becoming a LIR, you will get that... :-) > > > > My small router deals today with more than 2.5 million routes (2 full routing tables and some IX) and it really takes time to backup and > even routing performance are affected by volume of routes. I think we should propote IPv6 for route aggregation ability. > > > There is also de-aggregation in IPv6-land. :-( > (http://www.cidr-report.org/v6/as2.0/) > People will mess up routing as the rest of the world lets them... > > > I see this policy as: > - an obstacle to IPv6 > > > That was not the goal. The goal was to extend v4 availability for some more time, thus making life easier for IPv6 deployments that will still need to > talk with the v4 world. > > > - a clear side effect of market price rise on IPv4 > > > This proposal is not about the "market". a /24 can cost X, Y or Z over time. The only way we can keep "affordability" for new entrants is by defining > what they get from the NCC, not from any 3rd party. > > > > - a disincentive to route aggregation > > > I don't agree. /22s (and bigger chunks) are already being announced as /24s. What we consider is that keeping the "affordability" for new entrants is a > bigger priority than keeping the DFZ on 683k (today) instead of 725k, 750k or even 800k routes. I know 800k routes looks insane, but two years ago 683k > would have been equally insane :-)) > > ps: On 24-09-2015 (two years ago), 572876 routes > https://web.archive.org/web/20150924225101/https://www.cidr-report.org/as2.0/ > > > Thanks! > > > Best Regards, > Carlos Fria?as > > > That's why I oppose this policy > kind regards > Riccardo > > -- > Riccardo Gori > > > -- > > Ing. Riccardo Gori > e-mail: rgori at wirem.net > Italia: +39 339 89 25 947 > Espa?a: +34 660 11 59 89 > Profile: https://it.linkedin.com/in/riccardo-gori-74201943 > [logoWirem_4cm_conR.jpg] > > WIREM Fiber Revolution > Net-IT s.r.l. > Via Cesare Montanari, 2 > 47521 Cesena (FC) > Tel +39 0547 1955485 > Fax +39 0547 1950285 > > -------------------------------------------------------------------- > CONFIDENTIALITY NOTICE > This message and its attachments are addressed solely to the persons > above and may contain confidential information. If you have received > the message in error, be informed that any use of the content hereof > is prohibited. Please return it immediately to the sender and delete > the message. Should you have any questions, please contact us by re- > plying to info at wirem.net > Thank you > WIREM - Net-IT s.r.l.Via Cesare Montanari, 2 - 47521 Cesena (FC) > -------------------------------------------------------------------- > > From aleksbulgakov at gmail.com Thu Oct 19 14:46:21 2017 From: aleksbulgakov at gmail.com (Aleksey Bulgakov) Date: Thu, 19 Oct 2017 15:46:21 +0300 Subject: [address-policy-wg] Confusion In-Reply-To: References: Message-ID: Hi, all. As you can read here https://www.ripe.net/ripe/mail/archives/ncc- announce/2016-July/001066.html Transfer of resources between LIR accounts of the same member will fall under the transfer policy. This aligns the transfer of resources between LIR accounts of the same member with the transfer procedures the RIPE NCC applies to transfers between LIR accounts of different members. The transfer policy will now apply to all transfers, regardless of whether the transfer is between the same or different members. In practice, this means that the IPv4 allocation will only be transferable between LIR accounts of the same member after 24 months. But if you go to transfer policy, you can see the next This restriction does not prevent the resources from being transferred due to further mergers or acquisitions within the 24-month period. So, I see confusion between policies and executive board desision . -------------- next part -------------- An HTML attachment was scrubbed... URL: From d.baeza at tvt-datos.es Thu Oct 19 14:59:38 2017 From: d.baeza at tvt-datos.es (Daniel Baeza) Date: Thu, 19 Oct 2017 14:59:38 +0200 Subject: [address-policy-wg] Confusion In-Reply-To: References: Message-ID: Hi Aleksey, I think those are two different things, one being the transfer of a resource and a "merge or adquisition". If you buy a company that has a LIR and is between the 24 months period, you still can merge LIRs and have their resources in only one LIR. I hope to be rigth, but if anyone can confirm what Im saying... Regards, El 19/10/2017 a las 14:46, Aleksey Bulgakov escribi?: > Hi, all. > > As you can read here > https://www.ripe.net/ripe/mail/archives/ncc-announce/2016-July/001066.html > > > Transfer of resources between LIR accounts of the same member will > > fall under the transfer policy. > > This aligns the transfer of resources > between LIR accounts of the same > member with the transfer procedures > the RIPE NCC applies to transfers between LIR accounts of different > members. > > The transfer policy will now apply to all transfers, > regardless of > whether the transfer is between the same or different > members. > > In practice, this means that the IPv4 allocation will only be > > transferable between LIR accounts of the same member after 24 months. > > > But if you go to transfer policy, you can see the next > > This restriction does not prevent the resources from being transferred > due to further mergers or acquisitions within the 24-month period. > > So, I see confusion between policies and executive board desision > . From mschmidt at ripe.net Thu Oct 19 15:08:07 2017 From: mschmidt at ripe.net (Marco Schmidt) Date: Thu, 19 Oct 2017 15:08:07 +0200 Subject: [address-policy-wg] 2016-04 Review Phase (IPv6 Sub-assignment Clarification) Message-ID: Dear colleagues, Policy proposal 2016-04, "IPv6 Sub-assignment Clarification" is now in the Review Phase. The goal of this proposal is to re-define the term "sub-assignment" for IPv6. This proposal has been updated following the last round of discussion and is now at version v2.0. Some of the differences from version v1.0 include: - the scope is extended to all IPv6 assignments - it defines that the provision of separate IPv6 addresses is not considered a sub-assignment The RIPE NCC has prepared an impact analysis on this latest proposal version to support the community?s discussion. You can find the full proposal and impact analysis at: https://www.ripe.net/participate/policies/proposals/2016-04 And the draft documents at: https://www.ripe.net/participate/policies/proposals/2016-04/draft As per the RIPE Policy Development Process (PDP), the purpose of this four week Review Phase is to continue discussing the proposal, taking the impact analysis into consideration, and to review the full draft RIPE Policy Document. At the end of the Review Phase, the WG Chairs will determine whether the WG has reached rough consensus. It is therefore important to provide your opinion, even if it is simply a restatement of your input from the previous phase. We encourage you to read the proposal, impact analysis and draft document and send any comments to before 17 November 2017. Kind regards, Marco Schmidt Policy Development Officer RIPE NCC Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum From max at rfc2324.org Thu Oct 19 15:33:18 2017 From: max at rfc2324.org (Maximilian Wilhelm) Date: Thu, 19 Oct 2017 15:33:18 +0200 Subject: [address-policy-wg] 2016-04 Review Phase (IPv6 Sub-assignment Clarification) In-Reply-To: References: Message-ID: <20171019133318.GK12449@principal.rfc2324.org> Anno domini 2017 Marco Schmidt scripsit: Hi Marco, > Policy proposal 2016-04, "IPv6 Sub-assignment Clarification" is now in the Review Phase. Cool, thanks for that! > The goal of this proposal is to re-define the term "sub-assignment" for IPv6. > > This proposal has been updated following the last round of discussion and is now at version v2.0. > Some of the differences from version v1.0 include: > - the scope is extended to all IPv6 assignments > - it defines that the provision of separate IPv6 addresses is not considered a sub-assignment > > The RIPE NCC has prepared an impact analysis on this latest proposal version to support the community?s discussion. You can find the full proposal and impact analysis at: > https://www.ripe.net/participate/policies/proposals/2016-04 > > And the draft documents at: > https://www.ripe.net/participate/policies/proposals/2016-04/draft There seem's to be some glitch in the comparison between the proposal versions. The diff seems to be in the wrong direction. Could you have a look at that? Thanks! Best Max -- "I have to admit I've always suspected that MTBWTF would be a more useful metric of real-world performance." -- Valdis Kletnieks on NANOG From Ondrej.Caletka at cesnet.cz Thu Oct 19 16:06:55 2017 From: Ondrej.Caletka at cesnet.cz (=?UTF-8?Q?Ond=c5=99ej_Caletka?=) Date: Thu, 19 Oct 2017 16:06:55 +0200 Subject: [address-policy-wg] 2016-04 Review Phase (IPv6 Sub-assignment Clarification) In-Reply-To: References: Message-ID: +1 for this proposal. The only thing that I'm little bit scared of is the last paragraph of the section A of the impact analysis. Some operators could use this proposal as an apology for not deploying the network properly, like when they use (pseudo-)bridges instead of routers, just to avoid "sub-delegation". But I don't think this is a big problem, especially now when most entities are becoming LIRs just to get some more v4 addresses. I believe this proposal goes in the right direction and conforms with common sense on what should be assignments used for. -- Ond?ej Caletka -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3718 bytes Desc: Elektronicky podpis S/MIME URL: From leo.vegoda at icann.org Fri Oct 20 00:55:33 2017 From: leo.vegoda at icann.org (Leo Vegoda) Date: Thu, 19 Oct 2017 22:55:33 +0000 Subject: [address-policy-wg] [Ext] 2016-04 Review Phase (IPv6 Sub-assignment Clarification) In-Reply-To: References: Message-ID: <39266388780c439385636e2735db3e4e@PMBX112-W1-CA-1.PEXCH112.ICANN.ORG> Marco Schmidt wrote: [...] > Policy proposal 2016-04, "IPv6 Sub-assignment Clarification" > is now in the Review Phase. I am neither speaking for or against the proposal but would like to ask to a question to clarify my understanding. The proposal states: "Although the IPv6 address space is huge, it's still finite. Users only needing a /48 (or less) for their organisation would also block a full /29 prefix when forced to become LIR which seems unproportioned." But some years ago, the RIPE NCC stated that it was using a bisection approach to allocate from its /12: https://www.ripe.net/ripe/mail/archives/address-policy-wg/2011-July/006176.html Is that still the case and if it is, it would be good to understand how each new /32 allocation blocks a /29. I had understood that defined reservations were no longer necessary for new allocations because of the changed approach to allocating address space. Kind regards, Leo Vegoda -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4988 bytes Desc: not available URL: From gert at space.net Fri Oct 20 09:34:50 2017 From: gert at space.net (Gert Doering) Date: Fri, 20 Oct 2017 09:34:50 +0200 Subject: [address-policy-wg] [Ext] 2016-04 Review Phase (IPv6 Sub-assignment Clarification) In-Reply-To: <39266388780c439385636e2735db3e4e@PMBX112-W1-CA-1.PEXCH112.ICANN.ORG> References: <39266388780c439385636e2735db3e4e@PMBX112-W1-CA-1.PEXCH112.ICANN.ORG> Message-ID: <20171020073450.GG45648@Space.Net> Hi, On Thu, Oct 19, 2017 at 10:55:33PM +0000, Leo Vegoda wrote: > "Although the IPv6 address space is huge, it's still finite. > Users only needing a /48 (or less) for their organisation would > also block a full /29 prefix when forced to become LIR which > seems unproportioned." > > But some years ago, the RIPE NCC stated that it was using a > bisection approach to allocate from its /12: > https://www.ripe.net/ripe/mail/archives/address-policy-wg/2011-July/006176.html > > Is that still the case and if it is, it would be good to > understand how each new /32 allocation blocks a /29. Since the initial allocation today can be a /29 with "no questions asked", this is not so much a matter of "reserving 3 additional bits, in addition to the allocation" as of "the allocations are this size today". (Not exactly sure what happens if a LIR steps up and says "I only want a /32!!" - Marco, can you comment on that? Will the NCC still *block* the /29, or might it happen that other /32s out of that /29 will eventually be allocated to someone else?) Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard 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: smime.p7s Type: application/x-pkcs7-signature Size: 3603 bytes Desc: not available URL: From ingrid at ripe.net Fri Oct 20 10:16:29 2017 From: ingrid at ripe.net (Ingrid Wijte) Date: Fri, 20 Oct 2017 10:16:29 +0200 Subject: [address-policy-wg] Confusion In-Reply-To: References: Message-ID: <9125212d-4f8e-3729-71d9-8b92432e7745@ripe.net> Dear Aleksey, The RIPE Document, "RIPE Resource Transfer Policies" (ripe-682), states that transfers between LIR accounts belonging to the same member fall within the scope of the RIPE Resource Transfer Policy. This means that resources cannot be transferred for 24 months, whether they were received from RIPE NCC, through a policy transfer or a change in an organisation's business structure: https://www.ripe.net/publications/docs/ripe-682#2-2-transfer-restrictions The RIPE NCC procedural document mentions this same limitation: https://www.ripe.net/publications/docs/ripe-689#transfer35 However, resources can be transferred due to a change in an organisation's business structure (such as a merger or network acquisition) within this 24 month period IF this is supported by documents from a national authority. I hope this clarifies.?? Best regards, Ingrid Wijte RIPE NCC On 19/10/2017 14:46, Aleksey Bulgakov wrote: > Hi, all. > > As you can read here > https://www.ripe.net/ripe/mail/archives/ncc-announce/2016-July/001066.html > > > Transfer of resources between LIR accounts of the same member will > > fall under the transfer policy. > > This aligns the transfer of resources > between LIR accounts of the same > member with the transfer procedures > the RIPE NCC applies to transfers between LIR accounts of different > members. > > The transfer policy will now apply to all transfers, > regardless of > whether the transfer is between the same or different > members. > > In practice, this means that the IPv4 allocation will only be > > transferable between LIR accounts of the same member after 24 months. > > But if you go to transfer policy, you can see the next > > This restriction does not prevent the resources from being transferred > due to further mergers or acquisitions within the 24-month period. > > So, I see confusion between policies and executive board desision > . -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrea at ripe.net Fri Oct 20 10:32:53 2017 From: andrea at ripe.net (Andrea Cima) Date: Fri, 20 Oct 2017 10:32:53 +0200 Subject: [address-policy-wg] [Ext] 2016-04 Review Phase (IPv6 Sub-assignment Clarification) In-Reply-To: <39266388780c439385636e2735db3e4e@PMBX112-W1-CA-1.PEXCH112.ICANN.ORG> References: <39266388780c439385636e2735db3e4e@PMBX112-W1-CA-1.PEXCH112.ICANN.ORG> Message-ID: <094d3823-2d86-6aa5-952a-d1e7880a1454@ripe.net> Hi Leo, I'm happy to provide some clarification here. On 20/10/2017 00:55, Leo Vegoda wrote: > Marco Schmidt wrote: > > [...] > >> Policy proposal 2016-04, "IPv6 Sub-assignment Clarification" >> is now in the Review Phase. > I am neither speaking for or against the proposal but would like > to ask to a question to clarify my understanding. > > The proposal states: > > "Although the IPv6 address space is huge, it's still finite. > Users only needing a /48 (or less) for their organisation would > also block a full /29 prefix when forced to become LIR which > seems unproportioned." > > But some years ago, the RIPE NCC stated that it was using a > bisection approach to allocate from its /12: > https://www.ripe.net/ripe/mail/archives/address-policy-wg/2011-July/006176.html > > Is that still the case and if it is, it would be good to > understand how each new /32 allocation blocks a /29. > > I had understood that defined reservations were no longer > necessary for new allocations because of the changed approach to > allocating address space. The RIPE NCC currently reserves a /26 for every allocation up to a /29. For allocations larger than a /29, the next three bits are reserved. This is based on a policy requirement that the RIPE NCC should maximise the potential for subsequent allocations to be contiguous with previous allocations: https://www.ripe.net/publications/docs/ripe-684#aggregation I hope this clarifies. Kind regards, Andrea Cima > > Kind regards, > > Leo Vegoda From mschmidt at ripe.net Mon Oct 23 07:56:59 2017 From: mschmidt at ripe.net (Marco Schmidt) Date: Mon, 23 Oct 2017 07:56:59 +0200 Subject: [address-policy-wg] 2017-03 Policy Proposal Withdrawn (Reducing Initial IPv4 Allocation, Aiming to Preserve a Minimum of IPv4 Space for Newcomers) Message-ID: Dear colleagues, The policy proposal 2017-03, "Reducing Initial IPv4 Allocation, Aiming to Preserve a Minimum of IPv4 Space for Newcomers" has been withdrawn. The proposal is archived and can be found at: https://www.ripe.net/participate/policies/archived-policy-proposals/archive-policy-proposals/ Reason for withdrawal: The proposers felt unable to create a second draft that addressed conflicting objections. Regards, Marco Schmidt Policy Development Officer RIPE NCC Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum From nick at foobar.org Tue Oct 24 11:41:49 2017 From: nick at foobar.org (Nick Hilliard) Date: Tue, 24 Oct 2017 10:41:49 +0100 Subject: [address-policy-wg] IXP peering lan reachability Message-ID: <59EF0ADD.8020607@foobar.org> Following up on Andrea's presentation earlier (for the record, ripe75, apwg session #1, tuesday morning), there aren't compelling reasons for the RIPE NCC to get involved in whether an IXP announces their peering LAN prefix into the DFZ. It's really a matter of local policy for the ixp as to whether they want this to happen, and if a prefix is announced into the dfz, this doesn't make any statement one way or another about what the prefix is used for. Lots of IXPs announce their peering lan netblocks and many others choose not to. The reasons for announcing relate mostly to debugging and problem diagnosis, e.g. ping / traceroute. We know of several IXP members at various INEX LANs who use external reachability checking services to monitor their service's uptime, which is a good thing to do and they see a benefit from this, and they particularly don't want to see this benefit going away. Regarding traceroute, the udp/icmp replies can be dropped if the network you're tracing from has uRPF enabled, which makes problem diagnosis troublesome. The reason most IXPs don't announce their peering LANs relates to protecting against DDoS attacks. Although we've had occasional DDoS attacks launched against our infrastructures in the past, we have not had service-affecting problems as a result. If a service affecting problem happens, we can announce the blocks with no-export or no-announce, which would reduce the blast radius - or we could completely drop the announcement, if that didn't work. We're aware that the experience at other IXPs - especially larger IXPs - can be different, but given that announcing the blocks provides useful telemetry and diagnosis capabilities, and we've not had problems in the last, we don't see any particular reason to stop announcing the range. The risk/return ratio doesn't justify it. The experiences of other IXPs may be different regarding ddos problems, but many (most?) organisations connected to IXPs use "redistribute connected" to inject the peering LAN prefix into their IGPs, and the largest IXPs have visibility to most of the Internet prefixes, so in practice, not announcing the blocks makes less difference to DDoS than it might appear. I'd politely suggest that this is an area that the RIPE NCC should not get involved in, especially from the point of view of implicitly issuing recommended practice by implying that there is a problem with doing this. The IXP associations are better placed to gather consensus for creating best practices, and there is no general consensus in the IXP community on this issue. As regards using this as a metric for determining whether an ixp address assignment is being used for legitimate purposes, I'd suggest that this is of only marginal use at best. By all means run a port scan to see if there is any obvious mis-use (e.g. services listening on www/smtp/etc), but the presence or absence of the route in the dfz doesn't mean anything one way or another. Nick CTO, INEX From rhe at nosc.ja.net Tue Oct 24 12:18:02 2017 From: rhe at nosc.ja.net (Rob Evans) Date: Tue, 24 Oct 2017 14:18:02 +0400 Subject: [address-policy-wg] IXP peering lan reachability In-Reply-To: <59EF0ADD.8020607@foobar.org> References: <59EF0ADD.8020607@foobar.org> Message-ID: <20171024101801.GA29946@dhcp-29-155.ripemtg.ripe.net> > I'd politely suggest that this is an area that the RIPE NCC should not > get involved in, especially from the point of view of implicitly issuing > recommended practice by implying that there is a problem with doing > this. The IXP associations are better placed to gather consensus for > creating best practices, and there is no general consensus in the IXP > community on this issue. Full agreement with Nick, the (controlled) announcement or otherwise of an IXP prefix is not a registry policy issue. Cheers, Rob From aris.lambrianidis at ams-ix.net Tue Oct 24 12:28:03 2017 From: aris.lambrianidis at ams-ix.net (Aris Lambrianidis) Date: Tue, 24 Oct 2017 14:28:03 +0400 Subject: [address-policy-wg] IXP peering lan reachability In-Reply-To: <20171024101801.GA29946@dhcp-29-155.ripemtg.ripe.net> References: <59EF0ADD.8020607@foobar.org> <20171024101801.GA29946@dhcp-29-155.ripemtg.ripe.net> Message-ID: <4C6A22EF-F9E2-42EE-8B84-1BA542BEAA32@ams-ix.net> > On 24 Oct 2017, at 14:18, Rob Evans wrote: > > Full agreement with Nick, the (controlled) announcement or otherwise > of an IXP prefix is not a registry policy issue. > > Cheers, > Rob Another +1 here with Nick?s email. There are good reasons to not announce the peering LAN prefix, but there are also good reasons to announce it. In the AMS-IX case, we have so many networks connected that: 1. Customers announce it inadvertently anyhow 2. Since 1. is the operational reality (which is unrealistic to stop anytime soon, if ever), we prefer (also) announcing it ourselves, in the hopes that traffic at least goes through its ?legitimate" originator. From my point of view, RIPE could offer reasons for both options, as to educate in the matter, contributing in a way so IXPs can make an informed decision. Kind regards, Aris AMS-IX -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 873 bytes Desc: Message signed with OpenPGP URL: From gert at space.net Tue Oct 24 12:34:29 2017 From: gert at space.net (Gert Doering) Date: Tue, 24 Oct 2017 12:34:29 +0200 Subject: [address-policy-wg] IXP peering lan reachability In-Reply-To: <59EF0ADD.8020607@foobar.org> References: <59EF0ADD.8020607@foobar.org> Message-ID: <20171024103429.GJ45648@Space.Net> Hi, On Tue, Oct 24, 2017 at 10:41:49AM +0100, Nick Hilliard wrote: > As regards using this as a metric for determining whether an ixp address > assignment is being used for legitimate purposes, I'd suggest that this > is of only marginal use at best. By all means run a port scan to see if > there is any obvious mis-use (e.g. services listening on www/smtp/etc), > but the presence or absence of the route in the dfz doesn't mean > anything one way or another. The *absence* of the route is a very strong indicator that no other services than directly peering-related are sitting on that network, no? Gert -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From nick at foobar.org Tue Oct 24 12:56:23 2017 From: nick at foobar.org (Nick Hilliard) Date: Tue, 24 Oct 2017 11:56:23 +0100 Subject: [address-policy-wg] IXP peering lan reachability In-Reply-To: <20171024103429.GJ45648@Space.Net> References: <59EF0ADD.8020607@foobar.org> <20171024103429.GJ45648@Space.Net> Message-ID: <59EF1C57.10307@foobar.org> Gert Doering wrote: > The *absence* of the route is a very strong indicator that no other > services than directly peering-related are sitting on that network, no? or that the holder is squatting the space, or that it's being used for connectivity which is unrelated to the standard DFZ (e.g. l3vpn p2p addressing), or that it's just not being used at that time, or... By all means, the RIPE NCC should flag things as a problem if it sees server farms configured on an assigned ixp range, or sees traceroutes ending up in residential customer, or whatever, but the presence or absence of a prefix in the dfz, per se, does not mean anything. Nick From cfriacas at fccn.pt Tue Oct 24 13:07:59 2017 From: cfriacas at fccn.pt (=?ISO-8859-15?Q?Carlos_Fria=E7as?=) Date: Tue, 24 Oct 2017 12:07:59 +0100 (WEST) Subject: [address-policy-wg] IXP peering lan reachability In-Reply-To: <59EF0ADD.8020607@foobar.org> References: <59EF0ADD.8020607@foobar.org> Message-ID: On Tue, 24 Oct 2017, Nick Hilliard wrote: (...) > I'd politely suggest that this is an area that the RIPE NCC should not > get involved in, especially from the point of view of implicitly issuing > recommended practice by implying that there is a problem with doing > this. The IXP associations are better placed to gather consensus for > creating best practices, and there is no general consensus in the IXP > community on this issue. > > As regards using this as a metric for determining whether an ixp address > assignment is being used for legitimate purposes, I'd suggest that this > is of only marginal use at best. By all means run a port scan to see if > there is any obvious mis-use (e.g. services listening on www/smtp/etc), > but the presence or absence of the route in the dfz doesn't mean > anything one way or another. > > Nick > CTO, INEX +1. I only have some doubts about running (regular) portscans. Cheers, Carlos From cfriacas at fccn.pt Tue Oct 24 13:12:05 2017 From: cfriacas at fccn.pt (=?ISO-8859-15?Q?Carlos_Fria=E7as?=) Date: Tue, 24 Oct 2017 12:12:05 +0100 (WEST) Subject: [address-policy-wg] IXP peering lan reachability In-Reply-To: <59EF1C57.10307@foobar.org> References: <59EF0ADD.8020607@foobar.org> <20171024103429.GJ45648@Space.Net> <59EF1C57.10307@foobar.org> Message-ID: Hi, On Tue, 24 Oct 2017, Nick Hilliard wrote: > Gert Doering wrote: >> The *absence* of the route is a very strong indicator that no other >> services than directly peering-related are sitting on that network, no? > > or that the holder is squatting the space, or that it's being used for > connectivity which is unrelated to the standard DFZ (e.g. l3vpn p2p > addressing), or that it's just not being used at that time, or... > > By all means, the RIPE NCC should flag things as a problem if it sees > server farms configured on an assigned ixp range, or sees traceroutes > ending up in residential customer, or whatever, but the presence or > absence of a prefix in the dfz, per se, does not mean anything. I understand it as a simple clue. Clues sometimes lead nowhere... Btw, is the NCC already monitoring this address space's usage somehow? (i may have missed this bit from Andrea's presentation, i didn't catch it from the beginning). Or we are simply relying on stat.ripe.net, atlas, and the like...? Cheers, Carlos > Nick > From andrea at ripe.net Tue Oct 24 13:28:25 2017 From: andrea at ripe.net (Andrea Cima) Date: Tue, 24 Oct 2017 13:28:25 +0200 Subject: [address-policy-wg] IXP peering lan reachability In-Reply-To: References: <59EF0ADD.8020607@foobar.org> <20171024103429.GJ45648@Space.Net> <59EF1C57.10307@foobar.org> Message-ID: Hi Carlos, On 24/10/2017 13:12, Carlos Fria?as wrote: > On Tue, 24 Oct 2017, Nick Hilliard wrote: > >> Gert Doering wrote: >>> The *absence* of the route is a very strong indicator that no other >>> services than directly peering-related are sitting on that network, no? >> >> or that the holder is squatting the space, or that it's being used for >> connectivity which is unrelated to the standard DFZ (e.g. l3vpn p2p >> addressing), or that it's just not being used at that time, or... >> >> By all means, the RIPE NCC should flag things as a problem if it sees >> server farms configured on an assigned ixp range, or sees traceroutes >> ending up in residential customer, or whatever, but the presence or >> absence of a prefix in the dfz, per se, does not mean anything. > > I understand it as a simple clue. Clues sometimes lead nowhere... > > Btw, is the NCC already monitoring this address space's usage somehow? > (i may have missed this bit from Andrea's presentation, i didn't catch > it from the beginning). > Yes, we are monitoring the address space from the /16 reserved for IXPs peering LANs. When we see that one of the ranges is being announced, we contact the holder, reminding them the address space can only be used to run an IXP peering LAN, and that other uses are forbidden by policy. Usually the holder of the address space has indeed started using the IP range for other services, as they are often not aware of the policy in place. I hope this clarifies, Andrea Cima RIPE NCC