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

APWG agenda for Madrid - first draft
by Gert Doering 17 Oct '16

17 Oct '16

Hi APWG folks, below you can find a draft for the RIPE address policy WG meeting's agenda, which will take place in Madrid in the following time slots: Wednesday, Oct 26, 10:00 - 11:30 (+1 hour!!) Wednesday, Oct 26, 12:00 - 13:30 If you have anything else you want to see on the agenda, or if we need to change anything, please let us know. So far, the agenda is fairly light - if you have something you want to address, or that bothers you, let us know and we make room for you :-) The distribution of items to the two timeslot is somewhat subject to the time spent on discussion - but we'll try to stick to what's published. regards, Gert Doering & Sander Steffann, APWG chairs ---------------------------------------------------------------------- Wednesday, 10:00-11:30 ---------------------------------------------------------------------- A. Administrative Matters 5 min (welcome, thanking the scribe, approving the minutes, etc.) C. Current Policy Topics - Marco Schmidt, NCC PDO 20 min - 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 72 - brief overview over new proposals (if any) F. Discussion of open policy proposals 50 min 2015-04 RIPE Resource Transfer Policies Erik Bais 2016-03 Locking Down the Final /8 Policy Remco van Mook G. consequences of the end of IPv4 15 min Erik Bais (presentation only, think about over coffee, discuss later) ---------------------------------------------------------------------- Wednesday, 12:00-13:30 ---------------------------------------------------------------------- Welcome back G. consequences of the end of IPv4 30 min Erik Bais (discussion with the group) D. Feedback From NCC Registration Service - Andrea Cima 45 min (+ discussion with the group) Y. Open Policy Hour 15 min 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 Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279

1 2

New on RIPE Labs: Supporting IPv6 Deployment Through Policy
by Marco Schmidt 11 Oct '16

11 Oct '16

Dear colleagues, It was about a year ago that the RIPE community reached consensus on a policy proposal that introduced additional criteria for initial IPv6 allocations. We thought it was time to look back the origins of this proposal and see how the change has worked out since: https://labs.ripe.net/Members/marco_schmidt/supporting-ipv6-deployment-thro… Regards, Marco Schmidt Policy Development Officer RIPE NCC Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum

1 0

(no subject)
by 8lb. 7zin 01 Oct '16

01 Oct '16

Monday, June 9, 2014 at 14:49:33 +0200, Joao Damas wrote: > At a recent meeting RIPE 68 there was a discussion about the issues > On the return of the recovered version for 16-bit ASNs by the NCC and RIPE > Possible modifications to the content of the qualities related guidance in > Data RIPE database objects, a guidance autnum politics features >. As is set things > > The consensus was noted during the meeting include: > > - The National Coordinating Committee RIPE not to remove all references to recovered ASNs for > Import and export lines, not Kkainat- SET. Directive > Policies owner of the object world and have nothing to do > Personalization data. > - NCC RIPE inform the maintainer of the object that contains > Outdated for this reference signal. The NCC also offer RIPE > Support for the breadwinner to delete the reference. > - NCC RIPE start reset referred to numbers once and > It is a reference gathering of 16-bit AS numbers have been exhausted. > > We would like to close the case, and be able to provide clear guidance > NCC RIPE so we would like to get confirmation of this result > Also from the mailing lists of the Working Group. This is not a matter of policy: > We have been dealing with the redistribution of ASNs for recovered with by the APWG, and > The current number of modifications to the database objects associated with the RIPE > Return to the rechargeable customization resources. We suggest 15 days > Comment period, ending June 24, 2014. I love that. Best Regards, Function

1 0

Idea for aggregating IP addresses
by Ping IP 25 Sep '16

25 Sep '16

