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

permanently % denied
by Patrick Schauer 10 Jan '18

10 Jan '18

Why your service blocked many of my customers? how can we delete your entries? Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum

1 0

DMARC Solution Applied to this Mailing List
by Adam Castle 18 Dec '17

18 Dec '17

Dear Working Group, As more email providers enable Domain Message Authentication Reporting & Conformance (DMARC), some people find they can no longer receive emails from the mailing lists they are subscribed to. We have deployed a Mailman setting change to address this problem. After consultation with the RIPE Working Group Chairs, we have enabled the DMARC "Munge From" setting on all RIPE mailing lists. This means that if your email service provider has DMARC enabled, you will continue to receive all emails sent to this mailing list, but the "From" part of the header will change. If you don't have DMARC enabled, you won't see any change to the emails you receive from this mailing list. You can find more information about how we have been handling DMARC in the following RIPE Labs articles: https://labs.ripe.net/Members/adam_castle/dmarc-and-the-ripe-ncc https://labs.ripe.net/Members/adam_castle/ripe-mailing-lists-and-dmarc To ensure all working group participants are aware of the changes, I am sending this mail to all working groups. If you have any questions or encounter any issues on this mailing list, please let me know. Many thanks. Adam Castle Web Services Manager RIPE NCC

1 0

2016-04 Review Phase Extended (IPv6 Sub-assignment Clarification)
by Marco Schmidt 27 Nov '17

27 Nov '17

Dear colleagues, Policy proposal 2016-04, "IPv6 Sub-assignment Clarification" is now in the extended Review Phase. The goal of this proposal is to re-define the term "sub-assignment" for IPv6. You can find the full proposal and the RIPE NCC 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 extended 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. We encourage you to read the proposal, impact analysis and draft document and send any comments to <address-policy-wg(a)ripe.net> before 27 December 2017. Kind regards, Marco Schmidt Policy Development Officer RIPE NCC Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum

3 2

IXP peering lan reachability
by Nick Hilliard 24 Oct '17

24 Oct '17

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

6 7

2017-03 Policy Proposal Withdrawn (Reducing Initial IPv4 Allocation, Aiming to Preserve a Minimum of IPv4 Space for Newcomers)
by Marco Schmidt 23 Oct '17

23 Oct '17

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… 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

1 0

Confusion
by Aleksey Bulgakov 20 Oct '17

20 Oct '17

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 .

3 2

2017-03 New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space)
by Marco Schmidt 08 Oct '17

08 Oct '17

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 <address-policy-wg(a)ripe.net> before 20 October 2017. Kind regards, Marco Schmidt Policy Development Officer RIPE NCC Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum

41 93

Re: [address-policy-wg] 2017-03 New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space)
by Aleksey Bulgakov 06 Oct '17

06 Oct '17

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" <noc(a)ntx.ru> написал: 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 > <address-policy-wg(a)ripe.net> before 20 October 2017. > > Kind regards, > > Marco Schmidt > Policy Development Officer > RIPE NCC > > Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum >

2 1

Re: [address-policy-wg] 2017-03, New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space)
by Willy MANGA 26 Sep '17

26 Sep '17

Hi, Le 22/09/2017 à 08:47, address-policy-wg-request(a)ripe.net a écrit : > [...] > I'm working around IPv6 since 2001. Anna and Randy probably since before > that. We have deployed IPv6. It didn't enable us to completely get rid of > IPv4 within our networks. That also didn't solve any issue for 3rd party > networks -- they all still need IPv4 addresses. being a newbie here can you please explain briefly why, as of today , these people really need IPv4 addresses ? Or at least why they cannot start a transition process towards IPv6? Regards, -- Willy Manga @ongolaboy https://ongola.blogspot.com/

13 23

Agenda for APWG in Dubai (v1)
by Sander Steffann 26 Sep '17

26 Sep '17

