May 2019 - address-policy-wg - mailman.ripe.net

2019-05 New Policy Proposal (Revised IPv4 assignment policy for IXPs)
by Marco Schmidt 05 Sep '19

05 Sep '19

Dear colleagues, A new RIPE Policy proposal, 2019-05, "Revised IPv4 assignment policy for IXPs" is now available for discussion. This proposal aims to increase the reserved IPv4 pool for IXPs to a /15 and finetune assignment criteria. You can find the full proposal at: https://www.ripe.net/participate/policies/proposals/2019-05 As per the RIPE Policy Development Process (PDP), the purpose of this four week Discussion Phase is to discuss the proposal and provide feedback to the proposer. At the end of the Discussion Phase, the proposers, with the agreement of the WG Chairs, will decide how to proceed with the proposal. We encourage you to review this proposal and send your comments to <address-policy-wg(a)ripe.net> before 27 June 2019. Regards, Marco Schmidt Policy Officer RIPE NCC Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum

29 70

New on RIPE Labs: So Long Last /8 and Thanks For All the Allocations
by Mirjam Kuehne 28 Aug '19

28 Aug '19

Dear colleagues, On 17 April 2018, we allocated the last available block of 1,024 addresses in 185/8 - the last /8 we received from IANA back in 2011. This article on RIPE Labs looks at how this address space was allocated and how it is used today: https://labs.ripe.net/Members/wilhelm/so-long-last-8-and-thanks-for-all-the… It's important to keep in mind that while 185/8 is finished, we still have around nine million recovered IPv4 addresses in our available pool. Under current policy and growth rates, we expect these to last a further two years. Kind regards, Mirjam Kühne RIPE NCC

3 2

2019-02 Review Phase (IPv4 Waiting List Implementation)
by Marco Schmidt 24 Jun '19

24 Jun '19

Dear colleagues, Policy proposal 2019-02, "IPv4 Waiting List Implementation" is now in the Review Phase. This proposal aims at creating a waiting list based on an allocation size of /24 once the RIPE NCC’s free IPv4 pool is exhausted. The 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: - New proposal title - Focus on waiting list requirements - Adjusting the moment of policy activation 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/2019-02 And the draft documents at: https://www.ripe.net/participate/policies/proposals/2019-02/draft As per the RIPE Policy Development Process (PDP), the purpose of this four week Review Phase is to continue discussion of the proposal, taking the impact analysis into consideration, and to review the full draft RIPE Policy Document. At the end of the Review Phase, the 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 <address-policy-wg(a)ripe.net> before 4 June 2019. Kind regards, Marco Schmidt Policy Officer RIPE NCC Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum

9 8

Prefix size
by Sander Steffann 23 May '19

23 May '19

Hi, Yesterday in the APWG session I promised to go to the routing WG and notify them of the possibility of IPv4 prefix lengths growing longer than /24 in the future. I think Geoff Huston just already made an excellent presentation that included that point, so thank you Geoff! Cheers, Sander

1 0

informal discussion about removing 5.4.2. Assignments shorter than a /48 to a single End Site
by JORDI PALET MARTINEZ 22 May '19

22 May '19