Hello, One of the goals of RIPE is to aggregate IP addresses. I'd like to suggest the ability for a LIR and End User to exchange number of blocks of IP ranges for a greater block. For example: LIR/End User has 4 different /22 subnets and LIR/End User can exchange these subnets for 1 x /20 subnet. This gives a LIR or End User the possibility to announce larger IP subnets to the Internet. Helping the goal of aggregating the IP addresses on the Internet. According one of the RIPE trainer, this is currently not possible according the RIPE policy. Because there's no policy to give a LIR/End User this ability. I'm curious to what you think of this idea. Best regards, Abdelouahed Ping IP network

8 8

Re: [address-policy-wg] Idea for aggregating IP addresses
by Ping IP 23 Sep '16

23 Sep '16

Hello Jörg, Although I used a /22 and /20 as an example. I deliberately mention IP addresses, since this idea can be used for IPv4 and IPv6. Perhaps its too little, too late for IPv4. But it helps one of the goals of RIPE. Best regards, Abdelouahed Ping IP network 2016-09-22 16:04 GMT+02:00 Jörg Kost <joerg.kost(a)premium-datacenter.de>: > Hi, > > I like the idealism of this idea, but it is too little, too late and much > too many work to save a few bytes on the ip4 routing table. This race is > lost, adding more memory to the board or block and remove certain routes > will be the solution. My focus shifted already to the future (?) > disaggregation of ip6, where we had hit the 32k lately. > > Jörg > > > On 22 Sep 2016, at 14:37, Ping IP wrote: > > Hello, >> >> One of the goals of RIPE is to aggregate IP addresses. I'd like to suggest >> the ability for a LIR and End User to exchange number of blocks of IP >> ranges for a greater block. >> >> For example: >> LIR/End User has 4 different /22 subnets and LIR/End User can exchange >> these subnets for 1 x /20 subnet. >> >> This gives a LIR or End User the possibility to announce larger IP subnets >> to the Internet. Helping the goal of aggregating the IP addresses on the >> Internet. >> >> According one of the RIPE trainer, this is currently not possible >> according >> the RIPE policy. Because there's no policy to give a LIR/End User this >> ability. >> >> I'm curious to what you think of this idea. >> >> Best regards, >> >> Abdelouahed >> Ping IP network >> >

2 1

New on RIPE Labs: All Quiet in the IPv4 Internet?
by Mirjam Kuehne 21 Sep '16

21 Sep '16

Dear colleagues, Please find this new article on RIPE Labs by Philipp Richter: All Quiet in the IPv4 Internet? The number of new IPv4 allocations has stagnated, address markets have taken off, and address sharing mechanisms (for example, Carrier-Grade NAT) are on the rise as operators try to squeeze the most out of their IPv4 address space. But what is really happening in the IPv4 address space? Measuring address space activity at scale is difficult. There’s really no single vantage point that can capture all the activity. Read more on RIPE Labs (this article was originally published on the APNIC blog): https://labs.ripe.net/Members/philipp_richter/all-quiet-in-the-ipv4-internet Kind regards, Mirjam Kuehne RIPE NCC

1 0

RIPE 72 Address Policy WG Draft Minutes
by Marco Schmidt 06 Sep '16

06 Sep '16

Dear colleagues, The draft minutes from the Address Policy Working Group sessions at RIPE 72 have now been published: https://www.ripe.net/participate/ripe/wg/ap/minutes/ripe-72 Please let us know of any corrections or amendments. Kind regards, Marco Schmidt Policy Development Officer RIPE NCC Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum

1 0

Update on ALLOCATED PI/UNSPECIFIED
by Ingrid Wijte 22 Aug '16

22 Aug '16