Hi APWG folks, below you can find a draft for the RIPE address policy WG meeting's agenda, which will take place in Dubai in the following time slots: Tuesday, October 24, 09:00 - 10:30 Tuesday, October 24, 11:00 - 12:30 If you have anything else you want to see on the agenda, or if we need to change anything, please let us know. Depending on the amount of "not yet known" things that show up on the agenda, we might only need one time slot. In which case, we can all join the Connect WG for a change :-) ** NOTE FOR SPEAKERS[1] ** After Dubai had already been chosen as the location for the upcoming RIPE meeting, the authorities there (DTCM) have started to enforce some rules for conferences and speakers. All speakers (including remote speakers) will need to email the following information to meeting(a)ripe.net before 15 September 2017): - Full name, title - A colour copy of their passport - A copy of their Emirates ID (if a UAE resident) - Profile/bio for the speaker (at least 200 characters) - Mobile number - Email address This information will then be forwarded to the DTCM by the RIPE NCC. We realise that these requirements go beyond what was expected at previous meetings and that they may be a cause for concern for some people - especially the sharing of colour copies of passports. Unfortunately there is nothing we can do about this - we have to comply with local laws. If you do not wish to comply with these requirements then you will not be allowed to present on stage. You will still be able to join the discussions from the floor. [1] "Speakers" includes anyone who is presenting on stage - presenters, WG Chairs, and community members who are chairing or moderating sessions. This also includes policy proposers who are planning to present their policy. Attendees speaking at the microphones during the Q&A are explicitly not considered as speakers. Regards, Gert Doering & Sander Steffann, APWG chairs ---------------------------------------------------------------------- Tuesday, 09:00-10: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 74 - brief overview over new proposals (if any) D. Feedback From NCC Registration Service - Andrea Cima 25 min (+ discussion with the group) F. Discussion of open policy proposals 30 min 2016-04 IPv6 PI Sub-assignment Clarification Maximilian Wilhelm 2017-01 Publish statistics on Intra-RIR Legacy updates Elvis Daniel Velea Y. Open Policy Hour 10 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 ---------------------------------------------------------------------- Tuesday, 12:00-13:30 ---------------------------------------------------------------------- Welcome back F|Y|Z. If we overrun the first slot we continue here.

3 4

Re: [address-policy-wg] 2017-03 New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space)
by Martin Huněk 23 Sep '17

23 Sep '17

Hello, I don't think that there is anyone whom would not be able to justify /22. So I think that there should not be any need for justification. Simply because it would be one more meaningless paper, nothing more. Secondly, for me having more specific routes than /24 doesn't seems seem as the right solution for IPv4. More specific routes means more routes in table, so more resources spent on legacy protocol. As for the core of the proposal - droping maximal allocation size from /22 to /24: I don't think that keeping PA pool longer than needed is good for future of an Internet. Maybe it would be better to transfer more space in PI IX pool, drop the restrictions on that pool which prevents to use it for CGN and let the PA space run flat. Long story short, I'm aginst the 2017-03 policy as it is written right now. Best Regards, Martin Hunek Dne pátek 22. září 2017 10:09:28 CEST, Daniel Suchy napsal(a): > Hello, > /24 is de-facto standard accepted in routing tables these days and also > /24 was used in large scale during PI assignments - so I don't see any > problem in reduction of initial (minimal) IPv4 allocation. So i support > this idea. > > But I would like to keep option for asking more than /24 (up to /22 > maximum, as was decided in the past) LIRs eligible for allocation, if > LIR properly documents his request. > > From my own practice there're some LIR, where /24 is sufficient and they > just become LIRs because there's no other real option to get independent > addresses (old "PI") and with /22 we're just wasting limited resource. > But there're also LIRs, where /22 will actively used. > > I don't see any problems in terms of RFC 2050 mentioned here and memory > contraints, providers had to upgrade their routers in meantime anyway > (at least due to IPv6 adoption). Fragmentation up to /24 is long-term > reality and we had to deal with it anyway. > > With regards, > Daniel > > On 09/21/2017 01:43 PM, 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 > > <address-policy-wg(a)ripe.net> before 20 October 2017. > > > > Kind regards, > > > > Marco Schmidt > > Policy Development Officer > > RIPE NCC > > > > Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum

2 1

Re: [address-policy-wg] 2017-03 New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space)
by Aleksey Bulgakov 22 Sep '17

22 Sep '17

Hi. I think it would be better to allocate /19 or bigger. It helps to go to IPv6 and the problem of IPv4 is resolved automatically. I don't really understand why the NCC tries to prolong the life of the dead patient by means of restrictions such as 2015-01, 2017-03 and others. It seems the NCC wants to earn money due to the IPs become more expensive. So I oppose this proposal. 22 Сен 2017 г. 7:50 пользователь "Mikael Abrahamsson" <swmike(a)swm.pp.se> написал: On Thu, 21 Sep 2017, Tim Chown wrote: At the current run-rate, do we know what is the expected expiry of the free >> pool in RIPE's hands? >> > > There’s http://www.potaroo.net/tools/ipv4/. > There is also: https://www.ripe.net/publications/ipv6-info-centre/about- ipv6/ipv4-exhaustion/ipv4-available-pool-graph Looks to me that there is still IPv4 space being returned, the run-rate on 185/8 is constant, we have approximately 4-5 years to go? To me it looks like things are going according to plan, and I don't see any need to change anything. -- Mikael Abrahamsson email: swmike(a)swm.pp.se

5 4

2017-01 Policy Proposal Withdrawn (Publish statistics on Intra-RIR Legacy updates)
by Marco Schmidt 13 Sep '17

13 Sep '17

