From gert at space.net Fri Mar 10 09:00:07 2017 From: gert at space.net (Gert Doering) Date: Fri, 10 Mar 2017 09:00:07 +0100 Subject: [address-policy-wg] 2015-04 Proposal Accepted - "RIPE Resource Transfer Policies" In-Reply-To: References: Message-ID: <20170310080007.GA71048@Space.Net> Dear AP WG, On Wed, Feb 08, 2017 at 01:43:09PM +0100, Marco Schmidt wrote: > Proposal 2015-04, "RIPE Resource Transfer Policies", is now in Concluding Phase. [..] > Any objection must be made by 9 March 2017 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. [..] The Last Call phase is now over. One comment from Alexsey was received and answered, which was not an objection to our following the PDP, or a new objection to the proposal itself. No other comments were received, which *in Last Call* is considered "consent". Thus, I hereby declare consensus on 2015-04 (Sander still abstains). If you disagree with this decision please contact the working group chairs (preferably on this public mailing list and otherwise by sending mail to apwg-chairs at ripe.net). Should that not resolve the problem then you can appeal to the WG chairs collective (as per section 4 of ripe-642). Marco will send the formal announcement from the NCC soon. regards, Gert Doering -- APWG Chair -- 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 gert at space.net Fri Mar 10 09:21:08 2017 From: gert at space.net (Gert Doering) Date: Fri, 10 Mar 2017 09:21:08 +0100 Subject: [address-policy-wg] WG chair rotation Message-ID: <20170310082108.GR2367@Space.Net> Dear AP WG, as per the WG chair policy we gave us, the WG chairs are appointed for a two year duty, and then have to step down (and can be re-appointed). https://www.ripe.net/participate/ripe/wg/ap https://www.ripe.net/participate/ripe/wg/ap/address-policy-wg-chair-selection-process This year, it's my term to step down. Which I will do at the upcoming RIPE meeting - and Sander as remaining chair will oversee the selection of a new WG chair. I am happy and willing to serve another term, so there's already one candidate for your consideration :-) Gert Doering -- APWG chair -- 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 sander at steffann.nl Sun Mar 12 15:17:40 2017 From: sander at steffann.nl (Sander Steffann) Date: Sun, 12 Mar 2017 15:17:40 +0100 Subject: [address-policy-wg] WG chair rotation - call for volunteers Message-ID: <88822D35-7637-4EAC-967F-5BDFD3D55ED5@steffann.nl> Hello working group, As per the WG chair policy we gave us, the WG chairs are appointed for a two year duty, and then have to step down (and can be re-appointed). https://www.ripe.net/participate/ripe/wg/ap https://www.ripe.net/participate/ripe/wg/ap/address-policy-wg-chair-selection-process It is Gert's turn to step down, and he has announced he will do this at the upcoming RIPE meeting. This means we have an empty position and are looking for volunteers to step forward. The job description and responsibilities are documented in https://www.ripe.net/publications/docs/ripe-542. Gert has indicated that he is volunteering to serve another term, so we already have one candidate for the empty position. But don't let that deter you from volunteering! If you have any questions about what it means to be a working group chair then please contact us and we'll prepare you as good as we can. And if you want to volunteer and be eligible for selection at the upcoming RIPE meeting then please state so on the mailing list along with a short introduction for those of us that don't know you yet. Cheers, Sander Steffann APWG co-chair -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: Message signed with OpenPGP using GPGMail URL: From gert at space.net Mon Mar 13 14:59:30 2017 From: gert at space.net (Gert Doering) Date: Mon, 13 Mar 2017 14:59:30 +0100 Subject: [address-policy-wg] WG chair rotation - call for volunteers In-Reply-To: <88822D35-7637-4EAC-967F-5BDFD3D55ED5@steffann.nl> References: <88822D35-7637-4EAC-967F-5BDFD3D55ED5@steffann.nl> Message-ID: <20170313135930.GS2367@Space.Net> Hi, On Sun, Mar 12, 2017 at 03:17:40PM +0100, Sander Steffann wrote: > It is Gert's turn to step down, and he has announced he will do this at the upcoming RIPE meeting. This means we have an empty position and are looking for volunteers to step forward. The job description and responsibilities are documented in https://www.ripe.net/publications/docs/ripe-542. > > Gert has indicated that he is volunteering to serve another term, Right. So, I hereby volunteer for another two-year term (and after that, I'll probably retire as a WG chair, so this is the start of a hopefully smooth transition to new chairpeople...). As a matter of introduction, I'll just lazily copy-paste from the mail I sent about two years ago, and just adjust the dates... Gert Doering * age 45 * shoe size 47, preferrably wearing sandals * university diploma in physics, but into networking since about 24 years * the ISP I work for is SpaceNet, AS5539 - a regional ISP in Munich, DE, who provides mostly "datacenter" and "managed hosting" services these days (but used to provide access, so I know both sides of the medal) * hands-on-geek - network, peering, unix admin - and long-time LIR contact, so I know both the operational side of "IP networks" and the bureaucracy side of "I want a Class C network!" - "here's a /29" haggling. * attending RIPE meetings since RIPE 24 in Berlin, 1996 (missing two since then, Dublin I and Prague II) * address policy working group co-chair since RIPE 44 in Amsterdam, 2003 (https://www.ripe.net/ripe/meetings/ripe-meetings/ripe-44/meeting-report) - then still called the "LIR working group". My plans for the WG are mostly the same as I did in the previous years - help shape address policies for the RIPE region that are workable for all affected users, and do so in a hopefully neutral and construtive way. Further, facilitate a constructive dialogue between the RIPE NCC and the RIPE community regarding address policy issues. (I *still* do expect the WG to eventually wind down, as we seem to have reached the point where IPv4 policies do not succeed anymore due to too vastly conflicting interests, and IPv6 policies seem to be "good enough" for most cases, so the occasional tweak here and there... we'll see :-) ) Gert Doering -- me -- 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 mschmidt at ripe.net Tue Mar 14 14:29:35 2017 From: mschmidt at ripe.net (Marco Schmidt) Date: Tue, 14 Mar 2017 14:29:35 +0100 Subject: [address-policy-wg] 2015-04 Proposal Accepted (RIPE Resource Transfer Policies) Message-ID: Dear colleagues, Consensus has been reached on 2015-04, "RIPE Resource Transfer Policies". This policy change created a single policy document with all relevant information on the transfer of Internet number resources, replacing text in several RIPE Policies. The policy change also introduces a 24-month holding period for IPv4 addresses and 16-bit ASNs after any change of holdership. You can find the full proposal at: https://www.ripe.net/participate/policies/proposals/2015-04 The new RIPE Document is ripe-682, "RIPE Resource Transfer Policies" and is available at: https://www.ripe.net/publications/docs/ripe-682 The following RIPE policies haven been updated as well and received a new document number: ripe-679, "Autonomous System (AS) Number Assignment Policies" https://www.ripe.net/publications/docs/ripe-679 ripe-680, "IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region" https://www.ripe.net/publications/docs/ripe-680 ripe-681, "IPv6 Address Allocation and Assignment Policy" https://www.ripe.net/publications/docs/ripe-681 The following RIPE policy has been marked as obsolete and replaced by ripe-682: ripe-644, "Policy for Inter-RIR Transfers of Internet Resources" We estimate that this proposal will take around three months to fully implement. In order to ensure a correct and consistent handling of requests, the current procedures remain in place until the implementation is completed. This applies in particular to transfers of IPv4 and 16-bit ASNs. Details of the implementation status are available at: https://www.ripe.net/manage-ips-and-asns/resource-management/policy-implementation-status We will send another announcement once the implementation is complete and the new procedures are in place. Thank you to everyone who provided input. Kind regards, Marco Schmidt Policy Development Officer RIPE NCC Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum From ebais at a2b-internet.com Thu Mar 16 12:06:00 2017 From: ebais at a2b-internet.com (Erik Bais) Date: Thu, 16 Mar 2017 12:06:00 +0100 Subject: [address-policy-wg] 2015-04 Proposal Accepted (RIPE Resource Transfer Policies) In-Reply-To: References: Message-ID: <00b401d29e45$4e4c21f0$eae465d0$@a2b-internet.com> Dear Marco & Gert, Thanks for monitoring the process and the assistance in getting this sorted. Looking forward to the implementation. Kind regards, Erik Bais A2B Internet -----Oorspronkelijk bericht----- Van: address-policy-wg [mailto:address-policy-wg-bounces at ripe.net] Namens Marco Schmidt Verzonden: dinsdag 14 maart 2017 14:30 Aan: address-policy-wg at ripe.net Onderwerp: [address-policy-wg] 2015-04 Proposal Accepted (RIPE Resource Transfer Policies) Dear colleagues, Consensus has been reached on 2015-04, "RIPE Resource Transfer Policies". This policy change created a single policy document with all relevant information on the transfer of Internet number resources, replacing text in several RIPE Policies. The policy change also introduces a 24-month holding period for IPv4 addresses and 16-bit ASNs after any change of holdership. You can find the full proposal at: https://www.ripe.net/participate/policies/proposals/2015-04 The new RIPE Document is ripe-682, "RIPE Resource Transfer Policies" and is available at: https://www.ripe.net/publications/docs/ripe-682 The following RIPE policies haven been updated as well and received a new document number: ripe-679, "Autonomous System (AS) Number Assignment Policies" https://www.ripe.net/publications/docs/ripe-679 ripe-680, "IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region" https://www.ripe.net/publications/docs/ripe-680 ripe-681, "IPv6 Address Allocation and Assignment Policy" https://www.ripe.net/publications/docs/ripe-681 The following RIPE policy has been marked as obsolete and replaced by ripe-682: ripe-644, "Policy for Inter-RIR Transfers of Internet Resources" We estimate that this proposal will take around three months to fully implement. In order to ensure a correct and consistent handling of requests, the current procedures remain in place until the implementation is completed. This applies in particular to transfers of IPv4 and 16-bit ASNs. Details of the implementation status are available at: https://www.ripe.net/manage-ips-and-asns/resource-management/policy-implemen tation-status We will send another announcement once the implementation is complete and the new procedures are in place. Thank you to everyone who provided input. Kind regards, Marco Schmidt Policy Development Officer RIPE NCC Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum From gert at space.net Mon Mar 20 14:15:37 2017 From: gert at space.net (Gert Doering) Date: Mon, 20 Mar 2017 14:15:37 +0100 Subject: [address-policy-wg] RIPE 74 APWG agenda, draft 0.1 Message-ID: <20170320131537.GA62839@Space.Net> Hi APWG folks, below you can find a 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 :-) regards, Gert Doering & Sander Steffann, APWG chairs ---------------------------------------------------------------------- Wednesday, 09:00-10:30 ---------------------------------------------------------------------- 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) F. Discussion of open policy proposals 20 min (more specifically: presentation on the status of the open policy proposals and Q&A, discussion will take place on the list) 2016-04 IPv6 PI Sub-assignment Clarification Maximilian Wilhelm ---------------------------------------------------------------------- Wednesday, 12:00-13:30 ---------------------------------------------------------------------- Welcome back 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 -- 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 Laurens.Hoogendoorn at ripe.net Thu Mar 23 13:18:32 2017 From: Laurens.Hoogendoorn at ripe.net (Laurens Hoogendoorn) Date: Thu, 23 Mar 2017 13:18:32 +0100 Subject: [address-policy-wg] Cleaning up Unused AS Numbers Message-ID: <9570203a-051f-0c92-64c9-41713110a2c5@ripe.net> 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 . Regards, Laurens Hoogendoorn Registration Services RIPE NCC -------------- next part -------------- An HTML attachment was scrubbed... URL: From fransossen at yahoo.com Thu Mar 23 15:53:27 2017 From: fransossen at yahoo.com (fransossen at yahoo.com) Date: Thu, 23 Mar 2017 14:53:27 +0000 (UTC) Subject: [address-policy-wg] Cleaning up Unused AS Numbers References: <1714652745.1189063.1490280807590.ref@mail.yahoo.com> Message-ID: <1714652745.1189063.1490280807590@mail.yahoo.com> Hi, Good plan. Will there be any measures put in place so that mass clean ups like that won't be needed? Meaning catching them earlier on in the process. In the internal processing side, will the RIPE NCC flag the ASNs that are justifiably not publicly visible. So that they don't get asked the same question every couple of months? Cheers, David -------------------------------------------- On Thu, 3/23/17, Laurens Hoogendoorn wrote: Subject: [address-policy-wg] Cleaning up Unused AS Numbers To: "address-policy-wg at ripe.net" Date: Thursday, March 23, 2017, 12:18 PM 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 . Regards, Laurens Hoogendoorn Registration Services RIPE NCC From gert at space.net Thu Mar 23 17:35:19 2017 From: gert at space.net (Gert Doering) Date: Thu, 23 Mar 2017 17:35:19 +0100 Subject: [address-policy-wg] Cleaning up Unused AS Numbers In-Reply-To: <1714652745.1189063.1490280807590@mail.yahoo.com> References: <1714652745.1189063.1490280807590.ref@mail.yahoo.com> <1714652745.1189063.1490280807590@mail.yahoo.com> Message-ID: <20170323163519.GH2367@Space.Net> Hi, On Thu, Mar 23, 2017 at 02:53:27PM +0000, fransossen at yahoo.com wrote: > In the internal processing side, will the RIPE NCC flag the ASNs that are justifiably not publicly visible. > So that they don't get asked the same question every couple of months? Well, if they keep being not publically visible, maybe they *should* be asked regularily if they are *still* in use? For the same reason we're asking today - setups have changed, people and companies cease to exist, stuff starts being no longer used. (I wouldn't ask "every couple of months", though, maybe "every few years" - but that's for the community to decide, in the end) Gert Doering -- APWG chair -- 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 hank at efes.iucc.ac.il Thu Mar 23 18:26:16 2017 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Thu, 23 Mar 2017 19:26:16 +0200 Subject: [address-policy-wg] Cleaning up Unused AS Numbers In-Reply-To: <9570203a-051f-0c92-64c9-41713110a2c5@ripe.net> References: <9570203a-051f-0c92-64c9-41713110a2c5@ripe.net> Message-ID: <70c81c4b-6f95-8d42-5c7e-95bed5df8ae6@efes.iucc.ac.il> On 23/03/2017 14:18, Laurens Hoogendoorn wrote: > > 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. > Very often, companies get bought or merge and then get bought out again. A company that received an ASN 15 years ago and hasn't updated their whois and isn't announcing the ASN will be difficult to track down. Might I suggest a further option: if you do not receive a response within 3 months, that you attempt to contact the national default contact. For example, I volunteer to be the national default contact for *.il. I am sure there are others that know all or most ASNs in their specific countries and would be willing to assist to track down the rightful owner if they still exist. Regards, Hank > > > 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 . > > Regards, > > Laurens Hoogendoorn > Registration Services > RIPE NCC > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ripe-wgs at radu-adrian.feurdean.net Thu Mar 23 18:35:26 2017 From: ripe-wgs at radu-adrian.feurdean.net (Radu-Adrian FEURDEAN) Date: Thu, 23 Mar 2017 18:35:26 +0100 Subject: [address-policy-wg] Cleaning up Unused AS Numbers In-Reply-To: <20170323163519.GH2367@Space.Net> References: <1714652745.1189063.1490280807590.ref@mail.yahoo.com> <1714652745.1189063.1490280807590@mail.yahoo.com> <20170323163519.GH2367@Space.Net> Message-ID: <1490290526.2037094.921280416.136004D2@webmail.messagingengine.com> Hi, On Thu, Mar 23, 2017, at 17:35, Gert Doering wrote: > Well, if they keep being not publically visible, maybe they *should* > be asked regularily if they are *still* in use? .... > (I wouldn't ask "every couple of months", though, maybe "every few > years" - but that's for the community to decide, in the end) Several years would be OK, given that some set-ups use ASNs outside of the GRT on the long (even "very long") term (PPPoL2TP aggregation from incumbent, other ugly things that some people consider to be the norm). -- Radu-Adrian FEURDEAN From ripe-wgs at radu-adrian.feurdean.net Thu Mar 23 18:38:26 2017 From: ripe-wgs at radu-adrian.feurdean.net (Radu-Adrian FEURDEAN) Date: Thu, 23 Mar 2017 18:38:26 +0100 Subject: [address-policy-wg] Cleaning up Unused AS Numbers In-Reply-To: <70c81c4b-6f95-8d42-5c7e-95bed5df8ae6@efes.iucc.ac.il> References: <9570203a-051f-0c92-64c9-41713110a2c5@ripe.net> <70c81c4b-6f95-8d42-5c7e-95bed5df8ae6@efes.iucc.ac.il> Message-ID: <1490290706.2037830.921287240.1B9F0F82@webmail.messagingengine.com> On Thu, Mar 23, 2017, at 18:26, Hank Nussbacher wrote: > Might I suggest a further option: if you do not receive a response > within 3 months, that you attempt to contact the national default > contact. ... or make the list of such cases public, rather than ask a given entity that may have his/hers/its own agenda.... -- Radu-Adrian FEURDEAN From hunekm at gmail.com Thu Mar 23 19:34:05 2017 From: hunekm at gmail.com (Martin =?utf-8?B?SHVuxJtr?=) Date: Thu, 23 Mar 2017 19:34:05 +0100 Subject: [address-policy-wg] Cleaning up Unused AS Numbers In-Reply-To: <20170323163519.GH2367@Space.Net> References: <1714652745.1189063.1490280807590.ref@mail.yahoo.com> <1714652745.1189063.1490280807590@mail.yahoo.com> <20170323163519.GH2367@Space.Net> Message-ID: <4386755.pjWc2apoCa@hunator-ntb.site> Hi, So why don't do some "hidden" flag part of asnum object? Let say that, end user (MNT) would be able to indicate that ASN should be hidden from the BGP and provide remarks for a reason (IXP or whatever) - mandatory. If such ASN would be observed in the BGP, the hidden flag would be unset and LIR/holder would be notified. When there would be the ASN which would not be seen for more that 3 months and would have the "hidden" flag unset, the deregistation process (as in proposal - ask, wait, deregister) could be started. The holders of "hidden" ASNs could be then asked about their need of such ASN with longer period and also be notified when the ASN emerges somewhere when it shouldn't. This would address issues of: - Inactive holder: Requires action to set ASN as hidden - Hijack: When so, holder would get notified (after hijack ends the ASN would expire if holder doesn't exist anymore) - Provides mandatory feedback by remarks of reason why it is not announced - Provide a way how to prolongate period of asking if the ASN is needed by adding other means then pooling - Maybe provide yet another way of filtering of BGP path (hidden ASN should not be present there), however for such use it would had to become some kind of standard across RIRs It might bring issue of intentional attack on such flag by announcing such ASN and trigger the timer. There should be some period for which the ASN should be observed in BGP to trigger the process to partially mitigate such vector of attack and possible mishaps. Best Regards Martin Hunek Dne ?tvrtek 23. b?ezna 2017 17:35:19 CET, Gert Doering napsal(a): > Hi, > > On Thu, Mar 23, 2017 at 02:53:27PM +0000, fransossen at yahoo.com wrote: > > In the internal processing side, will the RIPE NCC flag the ASNs that are > > justifiably not publicly visible. So that they don't get asked the same > > question every couple of months? > Well, if they keep being not publically visible, maybe they *should* > be asked regularily if they are *still* in use? > > For the same reason we're asking today - setups have changed, people > and companies cease to exist, stuff starts being no longer used. > > (I wouldn't ask "every couple of months", though, maybe "every few > years" - but that's for the community to decide, in the end) > > Gert Doering > -- APWG chair -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: This is a digitally signed message part. URL: From apwg at c4inet.net Thu Mar 23 23:41:43 2017 From: apwg at c4inet.net (Sascha Luck [ml]) Date: Thu, 23 Mar 2017 22:41:43 +0000 Subject: [address-policy-wg] Cleaning up Unused AS Numbers In-Reply-To: <4386755.pjWc2apoCa@hunator-ntb.site> References: <1714652745.1189063.1490280807590.ref@mail.yahoo.com> <1714652745.1189063.1490280807590@mail.yahoo.com> <20170323163519.GH2367@Space.Net> <4386755.pjWc2apoCa@hunator-ntb.site> Message-ID: <20170323224143.GV93886@cilantro.c4inet.net> On Thu, Mar 23, 2017 at 07:34:05PM +0100, Martin Hun?k wrote: >So why don't do some "hidden" flag part of asnum object? > >Let say that, end user (MNT) would be able to indicate that ASN >should be hidden from the BGP and provide remarks for a reason >(IXP or whatever) - mandatory. If such ASN would be observed in >the BGP, the hidden flag would be unset and LIR/holder would be >notified. What purpose would that serve apart from satisfying idle curiosity? The reasons why an ASN is not advertised are of concern only to the operator of that ASN. rgds, Sascha Luck From apwg at c4inet.net Thu Mar 23 23:49:41 2017 From: apwg at c4inet.net (Sascha Luck [ml]) Date: Thu, 23 Mar 2017 22:49:41 +0000 Subject: [address-policy-wg] Cleaning up Unused AS Numbers In-Reply-To: <1490290706.2037830.921287240.1B9F0F82@webmail.messagingengine.com> References: <9570203a-051f-0c92-64c9-41713110a2c5@ripe.net> <70c81c4b-6f95-8d42-5c7e-95bed5df8ae6@efes.iucc.ac.il> <1490290706.2037830.921287240.1B9F0F82@webmail.messagingengine.com> Message-ID: <20170323224941.GW93886@cilantro.c4inet.net> On Thu, Mar 23, 2017 at 06:38:26PM +0100, Radu-Adrian FEURDEAN wrote: > >... or make the list of such cases public, rather than ask a given >entity that may have his/hers/its own agenda.... I think this idea has merit. a page that lists "lost" ASNs. Possible downside is that some randomer could claim to "own" it but it may be possible for the NCC to establish whether they have a right to it. rgds, Sascha Luck From apwg at c4inet.net Thu Mar 23 23:51:23 2017 From: apwg at c4inet.net (Sascha Luck [ml]) Date: Thu, 23 Mar 2017 22:51:23 +0000 Subject: [address-policy-wg] Cleaning up Unused AS Numbers In-Reply-To: <20170323224941.GW93886@cilantro.c4inet.net> References: <9570203a-051f-0c92-64c9-41713110a2c5@ripe.net> <70c81c4b-6f95-8d42-5c7e-95bed5df8ae6@efes.iucc.ac.il> <1490290706.2037830.921287240.1B9F0F82@webmail.messagingengine.com> <20170323224941.GW93886@cilantro.c4inet.net> Message-ID: <20170323225123.GX93886@cilantro.c4inet.net> On Thu, Mar 23, 2017 at 10:49:41PM +0000, Sascha Luck [ml] wrote: >I think this idea has merit. a page that lists "lost" ASNs. >Possible downside is that some randomer could claim to "own" it >but it may be possible for the NCC to establish whether they have >a right to it. just an addendum: if nobody claims it after $time, de-register it, of course. rgds, Sascha Luck > > > From elvis at velea.eu Thu Mar 23 23:58:22 2017 From: elvis at velea.eu (Elvis Daniel Velea) Date: Thu, 23 Mar 2017 15:58:22 -0700 Subject: [address-policy-wg] Cleaning up Unused AS Numbers In-Reply-To: <9570203a-051f-0c92-64c9-41713110a2c5@ripe.net> References: <9570203a-051f-0c92-64c9-41713110a2c5@ripe.net> Message-ID: Hi Laurens, the plan below looks fine. Please go ahead. I've got a question about the ~300 reserved 16bit ASNs (as per the delegated extended file). Does the RIPE NCC have any plan to bring these into production as well? Kind regards, Elvis On 3/23/17 5:18 AM, Laurens Hoogendoorn wrote: > > > 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 . > > Regards, > > Laurens Hoogendoorn > Registration Services > RIPE NCC > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wusel+ml at uu.org Fri Mar 24 02:32:35 2017 From: wusel+ml at uu.org (Kai 'wusel' Siering) Date: Fri, 24 Mar 2017 02:32:35 +0100 Subject: [address-policy-wg] Cleaning up Unused AS Numbers In-Reply-To: <4386755.pjWc2apoCa@hunator-ntb.site> References: <1714652745.1189063.1490280807590.ref@mail.yahoo.com> <1714652745.1189063.1490280807590@mail.yahoo.com> <20170323163519.GH2367@Space.Net> <4386755.pjWc2apoCa@hunator-ntb.site> Message-ID: <61c5af5d-b406-265a-4d29-e52fca4a954f@uu.org> Moin, am 23.03.2017 um 19:34 schrieb Martin Hun?k: > Let say that, end user (MNT) would be able to indicate that ASN should be hidden from the BGP and provide remarks for a reason (IXP or whatever) - mandatory. Sorry, but as a public ASN is to serve public inter-AS-uses, why even think about private usage of a public resource? If you use a public AS internally only, you should switch to a private AS. Am 23.03.2017 um 18:26 schrieb Hank Nussbacher: > On 23/03/2017 14:18, Laurens Hoogendoorn wrote: >> Our Proposal >> [?] >> > Very often, companies get bought or merge and then get bought out again. > A company that received an ASN 15 years ago and hasn't updated their whois and isn't announcing the ASN will be difficult to track down. Well, so what? If the ASN isn't used where it counts, why should it stay assigned to an organization that clearly doesn't care at all (or, for that matter, exists)? Am 23.03.2017 um 13:18 schrieb Laurens Hoogendoorn: > There are a number of legitimate reasons why an ASN might not be advertised in the routing system. Care to list at least a few? https://www.ripe.net/publications/docs/ripe-679 looks rather straightforward ? and against hidden usage of assigned ASNs? > > 2.0 Assignment Criteria > > In order to help decrease global routing complexity, a new AS Number should be used only if a new external routing policy is required, see RFC1930 . > > A network must be multihomed in order to qualify for an AS Number. > > When requesting an AS Number the routing policy of the Autonomous System must be provided. The new unique routing policy should be defined in RPSL language, as used in the RIPE Database. > So, you need a "new" *external* routing policy to receive a (public) ASN. If your ASN does not show up in the global routing anymore, you obviously lost the need for that '"new" *external* routing policy', no? While I don't see any need to reclaim "virtually unused" ASNs since the protocol got extended to 32 bits, I don't see why there should be any fuzz about those ASNs not seen in the public routing tables either. Define January 1st and July 1st of each year as checkpoint dates, if an ASN isn't present in global routing of IPv4 and IPv6 on two consecutive checkpoint dates, it's scheduled for unassignment after the next checkpoint date. Send out appropriate information based on whois data *once*, put the AS on a red list on the RIPE website for these six months. No reaction: it's free to go, end of story. Regards, -kai -------------- next part -------------- An HTML attachment was scrubbed... URL: From lists at velder.li Fri Mar 24 08:02:48 2017 From: lists at velder.li (Patrick Velder) Date: Fri, 24 Mar 2017 08:02:48 +0100 Subject: [address-policy-wg] Cleaning up Unused AS Numbers In-Reply-To: <9570203a-051f-0c92-64c9-41713110a2c5@ripe.net> References: <9570203a-051f-0c92-64c9-41713110a2c5@ripe.net> Message-ID: <61853839-bca9-0b38-b14f-053ac1645169@velder.li> Hi, +1. Please do the same for IPv4 space ;-) Regards Patrick On 23.03.2017 13:18, Laurens Hoogendoorn wrote: > > > 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 . > > Regards, > > Laurens Hoogendoorn > Registration Services > RIPE NCC > -------------- next part -------------- An HTML attachment was scrubbed... URL: From richih.mailinglist at gmail.com Fri Mar 24 08:30:14 2017 From: richih.mailinglist at gmail.com (Richard Hartmann) Date: Fri, 24 Mar 2017 08:30:14 +0100 Subject: [address-policy-wg] Cleaning up Unused AS Numbers In-Reply-To: <9570203a-051f-0c92-64c9-41713110a2c5@ripe.net> References: <9570203a-051f-0c92-64c9-41713110a2c5@ripe.net> Message-ID: Sounds good, as does re-poking every 12-24 months. A public, or semi public, list of resources that have no holder could invite abuse. Don't do that. Richard Sent by mobile; excuse my brevity and the wall of text Gmail appends by default. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gert at space.net Fri Mar 24 09:29:26 2017 From: gert at space.net (Gert Doering) Date: Fri, 24 Mar 2017 09:29:26 +0100 Subject: [address-policy-wg] Cleaning up Unused AS Numbers In-Reply-To: <61853839-bca9-0b38-b14f-053ac1645169@velder.li> References: <9570203a-051f-0c92-64c9-41713110a2c5@ripe.net> <61853839-bca9-0b38-b14f-053ac1645169@velder.li> Message-ID: <20170324082926.GM2367@Space.Net> Hi, On Fri, Mar 24, 2017 at 08:02:48AM +0100, Patrick Velder wrote: > +1. > Please do the same for IPv4 space ;-) For IPv4 space, this is much easier. There is a yearly fee to be paid, so we know exactly whether something is still "in use enough" to warrant the rental fee being paid... (And for legacy space, the RIPE NCC has no mandate or authority to go hunting) Gert Doering -- APWG chair -- 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 fransossen at yahoo.com Fri Mar 24 10:12:20 2017 From: fransossen at yahoo.com (fransossen at yahoo.com) Date: Fri, 24 Mar 2017 09:12:20 +0000 (UTC) Subject: [address-policy-wg] Cleaning up Unused AS Numbers References: <1794548480.2862904.1490346740269.ref@mail.yahoo.com> Message-ID: <1794548480.2862904.1490346740269@mail.yahoo.com> The every couple of months thing is the problem. I actually see no reason in asking again other than when the LIR gets ARC'ed. Having a fee would also had help prune off some of the dead ASNs. Cheers, David -------------------------------------------- On Thu, 3/23/17, Gert Doering wrote: Subject: Re: [address-policy-wg] Cleaning up Unused AS Numbers To: fransossen at yahoo.com Cc: "address-policy-wg at ripe.net" Date: Thursday, March 23, 2017, 4:35 PM Hi, On Thu, Mar 23, 2017 at 02:53:27PM +0000, fransossen at yahoo.com wrote: > In the internal processing side, will the RIPE NCC flag the ASNs that are justifiably not publicly visible. > So that they don't get asked the same question every couple of months? Well, if they keep being not publically visible, maybe they *should* be asked regularily if they are *still* in use? For the same reason we're asking today - setups have changed, people and companies cease to exist, stuff starts being no longer used. (I wouldn't ask "every couple of months", though, maybe "every few years" - but that's for the community to decide, in the end) Gert Doering ? ? ? ? -- APWG chair -- 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 From Ian.Dickinson at sky.uk Fri Mar 24 11:29:22 2017 From: Ian.Dickinson at sky.uk (Dickinson, Ian) Date: Fri, 24 Mar 2017 10:29:22 +0000 Subject: [address-policy-wg] Cleaning up Unused AS Numbers In-Reply-To: <61c5af5d-b406-265a-4d29-e52fca4a954f@uu.org> References: <1714652745.1189063.1490280807590.ref@mail.yahoo.com> <1714652745.1189063.1490280807590@mail.yahoo.com> <20170323163519.GH2367@Space.Net> <4386755.pjWc2apoCa@hunator-ntb.site> <61c5af5d-b406-265a-4d29-e52fca4a954f@uu.org> Message-ID: <9B3BFE0A18160E40BAF1950414D10FAE89863639@WPMBX010.bskyb.com> Hi, Requiring an ASN to be visible on the public Internet is a non-starter IMHO. There are many instances of inter-provider EBGP that are non-public, where private ASNs are not appropriate. For example, more than one of the providers uses one or more private ASNs internally that clash with each other. Global identifiers are the usual approach for this situation, and I see no reason to change that. The same situation applies to the use of public IP address resources in inter-provider scenarios, such as L3VPNs, and has had no problem with justification to acquire or retain those resources ? ASNs should be no different. Fundamentally, please don?t mix up lack of public visibility meaning either lack of need or purely internal use, because it?s an overreach. Ian From: address-policy-wg [mailto:address-policy-wg-bounces at ripe.net] On Behalf Of Kai 'wusel' Siering Sent: 24 March 2017 01:33 To: address-policy-wg at ripe.net Subject: Re: [address-policy-wg] Cleaning up Unused AS Numbers Moin, am 23.03.2017 um 19:34 schrieb Martin Hun?k: Let say that, end user (MNT) would be able to indicate that ASN should be hidden from the BGP and provide remarks for a reason (IXP or whatever) - mandatory. Sorry, but as a public ASN is to serve public inter-AS-uses, why even think about private usage of a public resource? If you use a public AS internally only, you should switch to a private AS. Am 23.03.2017 um 18:26 schrieb Hank Nussbacher: On 23/03/2017 14:18, Laurens Hoogendoorn wrote: Our Proposal [?] Very often, companies get bought or merge and then get bought out again. A company that received an ASN 15 years ago and hasn't updated their whois and isn't announcing the ASN will be difficult to track down. Well, so what? If the ASN isn't used where it counts, why should it stay assigned to an organization that clearly doesn't care at all (or, for that matter, exists)? Am 23.03.2017 um 13:18 schrieb Laurens Hoogendoorn: There are a number of legitimate reasons why an ASN might not be advertised in the routing system. Care to list at least a few? https://www.ripe.net/publications/docs/ripe-679 looks rather straightforward ? and against hidden usage of assigned ASNs? 2.0 Assignment Criteria In order to help decrease global routing complexity, a new AS Number should be used only if a new external routing policy is required, see RFC1930. A network must be multihomed in order to qualify for an AS Number. When requesting an AS Number the routing policy of the Autonomous System must be provided. The new unique routing policy should be defined in RPSL language, as used in the RIPE Database. So, you need a "new" *external* routing policy to receive a (public) ASN. If your ASN does not show up in the global routing anymore, you obviously lost the need for that '"new" *external* routing policy', no? While I don't see any need to reclaim "virtually unused" ASNs since the protocol got extended to 32 bits, I don't see why there should be any fuzz about those ASNs not seen in the public routing tables either. Define January 1st and July 1st of each year as checkpoint dates, if an ASN isn't present in global routing of IPv4 and IPv6 on two consecutive checkpoint dates, it's scheduled for unassignment after the next checkpoint date. Send out appropriate information based on whois data *once*, put the AS on a red list on the RIPE website for these six months. No reaction: it's free to go, end of story. Regards, -kai Information in this email including any attachments may be privileged, confidential and is intended exclusively for the addressee. The views expressed may not be official policy, but the personal views of the originator. If you have received it in error, please notify the sender by return e-mail and delete it from your system. You should not reproduce, distribute, store, retransmit, use or disclose its contents to anyone. Please note we reserve the right to monitor all e-mail communication through our internal and external networks. SKY and the SKY marks are trademarks of Sky plc and Sky International AG and are used under licence. Sky UK Limited (Registration No. 2906991), Sky-In-Home Service Limited (Registration No. 2067075) and Sky Subscribers Services Limited (Registration No. 2340150) are direct or indirect subsidiaries of Sky plc (Registration No. 2247735). All of the companies mentioned in this paragraph are incorporated in England and Wales and share the same registered office at Grant Way, Isleworth, Middlesex TW7 5QD. From jim at rfc1035.com Fri Mar 24 11:43:51 2017 From: jim at rfc1035.com (Jim Reid) Date: Fri, 24 Mar 2017 10:43:51 +0000 Subject: [address-policy-wg] Cleaning up Unused AS Numbers In-Reply-To: <9B3BFE0A18160E40BAF1950414D10FAE89863639@WPMBX010.bskyb.com> References: <1714652745.1189063.1490280807590.ref@mail.yahoo.com> <1714652745.1189063.1490280807590@mail.yahoo.com> <20170323163519.GH2367@Space.Net> <4386755.pjWc2apoCa@hunator-ntb.site> <61c5af5d-b406-265a-4d29-e52fca4a954f@uu.org> <9B3BFE0A18160E40BAF1950414D10FAE89863639@WPMBX010.bskyb.com> Message-ID: > On 24 Mar 2017, at 10:29, Dickinson, Ian wrote: > > Requiring an ASN to be visible on the public Internet is a non-starter IMHO. +1. There is no comparable requirement in any of the RIRs which demand LIRs make their IP address allocations visible on the Internet. I fail to understand why this obligation should apply to ASNs. It?s not as if we?ll be running out of AS numbers any time soon. What are the actual (or perceived?) problems that would be solved by reclaiming the ASNs that are not seen in the Internet?s routing tables? From aled.w.morris at googlemail.com Fri Mar 24 12:02:26 2017 From: aled.w.morris at googlemail.com (Aled Morris) Date: Fri, 24 Mar 2017 11:02:26 +0000 Subject: [address-policy-wg] Cleaning up Unused AS Numbers In-Reply-To: References: <1714652745.1189063.1490280807590.ref@mail.yahoo.com> <1714652745.1189063.1490280807590@mail.yahoo.com> <20170323163519.GH2367@Space.Net> <4386755.pjWc2apoCa@hunator-ntb.site> <61c5af5d-b406-265a-4d29-e52fca4a954f@uu.org> <9B3BFE0A18160E40BAF1950414D10FAE89863639@WPMBX010.bskyb.com> Message-ID: On 24 March 2017 at 10:43, Jim Reid wrote: > > > On 24 Mar 2017, at 10:29, Dickinson, Ian wrote: > > > > Requiring an ASN to be visible on the public Internet is a non-starter > IMHO. > > +1. > > There is no comparable requirement in any of the RIRs which demand LIRs > make their IP address allocations visible on the Internet. I fail to > understand why this obligation should apply to ASNs. > > It?s not as if we?ll be running out of AS numbers any time soon. What are > the actual (or perceived?) problems that would be solved by reclaiming the > ASNs that are not seen in the Internet?s routing tables? > +1 from me too. I've worked in many companies where mergers and acquisitions resulted in conflicting "private" addressing schemes. If ASN scarcity was a real problem, it wouldn't be too hard to write an RFC for 128-bit ASNs. Aled -------------- next part -------------- An HTML attachment was scrubbed... URL: From Piotr.Strzyzewski at polsl.pl Fri Mar 24 12:44:50 2017 From: Piotr.Strzyzewski at polsl.pl (Piotr Strzyzewski) Date: Fri, 24 Mar 2017 12:44:50 +0100 Subject: [address-policy-wg] Cleaning up Unused AS Numbers In-Reply-To: References: <1714652745.1189063.1490280807590.ref@mail.yahoo.com> <1714652745.1189063.1490280807590@mail.yahoo.com> <20170323163519.GH2367@Space.Net> <4386755.pjWc2apoCa@hunator-ntb.site> <61c5af5d-b406-265a-4d29-e52fca4a954f@uu.org> <9B3BFE0A18160E40BAF1950414D10FAE89863639@WPMBX010.bskyb.com> Message-ID: <20170324114450.GF12776@hydra.ck.polsl.pl> On Fri, Mar 24, 2017 at 10:43:51AM +0000, Jim Reid wrote: > It???s not as if we???ll be running out of AS numbers any time soon. > What are the actual (or perceived?) problems that would be solved by > reclaiming the ASNs that are not seen in the Internet???s routing > tables? +1 Piotr -- gucio -> Piotr Strzy?ewski E-mail: Piotr.Strzyzewski at polsl.pl From richih.mailinglist at gmail.com Fri Mar 24 13:50:12 2017 From: richih.mailinglist at gmail.com (Richard Hartmann) Date: Fri, 24 Mar 2017 13:50:12 +0100 Subject: [address-policy-wg] Cleaning up Unused AS Numbers In-Reply-To: <9B3BFE0A18160E40BAF1950414D10FAE89863639@WPMBX010.bskyb.com> References: <1714652745.1189063.1490280807590.ref@mail.yahoo.com> <1714652745.1189063.1490280807590@mail.yahoo.com> <20170323163519.GH2367@Space.Net> <4386755.pjWc2apoCa@hunator-ntb.site> <61c5af5d-b406-265a-4d29-e52fca4a954f@uu.org> <9B3BFE0A18160E40BAF1950414D10FAE89863639@WPMBX010.bskyb.com> Message-ID: On Fri, Mar 24, 2017 at 11:29 AM, Dickinson, Ian wrote: > Requiring an ASN to be visible on the public Internet is a non-starter IMHO. There is nor was such a requirement and the proposal in this thread does not introduce such a requirement, either. Richard From hunekm at gmail.com Fri Mar 24 00:15:29 2017 From: hunekm at gmail.com (Martin =?utf-8?B?SHVuxJtr?=) Date: Fri, 24 Mar 2017 00:15:29 +0100 Subject: [address-policy-wg] Cleaning up Unused AS Numbers In-Reply-To: <20170323224143.GV93886@cilantro.c4inet.net> References: <1714652745.1189063.1490280807590.ref@mail.yahoo.com> <4386755.pjWc2apoCa@hunator-ntb.site> <20170323224143.GV93886@cilantro.c4inet.net> Message-ID: <18175457.ZNxtgE4XuT@hunator-ntb.site> > What purpose would that serve apart from satisfying idle > curiosity? > The reasons why an ASN is not advertised are of concern only to > the operator of that ASN. It depends. Is it resposibility of RIR to monitor usage of resources and search for unused ones? If so, there should be some way to tell RIR "This ASN is in use even if you can't see it, it is OK, don't bother me!". From my point of view it is better to track changes of announced -> not-announced and vice versa (when stated that they should not be), then list of all ASN which are not announced. Just because it doesn't carry an information if it is an intentional or not. Turning off such flag automatically would then work as fail-safe for abusing such flag for usual cases when ASN is announced but you would not want RIPE NCC to check on you. If you don't think that RIR should not track usage or resources in its region, then you are right, it would be not needed curiosity. > I think this idea has merit. a page that lists "lost" ASNs. > Possible downside is that some randomer could claim to "own" it but it may be possible for the NCC to establish whether they have a right to it. If you make just a list, apart of the downside you have mentioned, there is possibility that your ASN will get to such list periodically. How would you indicate that you ASN is not announced publicly for a reason? If you are planning making such list in the waves over and over again, it would be fine. Best Regards Martin Hunek -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: This is a digitally signed message part. URL: From richih.mailinglist at gmail.com Fri Mar 24 13:53:35 2017 From: richih.mailinglist at gmail.com (Richard Hartmann) Date: Fri, 24 Mar 2017 13:53:35 +0100 Subject: [address-policy-wg] Cleaning up Unused AS Numbers In-Reply-To: References: <1714652745.1189063.1490280807590.ref@mail.yahoo.com> <1714652745.1189063.1490280807590@mail.yahoo.com> <20170323163519.GH2367@Space.Net> <4386755.pjWc2apoCa@hunator-ntb.site> <61c5af5d-b406-265a-4d29-e52fca4a954f@uu.org> <9B3BFE0A18160E40BAF1950414D10FAE89863639@WPMBX010.bskyb.com> Message-ID: On Fri, Mar 24, 2017 at 11:43 AM, Jim Reid wrote: > There is no comparable requirement in any of the RIRs which demand LIRs make their IP address allocations visible on the Internet. I fail to understand why this obligation should apply to ASNs. It's correct that the RIPE NCC's database is the only one of actual real-world use when trying to track down certain situations, yes. The RIRs are their own distinct entities for a reason. > It?s not as if we?ll be running out of AS numbers any time soon. Correct. > What are the actual (or perceived?) problems that would be solved by reclaiming the ASNs that are not seen in the Internet?s routing tables? As the initial email states, this effort is about improving correctness of the database. To me, this is a goal in and as of itself. Richard From Ian.Dickinson at sky.uk Fri Mar 24 13:55:53 2017 From: Ian.Dickinson at sky.uk (Dickinson, Ian) Date: Fri, 24 Mar 2017 12:55:53 +0000 Subject: [address-policy-wg] Cleaning up Unused AS Numbers In-Reply-To: References: <1714652745.1189063.1490280807590.ref@mail.yahoo.com> <1714652745.1189063.1490280807590@mail.yahoo.com> <20170323163519.GH2367@Space.Net> <4386755.pjWc2apoCa@hunator-ntb.site> <61c5af5d-b406-265a-4d29-e52fca4a954f@uu.org> <9B3BFE0A18160E40BAF1950414D10FAE89863639@WPMBX010.bskyb.com> Message-ID: <9B3BFE0A18160E40BAF1950414D10FAE898637C4@WPMBX010.bskyb.com> Hi Richard, Whilst the original proposal did not (which I am comfortable with), the message I responded to was clearly hinting at this approach. Ian -----Original Message----- From: Richard Hartmann [mailto:richih.mailinglist at gmail.com] Sent: 24 March 2017 12:50 To: Dickinson, Ian Cc: address-policy-wg at ripe.net Subject: Re: [address-policy-wg] Cleaning up Unused AS Numbers On Fri, Mar 24, 2017 at 11:29 AM, Dickinson, Ian wrote: > Requiring an ASN to be visible on the public Internet is a non-starter IMHO. There is nor was such a requirement and the proposal in this thread does not introduce such a requirement, either. Richard Information in this email including any attachments may be privileged, confidential and is intended exclusively for the addressee. The views expressed may not be official policy, but the personal views of the originator. If you have received it in error, please notify the sender by return e-mail and delete it from your system. You should not reproduce, distribute, store, retransmit, use or disclose its contents to anyone. Please note we reserve the right to monitor all e-mail communication through our internal and external networks. SKY and the SKY marks are trademarks of Sky plc and Sky International AG and are used under licence. Sky UK Limited (Registration No. 2906991), Sky-In-Home Service Limited (Registration No. 2067075) and Sky Subscribers Services Limited (Registration No. 2340150) are direct or indirect subsidiaries of Sky plc (Registration No. 2247735). All of the companies mentioned in this paragraph are incorporated in England and Wales and share the same registered office at Grant Way, Isleworth, Middlesex TW7 5QD. From pk at DENIC.DE Fri Mar 24 22:02:31 2017 From: pk at DENIC.DE (Peter Koch) Date: Fri, 24 Mar 2017 22:02:31 +0100 Subject: [address-policy-wg] Cleaning up Unused AS Numbers In-Reply-To: <9570203a-051f-0c92-64c9-41713110a2c5@ripe.net> References: <9570203a-051f-0c92-64c9-41713110a2c5@ripe.net> Message-ID: <20170324210231.GB4336@x27.adm.denic.de> On Thu, Mar 23, 2017 at 01:18:32PM +0100, Laurens Hoogendoorn wrote: > 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. what are the reasons not to approach the admin-c (or tech-c) of that registered ASN? -Peter From dr at cluenet.de Sun Mar 26 22:20:59 2017 From: dr at cluenet.de (Daniel Roesen) Date: Sun, 26 Mar 2017 22:20:59 +0200 Subject: [address-policy-wg] Cleaning up Unused AS Numbers In-Reply-To: <61c5af5d-b406-265a-4d29-e52fca4a954f@uu.org> References: <1714652745.1189063.1490280807590.ref@mail.yahoo.com> <1714652745.1189063.1490280807590@mail.yahoo.com> <20170323163519.GH2367@Space.Net> <4386755.pjWc2apoCa@hunator-ntb.site> <61c5af5d-b406-265a-4d29-e52fca4a954f@uu.org> Message-ID: <20170326202059.GA8602@srv03.cluenet.de> On Fri, Mar 24, 2017 at 02:32:35AM +0100, Kai 'wusel' Siering wrote: > Sorry, but as a public ASN is to serve public inter-AS-uses, Can you cite the policy requiring that? > why even think about private usage of a public resource? If you > use a public AS internally only, you should switch to a private AS. Private ASN are non-unique, and as such pretty much a non-starter in extranet situations. > Care to list at least a few? https://www.ripe.net/publications/docs/ripe-679 > looks rather straightforward ??? and against hidden usage of assigned ASNs? I cannot see any language in this document requiring any kind of "visibility" in any part of whatever network, especially the "Internet". Can you point us to the specific regulation? > So, you need a "new" *external* routing policy to receive a (public) ASN. Yes. You seem to mistake "external" with "on the public Internet". "External" in BGP context is "with other ASN", that's it - not more, not less. > If your ASN does not show up in the global routing anymore, you > obviously lost the need for that '"new" *external* routing policy', > no? No. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From wusel+ml at uu.org Mon Mar 27 01:46:32 2017 From: wusel+ml at uu.org (Kai 'wusel' Siering) Date: Mon, 27 Mar 2017 01:46:32 +0200 Subject: [address-policy-wg] Cleaning up Unused AS Numbers In-Reply-To: <20170326202059.GA8602@srv03.cluenet.de> References: <1714652745.1189063.1490280807590.ref@mail.yahoo.com> <1714652745.1189063.1490280807590@mail.yahoo.com> <20170323163519.GH2367@Space.Net> <4386755.pjWc2apoCa@hunator-ntb.site> <61c5af5d-b406-265a-4d29-e52fca4a954f@uu.org> <20170326202059.GA8602@srv03.cluenet.de> Message-ID: <89e8a45e-6a45-c195-026d-7923eb63a3f8@uu.org> Am 26.03.2017 um 22:20 schrieb Daniel Roesen: > On Fri, Mar 24, 2017 at 02:32:35AM +0100, Kai 'wusel' Siering wrote: > >> Sorry, but as a public ASN is to serve public inter-AS-uses, > Can you cite the policy requiring that? RFC 1930, referenced by ripe-679, states: "10. The Internet Assigned Numbers Authority (IANA) has reserved the following block of AS numbers for private use (not to be advertised on the global Internet): 64512 through 65535". Together with "9. AS Space exhaustion" it disencourages the use of public AS numbers for non-public use. And there is ripe-679' requirement of multihoming. >> So, you need a "new" *external* routing policy to receive a (public) ASN. > Yes. You seem to mistake "external" with "on the public Internet". "External" in BGP context is "with other ASN", that's it - not more, not less. Maybe I do, if so, most likely because of the connection initially drawn, "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" as well as due to the reference to RFC 1930 in ripe-679. >> If your ASN does not show up in the global routing anymore, you obviously lost the need for that '"new" *external* routing policy', no? > No. Best regards, Daniel So, if a connection between "ASN received" and "ASN visible" does not exist, where's the case for this wg? RIPE NCC can carry out a db-based clean up on their own: keeping registration data up-to-date is already a requirement for resource holders (ripe-637). To be more elaborate (quoting the initial mail): > 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 ask if the ASN is currently being used or if there are plans to start using the ASN in the coming three months. [?] Answer a: "um, yes?". Answer b: "definitely no". As investigating to answer b in good faith is always more expensive than to just state a, and since without the need for public visibility there's no means to control the usage: what's the point? > 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. What's the calculated gain, what's the overall benefit, given the limited control (see above)? It's fine that the process is automated on RIPE NCC's end, but LIRs will face additional work. With now 32 bits at hand for AS numbers, what's the operational benefit for the RIPE community as a whole if all "invisible" 6,6k ASNs would be returned after this effort? Especially as RFC 4893 is celebrating it's 10th birthday in a few weeks? Regards, -kai From farmer at umn.edu Mon Mar 27 04:12:54 2017 From: farmer at umn.edu (David Farmer) Date: Sun, 26 Mar 2017 21:12:54 -0500 Subject: [address-policy-wg] Cleaning up Unused AS Numbers In-Reply-To: <89e8a45e-6a45-c195-026d-7923eb63a3f8@uu.org> References: <1714652745.1189063.1490280807590.ref@mail.yahoo.com> <1714652745.1189063.1490280807590@mail.yahoo.com> <20170323163519.GH2367@Space.Net> <4386755.pjWc2apoCa@hunator-ntb.site> <61c5af5d-b406-265a-4d29-e52fca4a954f@uu.org> <20170326202059.GA8602@srv03.cluenet.de> <89e8a45e-6a45-c195-026d-7923eb63a3f8@uu.org> Message-ID: On Sun, Mar 26, 2017 at 6:46 PM, Kai 'wusel' Siering wrote: > Am 26.03.2017 um 22:20 schrieb Daniel Roesen: > > On Fri, Mar 24, 2017 at 02:32:35AM +0100, Kai 'wusel' Siering wrote: > > > >> Sorry, but as a public ASN is to serve public inter-AS-uses, > > Can you cite the policy requiring that? > > RFC 1930, referenced by ripe-679, states: "10. The Internet Assigned > Numbers Authority (IANA) has reserved the following block of AS numbers for > private use (not to be advertised on the global Internet): 64512 through > 65535". Together with "9. AS Space exhaustion" it disencourages the use of > public AS numbers for non-public use. And there is ripe-679' requirement of > multihoming. > > >> So, you need a "new" *external* routing policy to receive a (public) > ASN. > > Yes. You seem to mistake "external" with "on the public Internet". > "External" in BGP context is "with other ASN", that's it - not more, not > less. > > Maybe I do, if so, most likely because of the connection initially drawn, > "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" as well as due to the reference to RFC 1930 in ripe-679. > > >> If your ASN does not show up in the global routing anymore, you > obviously lost the need for that '"new" *external* routing policy', no? > > No. Best regards, Daniel > > So, if a connection between "ASN received" and "ASN visible" does not > exist, where's the case for this wg? RIPE NCC can carry out a db-based > clean up on their own: keeping registration data up-to-date is already a > requirement for resource holders (ripe-637). > > To be more elaborate (quoting the initial mail): > > 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 ask if the ASN is currently being used or if there are plans to > start using the ASN in the coming three months. [?] > > Answer a: "um, yes?". Answer b: "definitely no". As investigating to > answer b in good faith is always more expensive than to just state a, and > since without the need for public visibility there's no means to control > the usage: what's the point? > > > 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. > > What's the calculated gain, what's the overall benefit, given the limited > control (see above)? It's fine that the process is automated on RIPE NCC's > end, but LIRs will face additional work. With now 32 bits at hand for AS > numbers, what's the operational benefit for the RIPE community as a whole > if all "invisible" 6,6k ASNs would be returned after this effort? > Especially as RFC 4893 is celebrating it's 10th birthday in a few weeks? > > Regards, > -kai > > > > -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: From farmer at umn.edu Mon Mar 27 04:48:08 2017 From: farmer at umn.edu (David Farmer) Date: Sun, 26 Mar 2017 21:48:08 -0500 Subject: [address-policy-wg] Cleaning up Unused AS Numbers In-Reply-To: <89e8a45e-6a45-c195-026d-7923eb63a3f8@uu.org> References: <1714652745.1189063.1490280807590.ref@mail.yahoo.com> <1714652745.1189063.1490280807590@mail.yahoo.com> <20170323163519.GH2367@Space.Net> <4386755.pjWc2apoCa@hunator-ntb.site> <61c5af5d-b406-265a-4d29-e52fca4a954f@uu.org> <20170326202059.GA8602@srv03.cluenet.de> <89e8a45e-6a45-c195-026d-7923eb63a3f8@uu.org> Message-ID: On Sun, Mar 26, 2017 at 6:46 PM, Kai 'wusel' Siering wrote: > Am 26.03.2017 um 22:20 schrieb Daniel Roesen: > > On Fri, Mar 24, 2017 at 02:32:35AM +0100, Kai 'wusel' Siering wrote: > > > >> Sorry, but as a public ASN is to serve public inter-AS-uses, > > Can you cite the policy requiring that? > > RFC 1930, referenced by ripe-679, states: "10. The Internet Assigned > Numbers Authority (IANA) has reserved the following block of AS numbers for > private use (not to be advertised on the global Internet): 64512 through > 65535". Together with "9. AS Space exhaustion" it disencourages the use of > public AS numbers for non-public use. And there is ripe-679' requirement of > multihoming. > First, RFC 1930 has been updated by RFC 6996 and RFC 7300, ASNs 64512 - 65534 and 4200000000 - 4294967294 are now available for private use, and AS 65535 is not intended for private use. Furthermore, the guidance in RFC 1930 is over twenty years old and does not account for 4-Byte (32 bit) ASNs and the fact that there are now 4 Billion ASNs means that "AS Space exhaustion" is no longer a realistic issue probably even in the long-run. > >> So, you need a "new" *external* routing policy to receive a (public) > ASN. > > Yes. You seem to mistake "external" with "on the public Internet". > "External" in BGP context is "with other ASN", that's it - not more, not > less. > > Maybe I do, if so, most likely because of the connection initially drawn, > "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" as well as due to the reference to RFC 1930 in ripe-679. > Given the availability of ASN now days an overly strict interpretation of an "external" routing policy to mean "on the public Internet" is not necessary. Has been or might need to be visible "on the public Internet" or is visible to any other administrative domain is a more than sufficiently strict definition of "external" routing policy, at least now with 4 Billion ASNs. > >> If your ASN does not show up in the global routing anymore, you > obviously lost the need for that '"new" *external* routing policy', no? > > No. Best regards, Daniel > > So, if a connection between "ASN received" and "ASN visible" does not > exist, where's the case for this wg? RIPE NCC can carry out a db-based > clean up on their own: keeping registration data up-to-date is already a > requirement for resource holders (ripe-637). > ... > Regards, > -kai > -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: From ripe-wgs at radu-adrian.feurdean.net Mon Mar 27 10:44:00 2017 From: ripe-wgs at radu-adrian.feurdean.net (Radu-Adrian FEURDEAN) Date: Mon, 27 Mar 2017 10:44:00 +0200 Subject: [address-policy-wg] Cleaning up Unused AS Numbers In-Reply-To: <61c5af5d-b406-265a-4d29-e52fca4a954f@uu.org> References: <1714652745.1189063.1490280807590.ref@mail.yahoo.com> <1714652745.1189063.1490280807590@mail.yahoo.com> <20170323163519.GH2367@Space.Net> <4386755.pjWc2apoCa@hunator-ntb.site> <61c5af5d-b406-265a-4d29-e52fca4a954f@uu.org> Message-ID: <1490604240.2036165.924443368.653CC77C@webmail.messagingengine.com> On Fri, Mar 24, 2017, at 03:32, Kai 'wusel' Siering wrote: > Sorry, but as a public ASN is to serve public inter-AS-uses, why even > think about private usage of a public resource? If you use a public AS > internally only, you should switch to a private AS. What do you call "public". There are a number of cases where inter- AS interconnection is required and still it's not visible to the outside world: - Virtual mobile operators (Full-MVNO) : you usually have to interconnect (IP-wise) with one or several "home radio networks", one or more "roaming brokers" and eventually with some other entities of the eco-system - "PPP Collect" : for operators that do not have an full national deployment, it is possible to purchase wholesale DSL links delivered "over L2TP over IP". In this case you have an e-BGP connection with the local-loop operator : you announce your LNS(-es) and RADIUS server(s) and tey announce thei LAC(s) and RADIUS proxy(es). Who we even have the same story for plain IPoE. - Some private cloud interconnections are not publically visible and do not follow the rules for "regular interconnections" (may accept private IP space and max prefix length may go up to /32 in v4) Some other cases exist as well. In all the above cases you have eBGP sessions that exchange prefixes that in IPv4 may go up to /32 ("PPP Collect" and "IPoE Collect" we receive and have to announce almost exclusively /32 - yes that's each v4 address individually announced). Useless to say that when you have several such interconnections using private ASNs things become a mess quite quickly. > > So, you need a "new" *external* routing policy to receive a > (public) ASN. If your ASN does not show up in the global routing > anymore, you obviously lost the need for that '"new" *external* > routing policy', no? > As explained above, all thoses cases involves routing policy "external" to the organisation using the AS using the "hidden" ASn. -- Radu-Adrian FEURDEAN -------------- next part -------------- An HTML attachment was scrubbed... URL: From apwg at c4inet.net Mon Mar 27 13:02:27 2017 From: apwg at c4inet.net (Sascha Luck [ml]) Date: Mon, 27 Mar 2017 12:02:27 +0100 Subject: [address-policy-wg] Cleaning up Unused AS Numbers In-Reply-To: <89e8a45e-6a45-c195-026d-7923eb63a3f8@uu.org> References: <1714652745.1189063.1490280807590.ref@mail.yahoo.com> <1714652745.1189063.1490280807590@mail.yahoo.com> <20170323163519.GH2367@Space.Net> <4386755.pjWc2apoCa@hunator-ntb.site> <61c5af5d-b406-265a-4d29-e52fca4a954f@uu.org> <20170326202059.GA8602@srv03.cluenet.de> <89e8a45e-6a45-c195-026d-7923eb63a3f8@uu.org> Message-ID: <20170327110227.GY93886@cilantro.c4inet.net> On Mon, Mar 27, 2017 at 01:46:32AM +0200, Kai 'wusel' Siering wrote: >What's the calculated gain, what's the overall benefit, given >the limited control (see above)? It's fine that the process is >automated on RIPE NCC's end, but LIRs will face additional work. >With now 32 bits at hand for AS numbers, what's the operational >benefit for the RIPE community as a whole if all "invisible" >6,6k ASNs would be returned after this effort? Especially as RFC >4893 is celebrating it's 10th birthday in a few weeks? I think this is a misunderstanding. The goal is not to reclaim "unused" ASNs, AIUI it is to re-establish contact with ASNs lost in the "swamp" over time. Any reclamations would presumably be incidental. It's just the NCC doing its job as a registry. rgds, Sascha Luck From gert at space.net Tue Mar 28 21:07:21 2017 From: gert at space.net (Gert Doering) Date: Tue, 28 Mar 2017 21:07:21 +0200 Subject: [address-policy-wg] 2016-05 Last Call for Comments (Synchronising the Initial and Subsequent IPv6 Allocation Policies) In-Reply-To: References: Message-ID: <20170328190721.GA57729@Space.Net> Dear AP WG, On Mon, Feb 27, 2017 at 10:58:00AM +0100, Marco Schmidt wrote: > Proposal 2016-05, "Synchronising the Initial and Subsequent IPv6 Allocation Policies", is now in Concluding Phase. [..] > 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. No comments have been voiced in the Last Call phase, which according to PDP is interpreted as "consent". Thus, the APWG chairs declare consensus on this proposal. Marco will send the formal announcement including implementation planning in the next days. thanks :-) Gert Doering -- APWG chair -- 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 mschmidt at ripe.net Thu Mar 30 16:04:06 2017 From: mschmidt at ripe.net (Marco Schmidt) Date: Thu, 30 Mar 2017 16:04:06 +0200 Subject: [address-policy-wg] 2016-05 Proposal Accepted (Synchronising the Initial and Subsequent IPv6 Allocation Policies) Message-ID: Dear colleagues, Consensus has been reached on 2016-05, "Synchronising the Initial and Subsequent IPv6 Allocation Policies". This policy change matches the subsequent IPv6 allocation requirements with the initial allocation requirements. In addition to the existing justification based on past utilisation, it is now also possible to document new needs, including the number of users, the extent of the organisation's infrastructure, the hierarchical and geographical structuring of the organisation, the segmentation of infrastructure for security and the planned longevity of the allocation. You can find the full proposal at: https://www.ripe.net/participate/policies/proposals/2016-05 The new RIPE Document is ripe-684 and is available at: https://www.ripe.net/publications/docs/ripe-684 We estimate that this proposal will take around two weeks to fully implement. We will send another announcement once the implementation is complete and the new procedures are in place. Thank you to everyone who provided input. Kind regards, Marco Schmidt Policy Development Officer RIPE NCC Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum