Re: [address-policy-wg] Cleaning up Unused AS Numbers
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 <Laurens.Hoogendoorn@ripe.net> wrote: Subject: [address-policy-wg] Cleaning up Unused AS Numbers To: "address-policy-wg@ripe.net" <address-policy-wg@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 <address-policy-wg@ripe.net>. Regards, Laurens Hoogendoorn Registration Services RIPE NCC
Hi, On Thu, Mar 23, 2017 at 02:53:27PM +0000, fransossen@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
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
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@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
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
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
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 <ftp://ftp.ripe.net/rfc/rfc1930.txt>.
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
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@ripe.net] On Behalf Of Kai 'wusel' Siering Sent: 24 March 2017 01:33 To: address-policy-wg@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.
On 24 Mar 2017, at 10:29, Dickinson, Ian <Ian.Dickinson@sky.uk> 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?
On 24 March 2017 at 10:43, Jim Reid <jim@rfc1035.com> wrote:
On 24 Mar 2017, at 10:29, Dickinson, Ian <Ian.Dickinson@sky.uk> 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
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@polsl.pl
On Fri, Mar 24, 2017 at 11:43 AM, Jim Reid <jim@rfc1035.com> 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
On Fri, Mar 24, 2017 at 11:29 AM, Dickinson, Ian <Ian.Dickinson@sky.uk> 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
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@gmail.com] Sent: 24 March 2017 12:50 To: Dickinson, Ian <Ian.Dickinson@sky.uk> Cc: address-policy-wg@ripe.net Subject: Re: [address-policy-wg] Cleaning up Unused AS Numbers On Fri, Mar 24, 2017 at 11:29 AM, Dickinson, Ian <Ian.Dickinson@sky.uk> 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.
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@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0
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
On Sun, Mar 26, 2017 at 6:46 PM, Kai 'wusel' Siering <wusel+ml@uu.org> 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@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 ===============================================
On Sun, Mar 26, 2017 at 6:46 PM, Kai 'wusel' Siering <wusel+ml@uu.org> 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@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 ===============================================
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
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
participants (13)
-
Aled Morris -
Daniel Roesen -
David Farmer -
Dickinson, Ian -
fransossen＠yahoo.com -
Gert Doering -
Jim Reid -
Kai 'wusel' Siering -
Martin Huněk -
Piotr Strzyzewski -
Radu-Adrian FEURDEAN -
Richard Hartmann -
Sascha Luck [ml]