Dear colleagues, The policy proposal 2017-01, "Publish statistics on Intra-RIR Legacy updates" has been withdrawn. The proposal is archived and can be found at: https://www.ripe.net/participate/policies/archived-policy-proposals/archive… Reason for withdrawal: The proposer didn't see enough community support, especially from Legacy Resource Holders as the parties that would be most affected. Regards Marco Schmidt Policy Development Officer RIPE NCC Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum

1 0

RIPE 74 Address Policy WG Draft Minutes
by Marco Schmidt 15 Aug '17

15 Aug '17

Dear colleagues, The draft minutes from the Address Policy Working Group sessions at RIPE 74 have now been published: https://www.ripe.net/participate/ripe/wg/ap/minutes/ripe-74 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

New on RIPE Labs: Trends in RIPE NCC Service Region IPv4 Transfers
by Mirjam Kuehne 29 Jun '17

29 Jun '17

Dear colleagues, With only a few months left until the fifth anniversary of RIPE NCC reaching the last unallocated /8 of IPv4 space, we look at developments in transfers in, to and from the RIPE NCC service region. https://labs.ripe.net/Members/wilhelm/trends-in-ipv4-transfers Kind regards, Mirjam Kühne RIPE NCC

2 1

Policy Proposal Implemented: 2015-04 "RIPE Resource Transfer Policies"
by Laurens Hoogendoorn 15 Jun '17

15 Jun '17

Dear colleagues, We are pleased to announce that we have implemented RIPE Policy Proposal 2015-04, "RIPE Resource Transfer Policies". In accordance with the new policy, the 24-month transfer restriction applies to all scarce resources (IPv4 and 16-bit ASNs). The restriction also applies if the resource was received due to a change in the organisation’s business structure (such as a merger or acquisition). The RIPE NCC publishes statistics on transfers that take place. From now on, the statistics will include information that indicates the kind of transfer (whether it is a transfer under policy or it is due to a merger/acquisition). Please note that: - All IPv4 and 16-bit ASN transfer requests received by the RIPE NCC after this announcement will be evaluated under the new policy - The evaluation of transfer requests received before this announcement, if completed within a reasonable time, will fall under the previous policy The main webpage on transfers can be found at: https://www.ripe.net/manage-ips-and-asns/resource-transfers-and-mergers/tra… The archived policy proposal can be found at: https://www.ripe.net/participate/policies/proposals/2015-04 The RIPE Document, "RIPE Resource Transfer Policies", is available at: https://www.ripe.net/publications/docs/transfer-policies -- Kind regards, Laurens Hoogendoorn RIPE NCC Registration Services

1 0

clarification on RIPE Resource Transfer Policies (ripe-682) Section 2.0
by Peter Hessler 23 May '17

23 May '17

Hi All https://www.ripe.net/publications/docs/ripe-682#2-0-transfers-within-the-ri… I saw this restriction: """ Allocated resources may only be transferred to another RIPE NCC member. Provider Independent resources may be transferred to: * A RIPE NCC member; or * An entity that has a contractual relationship with a RIPE NCC member in accordance with the RIPE Policy, """ Note the difference between Allocated (PA) and Provider Independent (PI). Is this split intentional? Would a proposal to unify both under the existing PI rules be welcome? -peter

3 3

recantation
by Randy Bush 11 May '17

11 May '17

at yesterday's address policy statement, i was quite incorrect when i said that updated or obsoleted rfcs were marked. they are not. the index entry is marked. the rfcB obsoliting rfcA is marked as such. but rfcA is not marked as modified. apologies. randy

1 0

2017-01 New Policy Proposal (Publish statistics on Intra-RIR Legacy updates)
by Marco Schmidt 05 May '17

05 May '17

Dear colleagues, A new RIPE Policy proposal, 2017-01, "Publish statistics on Intra-RIR Legacy updates" is now available for discussion. The goal of this proposal is to require the RIPE NCC to publish all changes to the holdership of legacy resources in the existing transfer statistics. You can find the full proposal at: https://www.ripe.net/participate/policies/proposals/2017-01 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 <address-policy-wg(a)ripe.net> before 24 May 2017. Regards, Marco Schmidt Policy Development Officer RIPE NCC Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum

11 22

APWG meeting agenda 0.2
by Gert Doering 26 Apr '17

26 Apr '17