Dear colleagues, During RIPE 72, the RIPE NCC was asked to suggest a way forward with regards to the unclear situation arising from address blocks in the RIPE Database with the status ALLOCATED PI or ALLOCATED UNSPECIFIED. We want to give you an update on this work and ask for your input. BACKGROUND Although PI assignments made by LIRs have the same status in the RIPE Database, it is not clear if resource holders with assignments from LIRs have the same rights as resource holders with those issued by the RIPE NCC. The community, mainly End Users, has asked the RIPE NCC to clarify the situation. In the early days of the RIPE NCC, a small number of LIRs received allocations with the status ALLOCATED PI or ALLOCATED UNSPECIFIED. From these address blocks, LIRs could assign ranges with the status ASSIGNED PI. The RIPE community later decided that the RIPE NCC should be the only party assigning ranges with ASSIGNED PI to End Users. It was not clear what the status of the assignments that had already been made should be. ACTION TAKEN At RIPE 71, the Address Policy Working Group asked the RIPE NCC to check the actual assignment status with the holders of these allocations. We contacted all of the LIRs involved and around 50% said they had no contact with holders of assignments with the status ASSIGNED PI within their allocations. Several allocations containing only PA assignments were converted from ALLOCATED UNSPECIFIED to ALLOCATED PA following communication with LIRs. The RIPE NCC presented these results to the Address Policy Working Group at RIPE 72. The WG stressed that data accuracy must have the highest priority. It was further suggested that the RIPE NCC should follow up with the LIRs on a case-by-case basis, following the principles outlined below. The WG agreed that, where the LIR can document a mutual agreement that they administer the address space, a conversion from PI to PA should take place. In all other cases, assignments with the status ASSIGNED PI should be treated as being assigned by the RIPE NCC. It was also stated that LIRs should not register any new assignments with the status ASSIGNED PI, as policy no longer allows for new IPv4 PI assignments (with the exception of IXP PI assignments from our reserved address pool). APPROACH The RIPE NCC will contact the 38 LIRs holding allocations that contain address blocks with the status ASSIGNED PI (3,600 inetnum objects in total). In the following months, these LIRs will check if their RIPE Database entries are still correct. Each LIR will check their records and with their customers to see under what conditions the assignments were originally provided. After the LIRs have finished their research, the RIPE NCC will: - Convert assignments to ASSIGNED PA if it can be documented that the administrative responsibility lies with the LIR - Follow up directly with resource holders of ASSIGNED PI to apply the RIPE policy, “Contractual Requirements for Provider Independent Resource Holders in the RIPE NCC Service Region”. The PI assignments will become part of the address space managed by the RIPE NCC just like all other PI space. Once the resource holders have fulfilled the contractual requirements, they will have the same rights and obligations as any other End User of PI space. - Split the allocations to separate the PI assignments and convert the blocks that remain with an LIR to ALLOCATED PA. We suggest giving these LIRs until the end of January 2017 to clarify the status of the assignments within their ALLOCATED PI/UNSPECIFIED allocations. In situations where a dispute arises between the LIR and the assignment holder about the administrative responsibility, the RIPE NCC will do its best to support a fair solution. We welcome your feedback on this suggested approach. Please provide your input before 12 September 2016. Kind regards, Ingrid Wijte Assistant Manager Registration Services RIPE NCC

19 40

2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy)
by Marco Schmidt 16 Aug '16

16 Aug '16

Dear colleagues, The Discussion Period for the policy proposal 2016-03, "Locking Down the Final /8 Policy" has been extended until 15 July 2016. The goal of this proposal is to ban transfers of allocations made under the final /8 policy. The text of the proposal has been revised based on mailing list feedback and we have published a new version (2.0) today. As a result, a new Discussion Phase has started for the proposal. Some of the differences from version 1.0 include: - Several restrictions have been removed - Adds a recommendation that LIRs should conserve whole or part of their final /22 allocation for interoperability purposes You can find the full proposal at: https://www.ripe.net/participate/policies/proposals/2016-03 We encourage you to review this policy proposal and send your comments to <address-policy-wg(a)ripe.net>. Regards, Marco Schmidt Policy Development Officer RIPE NCC Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum

38 142

New AS Number Blocks allocated to the RIPE NCC
by Ingrid Wijte 01 Aug '16

01 Aug '16

Dear Colleagues, The RIPE NCC has received the following AS Number Blocks from the IANA on 29 July 2016. 64396-64495 204288-205211 205212-206235 206236-207259 You may want to update your records accordingly. Best regards, Ingrid Wijte Registration Services Assistant Manager RIPE NCC

1 0