Hi all, As commented this morning at the end of the WG meeting, I've been thinking about this issue many times and in fact, in AFRINIC, APNIC and LACNIC, as part of *other* more complex IPv6 policy proposals, we successfully achieved consensus on removing the equivalent text. ARIN has also changed this. In my opinion, the way they handle it, is too complex and not needed, but if someone want to read: https://www.arin.net/participate/policy/nrpm/#6-5-8-2-2-extra-large-sites I've not (yet) done this in RIPE because I thought it is a so small change that doesn't make sense to tackle alone, but this morning I heard otherwise. So ... here we are. By the way, as I always state, I will love some other folks that are willing to contribute, if so let me know in private so we can even organize an on-site meeting. However, in this case I think this policy proposal is just an "empty" one (only remove text, so nothing to draft ...) ... see below. This is our actual text (https://www.ripe.net/publications/docs/ripe-707#assignments_shorter): *** 5.4.2. Assignments shorter than a /48 to a single End Site When a single End Site requires an assignment shorter than a /48, it must request the assignment with documentation or materials that justify the request. Requests for multiple or additional prefixes exceeding a /48 assignment for a single End Site will be processed and reviewed (i.e., evaluation of justification) at the RIR/NIR level. Note: There is no experience at the present time with the assignment of multiple network prefixes to the same End Site. Having the RIR review all such assignments is intended to be a temporary measure until some experience has been gained and some common policies can be developed. In addition, additional work at defining policies in this space will likely be carried out in the near future. *** In my opinion (as I've done in other RIRs), we should just *remove* the complete section. Extreme example case. If an LIR decides to assign /47 to all their customers, and in the future, they need to come back to the NCC for more space, they will need to justify it according to the existing policy at that time. I may understand (even if I don't agree) that somebody want to have the NCC keep doing some evaluation on this. If we want to go this way, we will need to define with a short text what we want. So, opinions? Regards, Jordi ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.

2 1

2019-01 Proposal Accepted and Implemented (Clarification of Definition for "ASSIGNED PA")
by Marco Schmidt 20 May '19

20 May '19

Dear colleagues, Consensus has been reached on 2019-01, "Clarification of Definition for "ASSIGNED PA"". This proposal made it clear in the IPv4 Policy that the status "ASSIGNED PA" can also be used for assignments to an LIR's infrastructure. You can find the full proposal at: https://www.ripe.net/participate/policies/proposals/2019-01 The new RIPE Document is called ripe-720 and is available at: https://www.ripe.net/publications/docs/ripe-720 This proposal is implemented with immediate effect. Thank you to everyone who provided input. Kind regards, Marco Schmidt Policy Officer RIPE NCC Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum

1 0

2019-01 Last Call for Comments (Clarification of Definition for "ASSIGNED PA")
by Marco Schmidt 15 May '19

15 May '19

Dear colleagues, Proposal 2019-01, "Clarification of Definition for "ASSIGNED PA"", is now in Concluding Phase. This proposal aims to make it clear in the IPv4 Policy that the status "ASSIGNED PA" can also be used for assignments to an LIR's infrastructure. The WG co-chair has declared that rough consensus has been reached and the proposal will now move to Last Call. As per the RIPE Policy Development Process (PDP), the purpose of this four week Concluding Phase is to give an opportunity to present well-justified objections for those who missed the previous two phases and wish to oppose the proposal. Any objection must be made by 14 May 2019 and must be supported by an explanation. If no substantive objections are raised by the end of Last Call, the proposal will complete the PDP and will be evaluated by the WG Chairs for consensus. You can find the full proposal at: https://www.ripe.net/participate/policies/proposals/2019-01 Please e-mail any final comments about this proposal to <address-policy-wg(a)ripe.net> before 14 May 2019. Regards, Marco Schmidt Policy Officer RIPE NCC Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum

2 1

Agenda for APWG meeting in Reykjavik
by Gert Doering 10 May '19

10 May '19

Dear working group, dear RIPE meeting folks, Below you can find a draft for the RIPE address policy WG meeting's agenda, which will take place in Reykjavik in the side-room (!) in the following time slots: Wednesday, May 22, 09:00 - 10:30 Wednesday, May 22, 11:00 - 12:30 We have two time slots, and the agenda is currently very light. So if you have something you want to see discussed (which is *address policy* related, so no member fee discussions or database stuff :-) ), please approach Erik or me to see whether this would be a good opportunity. Regards, Gert Döring & Erik Bais, APWG chairs ---------------------------------------------------------------------- Wednesday, 09:00-10:30 ---------------------------------------------------------------------- A. Administrative Matters (welcome, thanking the scribe, approving the minutes, etc.) B. WG chair rotation / re-seating - longest-serving chair (Gert Döring) stepping down - finding a new one or keeping the old one C. Current Policy Topics - Marco Schmidt, NCC PDO - global policy overview "what's going on?" - common policy topics in all regions (end of IPv4, transfers, ...) - overview over concluded proposals in the RIPE region since RIPE 77 - brief overview of new proposals (if any) D. Feedback From NCC Registration Service - Nikolas Pediaditis (+ discussion with the group) ---------------------------------------------------------------------- Wednesday, 11:00-12:30 ---------------------------------------------------------------------- Welcome back F. Discussion of open policy proposals * 2019-02 Waiting List & Reducing IPv4 Allocations to a /24 Y. Open Policy Hour The Open Policy Hour is a showcase for your policy ideas. If you have a policy proposal you'd like to debut, prior to formally submitting it, here is your opportunity. Z. AOB -- 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

4 5

Application for AS number
by Aled Morris 08 May '19

08 May '19

Hi all I'm in the process of helping a startup ISP get RIPE membership and resources and have hit against a little bit of poor wording in the AS guidelines RIPE-679, specifically: *A network must be multihomed in order to qualify for an AS Number.* The application for an AS number has been delayed because the NCC analyst working on the ticket is claiming the ISP has to be *already multihomed* before an AS can be issued. This interpretation doesn't make any sense to me. Surely the intention *to become multihomed* should be the requirement for obtaining an AS number? I don't even see how you can be properly multihomed if you don't have an AS number. Are we supposed to implement some kind of NAT multihoming first? Can we look to change the wording in RIPE-679 to make this clear? Aled

10 19