Hi APWG folks, below you can find a second draft for the RIPE address policy WG meeting's agenda, which will take place in Budapest in the following time slots: Wednesday, May 10, 09:00 - 10:30 Wednesday, May 10, 11:00 - 12:30 If you have anything else you want to see on the agenda, or if we need to change anything, please let us know. Depending on the amount of "not yet known" things to show up on the agenda, we might only need one time slot. In which case, we can all join the Connect WG for a change :-) Notable changes in the second version: Item "E" added (this was prompted by a reference to an updated-behind-our-back RFC in the AS number policy), and due to "more policy proposals", item "F" moved to second slot. HEADS UP: side room. regards, Gert Doering & Sander Steffann, APWG chairs ---------------------------------------------------------------------- Wednesday, 09:00-10:30 - main room ---------------------------------------------------------------------- A. Administrative Matters 5 min (welcome, thanking the scribe, approving the minutes, etc.) B. WG Chair Selection 10 min - longest-serving chair (Gert Döring) stepping down - willing to be re-appointed and serve another term 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) D. Feedback From NCC Registration Service - Andrea Cima 25 min (+ discussion with the group) E. outdated references in policy documents - Marco Schmidt 15 min (+ discussion with the group) ---------------------------------------------------------------------- Wednesday, 12:00-13:30 - side room (HEADS UP!) ---------------------------------------------------------------------- Welcome back F. Discussion of open policy proposals 40 min 2016-04 IPv6 PI Sub-assignment Clarification Maximilian Wilhelm 2017-01 Publish statistics on Intra-RIR Legacy updates Elvis Daniel Velea Y. Open Policy Hour 5 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 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

1 0

Policy Proposal Implemented: 2016-05, "Synchronising the Initial and Subsequent IPv6 Allocation Policies"
by Laurens Hoogendoorn 20 Apr '17

20 Apr '17

Dear colleagues, We are pleased to announce that we have implemented policy proposal 2016-05, "Synchronising the Initial and Subsequent IPv6 Allocation Policies". The criteria used to evaluate the size of subsequent IPv6 allocations has been expanded to include: - Hierarchical and geographical structuring of the organisation - Planned longevity of the allocation - Segmentation of infrastructure for security You can find more information about the expanded evaluation criteria here: https://www.ripe.net/manage-ips-and-asns/ipv6/request-ipv6/assessment-crite… The archived policy proposal can be found here: https://www.ripe.net/participate/policies/proposals/2016-05 The RIPE Document, "IPv6 Address Allocation and Assignment Policy", is available here: https://www.ripe.net/publications/docs/ripe-684 -- Kind regards, Laurens Hoogendoorn RIPE NCC Registration Services

1 0

Cleaning up Unused AS Numbers
by Sander Steffann 19 Apr '17

19 Apr '17

Hi working group, After reviewing the discussions on this mailing list about cleaning up unused AS numbers we think that the concerns and questions that came up have been addressed by the RIPE NCC. Therefore the working group chairs have asked the RIPE NCC to take the feedback into account and proceed with the cleanup. Cheers, Sander Steffann APWG co-chair

1 0

FYI: policy proposal in AFRINIC
by Shane Kerr 14 Apr '17

14 Apr '17

All, This just crossed my news feeds: https://www.theregister.co.uk/2017/04/12/no_ip_addresses_for_countries/ Cheers, -- Shane

3 2

Password
by Stephen Balogh 09 Apr '17

09 Apr '17

Need password

5 4

Cleaning up Unused AS Numbers
by Laurens Hoogendoorn 05 Apr '17

05 Apr '17

Dear colleagues, As previously mentioned at RIPE 73, we are planning a project to clean up unused AS Numbers. You can find this presentation here: https://ripe73.ripe.net/archives/video/1456/ According to ripe-679, "Autonomous System (AS) Number Assignment Policies" if an organisation no longer uses as AS Number, it should be returned to the free pool so it can be reassigned: https://www.ripe.net/publications/docs/ripe-679 There are currently around 6,600 ASNs in our service region (held or sponsored by 2,682 LIRs) that are not being advertised in the routing system. This represents around 22% of the ~30,000 ASNs assigned by the RIPE NCC. There are a number of legitimate reasons why an ASN might not be advertised in the routing system. However, it is also possible that the holder doesn't exist anymore or the ASN is no longer needed. Not only should unused ASNs be returned, but it's important to clean up out of date registrations, which affect the quality of data in the RIPE Registry. Our Proposal We plan to email the LIR or sponsoring LIR for each unannounced ASN and ask if the resource is still needed. We will group together ASNs that are sponsored or held by the same LIR to minimise the number of emails. We will ask if the ASN is currently being used or if there are plans to start using the ASN in the coming three months. Organisations can always request a new ASN in the future if they need one. If we do not receive a reply or if the ASN will not be used within three months, we will start the process of returning the ASN to the free pool. The deregistration process will take three months, during which time the LIR can still indicate that the ASN is needed. If the ASN is still needed, the validity of the assignment (such as the multihoming requirement) will not be re-evaluated. We do not expect any significant cost or impact on other services, as most of this process will be automated and we will not need to re-evaluate the assignments. Contacting all relevant LIRs will take less than six months. Please review this proposal and send any comments or other feedback before Thursday 6 April to <address-policy-wg(a)ripe.net>. Regards, Laurens Hoogendoorn Registration Services RIPE NCC

10 11