From mschmidt at ripe.net Mon May 6 13:10:32 2019 From: mschmidt at ripe.net (Marco Schmidt) Date: Mon, 06 May 2019 13:10:32 +0200 Subject: [address-policy-wg] 2019-02 Review Phase (IPv4 Waiting List Implementation) Message-ID: Dear colleagues, Policy proposal 2019-02, "IPv4 Waiting List Implementation" is now in the Review Phase. This proposal aims at creating a waiting list based on an allocation size of /24 once the RIPE NCC?s free IPv4 pool is exhausted. The proposal has been updated following the last round of discussion and is now at version v2.0. Some of the differences from version v1.0 include: - New proposal title - Focus on waiting list requirements - Adjusting the moment of policy activation The RIPE NCC has prepared an impact analysis on this latest proposal version to support the community?s discussion. You can find the full proposal and impact analysis at: https://www.ripe.net/participate/policies/proposals/2019-02 And the draft documents at: https://www.ripe.net/participate/policies/proposals/2019-02/draft As per the RIPE Policy Development Process (PDP), the purpose of this four week Review Phase is to continue discussion of the proposal, taking the impact analysis into consideration, and to review the full draft RIPE Policy Document. At the end of the Review Phase, the WG Chairs will determine whether the WG has reached rough consensus. It is therefore important to provide your opinion, even if it is simply a restatement of your input from the previous phase. We encourage you to read the proposal, impact analysis and draft document and send any comments to before 4 June 2019. Kind regards, Marco Schmidt Policy Officer RIPE NCC Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum From randy at psg.com Tue May 7 12:57:16 2019 From: randy at psg.com (Randy Bush) Date: Tue, 07 May 2019 03:57:16 -0700 Subject: [address-policy-wg] 2019-02 Review Phase (IPv4 Waiting List Implementation) In-Reply-To: References: Message-ID: > Policy proposal 2019-02, "IPv4 Waiting List Implementation" is now in > the Review Phase. /me supports we are here to do what we can to make the internet work. this helps by making connectivity as available as possible given the circumstances. randy From aled.w.morris at googlemail.com Tue May 7 14:18:14 2019 From: aled.w.morris at googlemail.com (Aled Morris) Date: Tue, 7 May 2019 13:18:14 +0100 Subject: [address-policy-wg] Application for AS number Message-ID: Hi all I'm in the process of helping a startup ISP get RIPE membership and resources and have hit against a little bit of poor wording in the AS guidelines RIPE-679, specifically: *A network must be multihomed in order to qualify for an AS Number.* The application for an AS number has been delayed because the NCC analyst working on the ticket is claiming the ISP has to be *already multihomed* before an AS can be issued. This interpretation doesn't make any sense to me. Surely the intention *to become multihomed* should be the requirement for obtaining an AS number? I don't even see how you can be properly multihomed if you don't have an AS number. Are we supposed to implement some kind of NAT multihoming first? Can we look to change the wording in RIPE-679 to make this clear? Aled -------------- next part -------------- An HTML attachment was scrubbed... URL: From dominik at clouvider.co.uk Tue May 7 14:24:48 2019 From: dominik at clouvider.co.uk (Dominik Nowacki) Date: Tue, 7 May 2019 12:24:48 +0000 Subject: [address-policy-wg] Application for AS number In-Reply-To: References: Message-ID: <3E1D3CE6-3D53-431A-B2AA-69510E88D31C@clouvider.co.uk> Aled, You could come up with a policy proposal to change the wording. With that?s said I wouldn?t say this is required. This is a common sense issue. Naturally if you can prove you?re multihoming the future network, so you have two ASNa that will peer with $NEWAS and they are happy to confirm it, I wouldn?t see a reason for this to be an issue, you might want to escalate it to within the NCC so the manager of said analyst could look into it. If you currently have only one peer and no solid plans to immediately turn up the other one for the new AS, so it is multihomed, I?d say the analyst is right in causing a fuss about it - ASNs are allocated for multihoming. With Kind Regards, Dominik Nowacki Clouvider Limited is a limited company registered in England and Wales. Registered number: 08750969. Registered office: 88 Wood Street, London, United Kingdom, EC2V 7RS. Please note that Clouvider Limited may monitor email traffic data and also the content of email for the purposes of security and staff training. This message contains confidential information and is intended only for the intended recipient. If you do not believe you are the intended recipient you should not disseminate, distribute or copy this e-mail. Please notify abuse at clouvider.net of this e-mail immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Clouvider Limited nor any of its employees therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. On 7 May 2019, at 13:19, Aled Morris via address-policy-wg > wrote: Hi all I'm in the process of helping a startup ISP get RIPE membership and resources and have hit against a little bit of poor wording in the AS guidelines RIPE-679, specifically: A network must be multihomed in order to qualify for an AS Number. The application for an AS number has been delayed because the NCC analyst working on the ticket is claiming the ISP has to be already multihomed before an AS can be issued. This interpretation doesn't make any sense to me. Surely the intention to become multihomed should be the requirement for obtaining an AS number? I don't even see how you can be properly multihomed if you don't have an AS number. Are we supposed to implement some kind of NAT multihoming first? Can we look to change the wording in RIPE-679 to make this clear? Aled -------------- next part -------------- An HTML attachment was scrubbed... URL: From gert at space.net Tue May 7 14:30:42 2019 From: gert at space.net (Gert Doering) Date: Tue, 7 May 2019 14:30:42 +0200 Subject: [address-policy-wg] Application for AS number In-Reply-To: References: Message-ID: <20190507123042.GZ25123@Space.Net> Hi, On Tue, May 07, 2019 at 01:18:14PM +0100, Aled Morris via address-policy-wg wrote: > I'm in the process of helping a startup ISP get RIPE membership and > resources and have hit against a little bit of poor wording in the AS > guidelines RIPE-679, specifically: > > *A network must be multihomed in order to qualify for an AS Number.* > > The application for an AS number has been delayed because the NCC analyst > working on the ticket is claiming the ISP has to be *already multihomed* > before an AS can be issued. > > This interpretation doesn't make any sense to me. Surely the intention *to > become multihomed* should be the requirement for obtaining an AS number? Speaking as WG participant and long time LIR contact, this sounds funny indeed. And none of my AS requests so far have been for networks that were *already* multihomed (because, well, how can you be without an AS number...). > I don't even see how you can be properly multihomed if you don't have an AS > number. Are we supposed to implement some kind of NAT multihoming first? > > Can we look to change the wording in RIPE-679 to make this clear? Now, speaking as WG chair, we can just toss the ball at Marco/Andrea from the NCC RS department and ask them to comment on this, and whether this is an issue of policy wording, misunderstanding, or possibly miscommunication (language barriers...). We can also spend some time at the next meeting to discuss this in the WG meeting - that's what our time is for, have face to face chats to clarify intentions, interpretations, and possibly ways forward... Gert Doering -- multi-hatted individual -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From ffamax at gmail.com Tue May 7 15:25:01 2019 From: ffamax at gmail.com (Maxim A Piskunov) Date: Tue, 7 May 2019 16:25:01 +0300 Subject: [address-policy-wg] Application for AS number In-Reply-To: <20190507123042.GZ25123@Space.Net> References: <20190507123042.GZ25123@Space.Net> Message-ID: Hi, all! Since time when AS was obtained to time when network will become multihomed may passed some time, up to several years. It's mean several kilometers of cables should be buried in the ground before it happens. In some cases. Or the same onether kinds of tasks should be done. It's not mean that some guys, who put on their eyes pink glasses, should decide for all other that network should already multihomed from scratch. No! Network should be multihomed by design - it's enough. On Tue, 7 May 2019 at 15:30, Gert Doering wrote: > Hi, > > On Tue, May 07, 2019 at 01:18:14PM +0100, Aled Morris via > address-policy-wg wrote: > > I'm in the process of helping a startup ISP get RIPE membership and > > resources and have hit against a little bit of poor wording in the AS > > guidelines RIPE-679, specifically: > > > > *A network must be multihomed in order to qualify for an AS Number.* > > > > The application for an AS number has been delayed because the NCC analyst > > working on the ticket is claiming the ISP has to be *already multihomed* > > before an AS can be issued. > > > > This interpretation doesn't make any sense to me. Surely the intention > *to > > become multihomed* should be the requirement for obtaining an AS number? > > Speaking as WG participant and long time LIR contact, this sounds funny > indeed. And none of my AS requests so far have been for networks that > were *already* multihomed (because, well, how can you be without an > AS number...). > > > > I don't even see how you can be properly multihomed if you don't have an > AS > > number. Are we supposed to implement some kind of NAT multihoming first? > > > > Can we look to change the wording in RIPE-679 to make this clear? > > Now, speaking as WG chair, we can just toss the ball at Marco/Andrea > from the NCC RS department and ask them to comment on this, and whether > this is an issue of policy wording, misunderstanding, or possibly > miscommunication (language barriers...). > > We can also spend some time at the next meeting to discuss this in > the WG meeting - that's what our time is for, have face to face chats > to clarify intentions, interpretations, and possibly ways forward... > > Gert Doering > -- multi-hatted individual > -- > have you enabled IPv6 on something today...? > > SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael > Emmer > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dominik at clouvider.co.uk Tue May 7 15:34:36 2019 From: dominik at clouvider.co.uk (Dominik Nowacki) Date: Tue, 7 May 2019 13:34:36 +0000 Subject: [address-policy-wg] Application for AS number In-Reply-To: References: <20190507123042.GZ25123@Space.Net>, Message-ID: <6675F3AC-00BC-484D-814F-0B7D86016E06@clouvider.co.uk> Hi Maxim, What stops you from applying for the ASN once the cables are buried several years down the road, and while the build process is ongoing from using a default route instead ? With Kind Regards, Dominik Nowacki Clouvider Limited is a limited company registered in England and Wales. Registered number: 08750969. Registered office: 88 Wood Street, London, United Kingdom, EC2V 7RS. Please note that Clouvider Limited may monitor email traffic data and also the content of email for the purposes of security and staff training. This message contains confidential information and is intended only for the intended recipient. If you do not believe you are the intended recipient you should not disseminate, distribute or copy this e-mail. Please notify abuse at clouvider.net of this e-mail immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Clouvider Limited nor any of its employees therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. On 7 May 2019, at 14:24, Maxim A Piskunov > wrote: Hi, all! Since time when AS was obtained to time when network will become multihomed may passed some time, up to several years. It's mean several kilometers of cables should be buried in the ground before it happens. In some cases. Or the same onether kinds of tasks should be done. It's not mean that some guys, who put on their eyes pink glasses, should decide for all other that network should already multihomed from scratch. No! Network should be multihomed by design - it's enough. On Tue, 7 May 2019 at 15:30, Gert Doering > wrote: Hi, On Tue, May 07, 2019 at 01:18:14PM +0100, Aled Morris via address-policy-wg wrote: > I'm in the process of helping a startup ISP get RIPE membership and > resources and have hit against a little bit of poor wording in the AS > guidelines RIPE-679, specifically: > > *A network must be multihomed in order to qualify for an AS Number.* > > The application for an AS number has been delayed because the NCC analyst > working on the ticket is claiming the ISP has to be *already multihomed* > before an AS can be issued. > > This interpretation doesn't make any sense to me. Surely the intention *to > become multihomed* should be the requirement for obtaining an AS number? Speaking as WG participant and long time LIR contact, this sounds funny indeed. And none of my AS requests so far have been for networks that were *already* multihomed (because, well, how can you be without an AS number...). > I don't even see how you can be properly multihomed if you don't have an AS > number. Are we supposed to implement some kind of NAT multihoming first? > > Can we look to change the wording in RIPE-679 to make this clear? Now, speaking as WG chair, we can just toss the ball at Marco/Andrea from the NCC RS department and ask them to comment on this, and whether this is an issue of policy wording, misunderstanding, or possibly miscommunication (language barriers...). We can also spend some time at the next meeting to discuss this in the WG meeting - that's what our time is for, have face to face chats to clarify intentions, interpretations, and possibly ways forward... Gert Doering -- multi-hatted individual -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- An HTML attachment was scrubbed... URL: From ffamax at gmail.com Tue May 7 15:51:13 2019 From: ffamax at gmail.com (Maxim A Piskunov) Date: Tue, 7 May 2019 16:51:13 +0300 Subject: [address-policy-wg] Application for AS number In-Reply-To: <6675F3AC-00BC-484D-814F-0B7D86016E06@clouvider.co.uk> References: <20190507123042.GZ25123@Space.Net> <6675F3AC-00BC-484D-814F-0B7D86016E06@clouvider.co.uk> Message-ID: >What stops you from applying for the ASN once the cables are buried several years down the road, and while the build process is ongoing from using a default route instead ? When build process is done, it should start work. It is very strange situation, when network component is ready and we should wait some time while obtaining AS. It's bullshit of office clerk. AS maybe and should be obtained in advance and to be ready for use. Try to understand from operators needs, not declare to operator how operator should do his business, okey? On Tue, 7 May 2019 at 16:34, Dominik Nowacki wrote: > Hi Maxim, > What stops you from applying for the ASN once the cables are buried > several years down the road, and while the build process is ongoing from > using a default route instead ? > > With Kind Regards, > Dominik Nowacki > > Clouvider Limited is a limited company registered in England and Wales. > Registered number: *08750969* <08750969>. Registered office: *88 Wood > Street, London, United Kingdom, EC2V 7RS*. Please note that Clouvider > Limited may monitor email traffic data and also the content of email for > the purposes of security and staff training. This message contains > confidential information and is intended only for the intended recipient. > If you do not believe you are the intended recipient you should not > disseminate, distribute or copy this e-mail. Please notify > *abuse at clouvider.net* of this e-mail immediately by > e-mail if you have received this e-mail by mistake and delete this e-mail > from your system. E-mail transmission cannot be guaranteed to be secure or > error-free as information could be intercepted, corrupted, lost, destroyed, > arrive late or incomplete, or contain viruses. Clouvider Limited nor any of > its employees therefore does not accept liability for any errors or > omissions in the contents of this message, which arise as a result of > e-mail transmission. If verification is required please request a hard-copy > version. > > On 7 May 2019, at 14:24, Maxim A Piskunov wrote: > > Hi, all! > > Since time when AS was obtained to time when network will become > multihomed may passed some time, up to several years. > It's mean several kilometers of cables should be buried in the ground > before it happens. In some cases. Or the same onether kinds of tasks should > be done. > It's not mean that some guys, who put on their eyes pink glasses, should > decide for all other that network should already multihomed from scratch. > No! > Network should be multihomed by design - it's enough. > > > On Tue, 7 May 2019 at 15:30, Gert Doering wrote: > >> Hi, >> >> On Tue, May 07, 2019 at 01:18:14PM +0100, Aled Morris via >> address-policy-wg wrote: >> > I'm in the process of helping a startup ISP get RIPE membership and >> > resources and have hit against a little bit of poor wording in the AS >> > guidelines RIPE-679, specifically: >> > >> > *A network must be multihomed in order to qualify for an AS Number.* >> > >> > The application for an AS number has been delayed because the NCC >> analyst >> > working on the ticket is claiming the ISP has to be *already multihomed* >> > before an AS can be issued. >> > >> > This interpretation doesn't make any sense to me. Surely the intention >> *to >> > become multihomed* should be the requirement for obtaining an AS number? >> >> Speaking as WG participant and long time LIR contact, this sounds funny >> indeed. And none of my AS requests so far have been for networks that >> were *already* multihomed (because, well, how can you be without an >> AS number...). >> >> >> > I don't even see how you can be properly multihomed if you don't have >> an AS >> > number. Are we supposed to implement some kind of NAT multihoming >> first? >> > >> > Can we look to change the wording in RIPE-679 to make this clear? >> >> Now, speaking as WG chair, we can just toss the ball at Marco/Andrea >> from the NCC RS department and ask them to comment on this, and whether >> this is an issue of policy wording, misunderstanding, or possibly >> miscommunication (language barriers...). >> >> We can also spend some time at the next meeting to discuss this in >> the WG meeting - that's what our time is for, have face to face chats >> to clarify intentions, interpretations, and possibly ways forward... >> >> Gert Doering >> -- multi-hatted individual >> -- >> have you enabled IPv6 on something today...? >> >> SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael >> Emmer >> Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann >> D-80807 Muenchen HRB: 136055 (AG Muenchen) >> Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul at prtsystems.ltd.uk Tue May 7 15:53:13 2019 From: paul at prtsystems.ltd.uk (Paul Thornton) Date: Tue, 7 May 2019 14:53:13 +0100 Subject: [address-policy-wg] Application for AS number In-Reply-To: <6675F3AC-00BC-484D-814F-0B7D86016E06@clouvider.co.uk> References: <20190507123042.GZ25123@Space.Net> <6675F3AC-00BC-484D-814F-0B7D86016E06@clouvider.co.uk> Message-ID: <5CD18DC9.4040406@prtsystems.ltd.uk> Hi, On 07/05/2019 14:34, Dominik Nowacki wrote: > Hi Maxim, > What stops you from applying for the ASN once the cables are buried > several years down the road, and while the build process is ongoing from > using a default route instead ? Nothing, of course. But it is a little hard to announce your own address space behind a provider if you don't have an AS. And having your upstream originate it just means pain (and usually downtime) whilst they convert you from a non-BGP service to a BGP-enabled one. I personally have no problem with making it easier to obtain an AS if you intend to multihome at some point in the future (measured in years if necessary - let people who want to do the Right Thing from day one do that). There are plenty of 32 bit AS numbers available, they are not a scarce resource and we as a community should probably not treat them as such. Paul. From christoffer at netravnen.de Tue May 7 15:55:37 2019 From: christoffer at netravnen.de (Hansen, Christoffer) Date: Tue, 7 May 2019 15:55:37 +0200 Subject: [address-policy-wg] Application for AS number In-Reply-To: References: Message-ID: <89184666-b5fa-a681-0a35-ddb7b23b4e19@netravnen.de> On 07/05/2019 14:18, Aled Morris via address-policy-wg wrote: > I'm in the process of helping a startup ISP get RIPE membership and > resources and have hit against a little bit of poor wording in the AS > guidelines RIPE-679, specifically: > > *A network must be multihomed in order to qualify for an AS Number.* > > The application for an AS number has been delayed because the NCC analyst > working on the ticket is claiming the ISP has to be *already multihomed* > before an AS can be issued. > > This interpretation doesn't make any sense to me. Surely the intention *to > become multihomed* should be the requirement for obtaining an AS number? > > I don't even see how you can be properly multihomed if you don't have an AS > number. Are we supposed to implement some kind of NAT multihoming first? > > Can we look to change the wording in RIPE-679 to make this clear? Pointing to RFC 1930 and pointing out you will want to move - from "Single-homed site, multiple prefixes" - to "Multi-homed site, multiple prefixes" requires you be assigned an ASN. You can ask the the NCC analyst, if it is alright to provide them with agreements with existing upstream provider A and future upstream provider B is sufficient to be assigned the ASN(?) -Christoffer ---- https://tools.ietf.org/html/rfc1930#section-5.1 * Single-homed site, multiple prefixes Again, a separate AS is not needed; the prefixes should be placed in an AS of the site's provider. * Multi-homed site Here multi-homed is taken to mean a prefix or group of prefixes which connects to more than one service provider (i.e. more than one AS with its own routing policy). It does not mean a network multi-homed running an IGP for the purposes of resilience. An AS is required; the site's prefixes should be part of a single AS, distinct from the ASes of its service providers. This allows the customer the ability to have a different repre- sentation of policy and preference among the different service providers. This is ALMOST THE ONLY case where a network operator should create its own AS number. In this case, the site should ensure that it has the necessary facilities to run appropriate routing protocols, such as BGP4. From ffamax at gmail.com Tue May 7 15:59:09 2019 From: ffamax at gmail.com (Maxim A Piskunov) Date: Tue, 7 May 2019 16:59:09 +0300 Subject: [address-policy-wg] Application for AS number In-Reply-To: <5CD18DC9.4040406@prtsystems.ltd.uk> References: <20190507123042.GZ25123@Space.Net> <6675F3AC-00BC-484D-814F-0B7D86016E06@clouvider.co.uk> <5CD18DC9.4040406@prtsystems.ltd.uk> Message-ID: I explain a little more detailed. Obtained in advance AS has about zero cost. Real network resources has a solid costs. Resources should be registered at first, like we register a firm before start to do something. We need some lawful resource ability confirmation at first. On Tue, 7 May 2019 at 16:53, Paul Thornton wrote: > Hi, > > On 07/05/2019 14:34, Dominik Nowacki wrote: > > Hi Maxim, > > What stops you from applying for the ASN once the cables are buried > > several years down the road, and while the build process is ongoing from > > using a default route instead ? > > Nothing, of course. > > But it is a little hard to announce your own address space behind a > provider if you don't have an AS. And having your upstream originate it > just means pain (and usually downtime) whilst they convert you from a > non-BGP service to a BGP-enabled one. > > I personally have no problem with making it easier to obtain an AS if > you intend to multihome at some point in the future (measured in years > if necessary - let people who want to do the Right Thing from day one do > that). There are plenty of 32 bit AS numbers available, they are not a > scarce resource and we as a community should probably not treat them as > such. > > Paul. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ffamax at gmail.com Tue May 7 16:02:28 2019 From: ffamax at gmail.com (Maxim A Piskunov) Date: Tue, 7 May 2019 17:02:28 +0300 Subject: [address-policy-wg] Application for AS number In-Reply-To: <89184666-b5fa-a681-0a35-ddb7b23b4e19@netravnen.de> References: <89184666-b5fa-a681-0a35-ddb7b23b4e19@netravnen.de> Message-ID: I strongly take position that at least one AS any company may have in advance. It's nothing, but it's make further pain is void. On Tue, 7 May 2019 at 16:55, Hansen, Christoffer wrote: > > On 07/05/2019 14:18, Aled Morris via address-policy-wg wrote: > > I'm in the process of helping a startup ISP get RIPE membership and > > resources and have hit against a little bit of poor wording in the AS > > guidelines RIPE-679, specifically: > > > > *A network must be multihomed in order to qualify for an AS Number.* > > > > The application for an AS number has been delayed because the NCC analyst > > working on the ticket is claiming the ISP has to be *already multihomed* > > before an AS can be issued. > > > > This interpretation doesn't make any sense to me. Surely the intention > *to > > become multihomed* should be the requirement for obtaining an AS number? > > > > I don't even see how you can be properly multihomed if you don't have an > AS > > number. Are we supposed to implement some kind of NAT multihoming first? > > > > Can we look to change the wording in RIPE-679 to make this clear? > > Pointing to RFC 1930 and pointing out you will want to move > - from "Single-homed site, multiple prefixes" > - to "Multi-homed site, multiple prefixes" > requires you be assigned an ASN. > > You can ask the the NCC analyst, if it is alright to provide them with > agreements with existing upstream provider A and future upstream > provider B is sufficient to be assigned the ASN(?) > > -Christoffer > > ---- > > https://tools.ietf.org/html/rfc1930#section-5.1 > > * Single-homed site, multiple prefixes > > Again, a separate AS is not needed; the prefixes should be > placed in an AS of the site's provider. > > * Multi-homed site > > Here multi-homed is taken to mean a prefix or group of prefixes > which connects to more than one service provider (i.e. more than > one AS with its own routing policy). It does not mean a network > multi-homed running an IGP for the purposes of resilience. > > An AS is required; the site's prefixes should be part of a > single AS, distinct from the ASes of its service providers. > This allows the customer the ability to have a different repre- > sentation of policy and preference among the different service > providers. > This is ALMOST THE ONLY case where a network operator should > create its own AS number. In this case, the site should ensure > that it has the necessary facilities to run appropriate routing > protocols, such as BGP4. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gert at space.net Tue May 7 16:03:11 2019 From: gert at space.net (Gert Doering) Date: Tue, 7 May 2019 16:03:11 +0200 Subject: [address-policy-wg] Application for AS number In-Reply-To: References: <20190507123042.GZ25123@Space.Net> <6675F3AC-00BC-484D-814F-0B7D86016E06@clouvider.co.uk> Message-ID: <20190507140311.GA25123@Space.Net> Hi, On Tue, May 07, 2019 at 04:51:13PM +0300, Maxim A Piskunov wrote: > It is very strange situation, when network component is ready and we should > wait some time while obtaining AS. It's bullshit of office clerk. Please keep your language polite. As I already said - let's ask Marco and Andrea for feedback what happened, and whether they need some sort of guidance statement and/or wording change for us. And, please, do proper quoting. "fullquote-style" is frowned upon here. Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From ffamax at gmail.com Tue May 7 16:16:11 2019 From: ffamax at gmail.com (Maxim A Piskunov) Date: Tue, 7 May 2019 17:16:11 +0300 Subject: [address-policy-wg] Application for AS number In-Reply-To: <20190507140311.GA25123@Space.Net> References: <20190507123042.GZ25123@Space.Net> <6675F3AC-00BC-484D-814F-0B7D86016E06@clouvider.co.uk> <20190507140311.GA25123@Space.Net> Message-ID: > > Please keep your language polite. As I already said - let's ask Marco > and Andrea for feedback what happened, and whether they need some sort > of guidance statement and/or wording change for us. > And, please, do proper quoting. "fullquote-style" is frowned upon here. > Attachments area Thanks. Please ask other people the same - to keep their thoughts about how other people should to do their works. When people trying to change some fundamental principles of freedom of choice, it's very painy. Possibility to have AS in advance - it's operator freedom in actions. Anybody can't try to disable this possibility. I am shame people who trying to take it from us. Anybody can be applicant for AS. Even if currently network not multihomed. On Tue, 7 May 2019 at 17:03, Gert Doering wrote: > Hi, > > On Tue, May 07, 2019 at 04:51:13PM +0300, Maxim A Piskunov wrote: > > It is very strange situation, when network component is ready and we > should > > wait some time while obtaining AS. It's bullshit of office clerk. > > Please keep your language polite. As I already said - let's ask Marco > and Andrea for feedback what happened, and whether they need some sort > of guidance statement and/or wording change for us. > > And, please, do proper quoting. "fullquote-style" is frowned upon here. > > Gert Doering > -- APWG chair > -- > have you enabled IPv6 on something today...? > > SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael > Emmer > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gert at space.net Tue May 7 16:19:05 2019 From: gert at space.net (Gert Doering) Date: Tue, 7 May 2019 16:19:05 +0200 Subject: [address-policy-wg] Application for AS number In-Reply-To: References: <20190507123042.GZ25123@Space.Net> <6675F3AC-00BC-484D-814F-0B7D86016E06@clouvider.co.uk> <20190507140311.GA25123@Space.Net> Message-ID: <20190507141905.GB25123@Space.Net> Hi, On Tue, May 07, 2019 at 05:16:11PM +0300, Maxim A Piskunov wrote: > > Please keep your language polite. As I already said - let's ask Marco > > and Andrea for feedback what happened, and whether they need some sort > > of guidance statement and/or wording change for us. > > And, please, do proper quoting. "fullquote-style" is frowned upon here. > > Attachments area > > Thanks. > Please ask other people the same - to keep their thoughts about how other > people should to do their works. I do. As WG chair it's part of my job to keep the discussion polite, and encourage clarification from the NCC. Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- 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 Tue May 7 16:53:49 2019 From: sander at steffann.nl (Sander Steffann) Date: Tue, 7 May 2019 16:53:49 +0200 Subject: [address-policy-wg] Application for AS number In-Reply-To: <5CD18DC9.4040406@prtsystems.ltd.uk> References: <20190507123042.GZ25123@Space.Net> <6675F3AC-00BC-484D-814F-0B7D86016E06@clouvider.co.uk> <5CD18DC9.4040406@prtsystems.ltd.uk> Message-ID: <0164012C-B612-4A63-AED8-1DC2268C5C9B@steffann.nl> Hi Paul, > I personally have no problem with making it easier to obtain an AS if you intend to multihome at some point in the future (measured in years if necessary - let people who want to do the Right Thing from day one do that). There are plenty of 32 bit AS numbers available, they are not a scarce resource and we as a community should probably not treat them as such. This! Cheers, Sander -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: Message signed with OpenPGP URL: From sandy at tislabs.com Tue May 7 16:55:37 2019 From: sandy at tislabs.com (Sandra Murphy) Date: Tue, 7 May 2019 10:55:37 -0400 Subject: [address-policy-wg] Application for AS number In-Reply-To: References: <20190507123042.GZ25123@Space.Net> <6675F3AC-00BC-484D-814F-0B7D86016E06@clouvider.co.uk> <20190507140311.GA25123@Space.Net> Message-ID: <4A87A64E-69B4-4E83-BF90-4F307CF0521A@tislabs.com> > On May 7, 2019, at 10:16 AM, Maxim A Piskunov wrote: > > Possibility to have AS in advance - it's operator freedom in actions. > Anybody can be applicant for AS. Huh. So I was wondering if you realized that the outcome of your proposal was ?all requests for an AS must be satisfied immediately?. But this sure looks like that is precisely what you meant. If that?s not what you meant, you might want to explain what the approval constraints should be. ?Sandy From jordi.palet at consulintel.es Tue May 7 16:58:21 2019 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Tue, 07 May 2019 10:58:21 -0400 Subject: [address-policy-wg] Application for AS number In-Reply-To: <0164012C-B612-4A63-AED8-1DC2268C5C9B@steffann.nl> References: <20190507123042.GZ25123@Space.Net> <6675F3AC-00BC-484D-814F-0B7D86016E06@clouvider.co.uk> <5CD18DC9.4040406@prtsystems.ltd.uk> <0164012C-B612-4A63-AED8-1DC2268C5C9B@steffann.nl> Message-ID: <3E50FB19-1586-479B-908D-85D88578E7A8@consulintel.es> Hi all, I've already drafted a policy proposal to make a change on this, but if I got it correctly, the chairs were believing that it was not needed, so I never officially submitted it. I'm happy to submit it again. It may be interesting for all the list participants to read my policy proposal about this exact same point in AfriNIC: https://www.afrinic.net/policy/proposals/2019-asn-001-d2#proposal Regards, Jordi ?El 7/5/19 10:54, "address-policy-wg en nombre de Sander Steffann" escribi?: Hi Paul, > I personally have no problem with making it easier to obtain an AS if you intend to multihome at some point in the future (measured in years if necessary - let people who want to do the Right Thing from day one do that). There are plenty of 32 bit AS numbers available, they are not a scarce resource and we as a community should probably not treat them as such. This! Cheers, Sander ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. From ffamax at gmail.com Tue May 7 17:04:02 2019 From: ffamax at gmail.com (Maxim A Piskunov) Date: Tue, 7 May 2019 18:04:02 +0300 Subject: [address-policy-wg] Application for AS number In-Reply-To: <4A87A64E-69B4-4E83-BF90-4F307CF0521A@tislabs.com> References: <20190507123042.GZ25123@Space.Net> <6675F3AC-00BC-484D-814F-0B7D86016E06@clouvider.co.uk> <20190507140311.GA25123@Space.Net> <4A87A64E-69B4-4E83-BF90-4F307CF0521A@tislabs.com> Message-ID: > > Huh. > So I was wondering if you realized that the outcome of your proposal was > ?all requests for an AS must be satisfied immediately?. > But this sure looks like that is precisely what you meant. > If that?s not what you meant, you might want to explain what the approval > constraints should be. The best thing is when any LIR may claim one AS for one customer without any approval. Just if customer asking for AS - just give AS. If customer asking for another and first AS is still spare (not multihomed) then some strategy may be required. Yes, it's good idea to delegate pre approved AS-list to LIR for assigning to their customers. On Tue, 7 May 2019 at 17:55, Sandra Murphy wrote: > > > On May 7, 2019, at 10:16 AM, Maxim A Piskunov wrote: > > > > Possibility to have AS in advance - it's operator freedom in actions. > > > Anybody can be applicant for AS. > > > Huh. > > So I was wondering if you realized that the outcome of your proposal was > ?all requests for an AS must be satisfied immediately?. > > But this sure looks like that is precisely what you meant. > > If that?s not what you meant, you might want to explain what the approval > constraints should be. > > ?Sandy > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From npediaditi at ripe.net Tue May 7 17:08:12 2019 From: npediaditi at ripe.net (Nikolas Pediaditis) Date: Tue, 7 May 2019 17:08:12 +0200 Subject: [address-policy-wg] Application for AS number In-Reply-To: <20190507123042.GZ25123@Space.Net> References: <20190507123042.GZ25123@Space.Net> Message-ID: <1B0A5B8F-52B5-4023-83DA-7134157838E4@ripe.net> Dear Aled, Gert, all, Please allow me to provide some clarification. I can confirm that the RIPE NCC does take future deployments into account and AS Numbers can be assigned in advance. Regarding this specific case, there was a miscommunication that we have now clarified directly in the request (which is still ongoing). Kind regards, Nikolas Pediaditis Assistant Manager Registration Services & Policy Development RIPE NCC > On 7 May 2019, at 14:30, Gert Doering wrote: > > Hi, > > On Tue, May 07, 2019 at 01:18:14PM +0100, Aled Morris via address-policy-wg wrote: >> I'm in the process of helping a startup ISP get RIPE membership and >> resources and have hit against a little bit of poor wording in the AS >> guidelines RIPE-679, specifically: >> >> *A network must be multihomed in order to qualify for an AS Number.* >> >> The application for an AS number has been delayed because the NCC analyst >> working on the ticket is claiming the ISP has to be *already multihomed* >> before an AS can be issued. >> >> This interpretation doesn't make any sense to me. Surely the intention *to >> become multihomed* should be the requirement for obtaining an AS number? > > Speaking as WG participant and long time LIR contact, this sounds funny > indeed. And none of my AS requests so far have been for networks that > were *already* multihomed (because, well, how can you be without an > AS number...). > > >> I don't even see how you can be properly multihomed if you don't have an AS >> number. Are we supposed to implement some kind of NAT multihoming first? >> >> Can we look to change the wording in RIPE-679 to make this clear? > > Now, speaking as WG chair, we can just toss the ball at Marco/Andrea > from the NCC RS department and ask them to comment on this, and whether > this is an issue of policy wording, misunderstanding, or possibly > miscommunication (language barriers...). > > We can also spend some time at the next meeting to discuss this in > the WG meeting - that's what our time is for, have face to face chats > to clarify intentions, interpretations, and possibly ways forward... > > Gert Doering > -- multi-hatted individual > -- > have you enabled IPv6 on something today...? > > SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2640 bytes Desc: not available URL: From gert at space.net Tue May 7 17:30:54 2019 From: gert at space.net (Gert Doering) Date: Tue, 7 May 2019 17:30:54 +0200 Subject: [address-policy-wg] Application for AS number In-Reply-To: <1B0A5B8F-52B5-4023-83DA-7134157838E4@ripe.net> References: <20190507123042.GZ25123@Space.Net> <1B0A5B8F-52B5-4023-83DA-7134157838E4@ripe.net> Message-ID: <20190507153054.GE25123@Space.Net> Hi Nikolas, On Tue, May 07, 2019 at 05:08:12PM +0200, Nikolas Pediaditis wrote: > Please allow me to provide some clarification. > > I can confirm that the RIPE NCC does take future deployments into account and AS Numbers can be assigned in advance. > > Regarding this specific case, there was a miscommunication that we have now clarified directly in the request (which is still ongoing). Thanks a lot. So from a policy point of view, I see no urgent need to "fix" something here (neither "the office clerk" nor "the policy" or "the understanding"). Of course we can always discuss whether to loosen up the policy further, but that would be a formal policy change. Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3603 bytes Desc: not available URL: From aled.w.morris at googlemail.com Wed May 8 10:19:51 2019 From: aled.w.morris at googlemail.com (Aled Morris) Date: Wed, 8 May 2019 09:19:51 +0100 Subject: [address-policy-wg] Application for AS number In-Reply-To: <20190507153054.GE25123@Space.Net> References: <20190507123042.GZ25123@Space.Net> <1B0A5B8F-52B5-4023-83DA-7134157838E4@ripe.net> <20190507153054.GE25123@Space.Net> Message-ID: Thank you Nikolas, Gert and everyone who contributed to this conversation. It's good to check that we do all agree. Aled -------------- next part -------------- An HTML attachment was scrubbed... URL: From gert at space.net Thu May 9 21:05:43 2019 From: gert at space.net (Gert Doering) Date: Thu, 9 May 2019 21:05:43 +0200 Subject: [address-policy-wg] Agenda for APWG meeting in Reykjavik Message-ID: <20190509190543.GA6408@Space.Net> Dear working group, dear RIPE meeting folks, Below you can find a draft for the RIPE address policy WG meeting's agenda, which will take place in Reykjavik in the side-room (!) in the following time slots: Wednesday, May 22, 09:00 - 10:30 Wednesday, May 22, 11:00 - 12:30 We have two time slots, and the agenda is currently very light. So if you have something you want to see discussed (which is *address policy* related, so no member fee discussions or database stuff :-) ), please approach Erik or me to see whether this would be a good opportunity. Regards, Gert D?ring & Erik Bais, APWG chairs ---------------------------------------------------------------------- Wednesday, 09:00-10:30 ---------------------------------------------------------------------- A. Administrative Matters (welcome, thanking the scribe, approving the minutes, etc.) B. WG chair rotation / re-seating - longest-serving chair (Gert D?ring) stepping down - finding a new one or keeping the old one C. Current Policy Topics - Marco Schmidt, NCC PDO - global policy overview "what's going on?" - common policy topics in all regions (end of IPv4, transfers, ...) - overview over concluded proposals in the RIPE region since RIPE 77 - brief overview of new proposals (if any) D. Feedback From NCC Registration Service - Nikolas Pediaditis (+ discussion with the group) ---------------------------------------------------------------------- Wednesday, 11:00-12:30 ---------------------------------------------------------------------- Welcome back F. Discussion of open policy proposals * 2019-02 Waiting List & Reducing IPv4 Allocations to a /24 Y. Open Policy Hour The Open Policy Hour is a showcase for your policy ideas. If you have a policy proposal you'd like to debut, prior to formally submitting it, here is your opportunity. Z. AOB -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From randy at psg.com Fri May 10 00:47:20 2019 From: randy at psg.com (Randy Bush) Date: Thu, 09 May 2019 15:47:20 -0700 Subject: [address-policy-wg] Agenda for APWG meeting in Reykjavik In-Reply-To: <20190509190543.GA6408@Space.Net> References: <20190509190543.GA6408@Space.Net> Message-ID: perhaps, as it is, imiho, more address policy than anti-spam, the anti-abuse wg proposal 2019-03 https://www.ripe.net/participate/policies/proposals/2019-03 would be worth a bit of consideration as address policy? randy From cfriacas at fccn.pt Fri May 10 11:05:27 2019 From: cfriacas at fccn.pt (=?ISO-8859-15?Q?Carlos_Fria=E7as?=) Date: Fri, 10 May 2019 10:05:27 +0100 (WEST) Subject: [address-policy-wg] Agenda for APWG meeting in Reykjavik In-Reply-To: References: <20190509190543.GA6408@Space.Net> Message-ID: Hi, Just a small note: 2019-03 is not about "anti-spam", it's about "hijacks". (if some people are not able to abide by the RIR/registry work, then why they need to be part of it?) As far as we authors have been told, the doubt was really between the anti-abuse WG and the routing WG. In fact, as similar proposals are at the table already at LACNIC (see LAC-2019-05) and ARIN (more or less, see prop-266), this might be touched (i hope) during the PDO's presentation. :-) Best Regards, Carlos On Thu, 9 May 2019, Randy Bush wrote: > perhaps, as it is, imiho, more address policy than anti-spam, the > anti-abuse wg proposal 2019-03 > > https://www.ripe.net/participate/policies/proposals/2019-03 > > would be worth a bit of consideration as address policy? > > randy > From gert at space.net Fri May 10 11:14:44 2019 From: gert at space.net (Gert Doering) Date: Fri, 10 May 2019 11:14:44 +0200 Subject: [address-policy-wg] Agenda for APWG meeting in Reykjavik In-Reply-To: References: <20190509190543.GA6408@Space.Net> Message-ID: <20190510091444.GR25123@Space.Net> Hi Randy, On Thu, May 09, 2019 at 03:47:20PM -0700, Randy Bush wrote: > perhaps, as it is, imiho, more address policy than anti-spam, the > anti-abuse wg proposal 2019-03 > > https://www.ripe.net/participate/policies/proposals/2019-03 > > would be worth a bit of consideration as address policy? We'll certainly give a HEADS UP to the AP WG (Marco does this in his "what is going on in current policy land?" presentation anyway, but we should make it more prominent), but formally, we shouldn't open up a separate discussion forum in AP - it has been formally adopted in the anti-abuse WG and thus their chairs need to see the discussion and determine consensus. Sorry for the formalities here. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From randy at psg.com Fri May 10 11:55:22 2019 From: randy at psg.com (Randy Bush) Date: Fri, 10 May 2019 02:55:22 -0700 Subject: [address-policy-wg] Agenda for APWG meeting in Reykjavik In-Reply-To: <20190510091444.GR25123@Space.Net> References: <20190509190543.GA6408@Space.Net> <20190510091444.GR25123@Space.Net> Message-ID: >> perhaps, as it is, imiho, more address policy than anti-spam, the >> anti-abuse wg proposal 2019-03 >> https://www.ripe.net/participate/policies/proposals/2019-03 >> would be worth a bit of consideration as address policy? > We'll certainly give a HEADS UP to the AP WG that is all i was suggesting. apologies, carlos, if you took it as more. randy From brian.nisbet at heanet.ie Fri May 10 13:04:35 2019 From: brian.nisbet at heanet.ie (Brian Nisbet) Date: Fri, 10 May 2019 11:04:35 +0000 Subject: [address-policy-wg] Agenda for APWG meeting in Reykjavik In-Reply-To: <20190510091444.GR25123@Space.Net> References: <20190509190543.GA6408@Space.Net> <20190510091444.GR25123@Space.Net> Message-ID: > -----Original Message----- > From: address-policy-wg On Behalf > Of Gert Doering > Sent: Friday 10 May 2019 10:15 > To: Randy Bush > Cc: meeting at ripe.net; Gert Doering ; address-policy- > wg at ripe.net > Subject: Re: [address-policy-wg] Agenda for APWG meeting in Reykjavik > > Hi Randy, > > On Thu, May 09, 2019 at 03:47:20PM -0700, Randy Bush wrote: > > perhaps, as it is, imiho, more address policy than anti-spam, the > > anti-abuse wg proposal 2019-03 > > > > https://www.ripe.net/participate/policies/proposals/2019-03 > > > > would be worth a bit of consideration as address policy? > > We'll certainly give a HEADS UP to the AP WG (Marco does this in his "what is > going on in current policy land?" presentation anyway, but we should make it > more prominent), but formally, we shouldn't open up a separate discussion > forum in AP - it has been formally adopted in the anti-abuse WG and thus > their chairs need to see the discussion and determine consensus. Barring accident I'll be in the room for the session and, in the highly unlikely event that Marco doesn't have all the info, I can comment. I would agree that it's important the AP WG are at least aware of the policy. But if anyone would like to discuss it in person, it is, unsurprisingly, on the agenda for AA-WG at 09:00 on Thursday morning, do come along! Brian Co-Chair, RIPE AA-WG Brian Nisbet Service Operations Manager HEAnet CLG, Ireland's National Education and Research Network 1st Floor, 5 George's Dock, IFSC, Dublin D01 X8N7, Ireland +35316609040 brian.nisbet at heanet.ie www.heanet.ie Registered in Ireland, No. 275301. CRA No. 20036270 From christoffer at netravnen.de Sun May 12 11:56:02 2019 From: christoffer at netravnen.de (Hansen, Christoffer) Date: Sun, 12 May 2019 11:56:02 +0200 Subject: [address-policy-wg] 2019-02 Review Phase (IPv4 Waiting List Implementation) In-Reply-To: References: Message-ID: On 07/05/2019 12:57, Randy Bush wrote: > On 06/05/2019 13:10, Marco Schmidt wrote: >> Policy proposal 2019-02, "IPv4 Waiting List Implementation" >> is now in the Review Phase. > > we are here to do what we can to make the internet work. this > helps by making connectivity as available as possible given > the circumstances. Agrees with Randys comment. +1 from here. -Christoffer -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: OpenPGP digital signature URL: From gert at space.net Wed May 15 16:17:20 2019 From: gert at space.net (Gert Doering) Date: Wed, 15 May 2019 16:17:20 +0200 Subject: [address-policy-wg] 2019-01 Last Call for Comments (Clarification of Definition for "ASSIGNED PA") In-Reply-To: References: Message-ID: <20190515141720.GA29355@Space.Net> Dear WG, On Mon, Apr 15, 2019 at 11:14:21AM +0200, Marco Schmidt wrote: > Proposal 2019-01, "Clarification of Definition for "ASSIGNED PA"", 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. [..] > Please e-mail any final comments about this proposal to before 14 May 2019. No comments have been received in "Last Call". According to PDP and established practice, this is considered "agreement". Thus, we declare consensus on this policy change, and ask the NCC to update documentation accordingly. Thanks for your contributions, Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- 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 Mon May 20 11:12:22 2019 From: mschmidt at ripe.net (Marco Schmidt) Date: Mon, 20 May 2019 11:12:22 +0200 Subject: [address-policy-wg] 2019-01 Proposal Accepted and Implemented (Clarification of Definition for "ASSIGNED PA") Message-ID: Dear colleagues, Consensus has been reached on 2019-01, "Clarification of Definition for "ASSIGNED PA"". This proposal made it clear in the IPv4 Policy that the status "ASSIGNED PA" can also be used for assignments to an LIR's infrastructure. You can find the full proposal at: https://www.ripe.net/participate/policies/proposals/2019-01 The new RIPE Document is called ripe-720 and is available at: https://www.ripe.net/publications/docs/ripe-720 This proposal is implemented with immediate effect. Thank you to everyone who provided input. Kind regards, Marco Schmidt Policy Officer RIPE NCC Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum From erik at bais.name Tue May 21 17:10:50 2019 From: erik at bais.name (Erik Bais) Date: Tue, 21 May 2019 15:10:50 +0000 Subject: [address-policy-wg] FW: 2019-02 Review Phase (IPv4 Waiting List Implementation) In-Reply-To: References: Message-ID: <8A5943E7-7234-4E9F-9E6C-2761FBCBF909@a2b-internet.com> Dear WG members, As you might have seen, there is a v2 uploaded on the RIPE website and this will be discussed tomorrow during the AP-WG meeting. Please pre-read the updated version in order to make sure you can participate in the discussion about the latest version of the policy text. Kind regards, Erik Bais Co-Chair AP-WG ?On 06/05/2019, 13:10, "address-policy-wg on behalf of Marco Schmidt" wrote: Dear colleagues, Policy proposal 2019-02, "IPv4 Waiting List Implementation" is now in the Review Phase. This proposal aims at creating a waiting list based on an allocation size of /24 once the RIPE NCC?s free IPv4 pool is exhausted. The proposal has been updated following the last round of discussion and is now at version v2.0. Some of the differences from version v1.0 include: - New proposal title - Focus on waiting list requirements - Adjusting the moment of policy activation The RIPE NCC has prepared an impact analysis on this latest proposal version to support the community?s discussion. You can find the full proposal and impact analysis at: https://www.ripe.net/participate/policies/proposals/2019-02 And the draft documents at: https://www.ripe.net/participate/policies/proposals/2019-02/draft As per the RIPE Policy Development Process (PDP), the purpose of this four week Review Phase is to continue discussion of the proposal, taking the impact analysis into consideration, and to review the full draft RIPE Policy Document. At the end of the Review Phase, the WG Chairs will determine whether the WG has reached rough consensus. It is therefore important to provide your opinion, even if it is simply a restatement of your input from the previous phase. We encourage you to read the proposal, impact analysis and draft document and send any comments to before 4 June 2019. Kind regards, Marco Schmidt Policy Officer RIPE NCC Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum From jordi.palet at consulintel.es Wed May 22 16:25:22 2019 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Wed, 22 May 2019 14:25:22 +0000 Subject: [address-policy-wg] informal discussion about removing 5.4.2. Assignments shorter than a /48 to a single End Site Message-ID: <0C6B1FE5-E655-47F3-815E-F4BD3EBF07C6@consulintel.es> Hi all, As commented this morning at the end of the WG meeting, I've been thinking about this issue many times and in fact, in AFRINIC, APNIC and LACNIC, as part of *other* more complex IPv6 policy proposals, we successfully achieved consensus on removing the equivalent text. ARIN has also changed this. In my opinion, the way they handle it, is too complex and not needed, but if someone want to read: https://www.arin.net/participate/policy/nrpm/#6-5-8-2-2-extra-large-sites I've not (yet) done this in RIPE because I thought it is a so small change that doesn't make sense to tackle alone, but this morning I heard otherwise. So ... here we are. By the way, as I always state, I will love some other folks that are willing to contribute, if so let me know in private so we can even organize an on-site meeting. However, in this case I think this policy proposal is just an "empty" one (only remove text, so nothing to draft ...) ... see below. This is our actual text (https://www.ripe.net/publications/docs/ripe-707#assignments_shorter): *** 5.4.2. Assignments shorter than a /48 to a single End Site When a single End Site requires an assignment shorter than a /48, it must request the assignment with documentation or materials that justify the request. Requests for multiple or additional prefixes exceeding a /48 assignment for a single End Site will be processed and reviewed (i.e., evaluation of justification) at the RIR/NIR level. Note: There is no experience at the present time with the assignment of multiple network prefixes to the same End Site. Having the RIR review all such assignments is intended to be a temporary measure until some experience has been gained and some common policies can be developed. In addition, additional work at defining policies in this space will likely be carried out in the near future. *** In my opinion (as I've done in other RIRs), we should just *remove* the complete section. Extreme example case. If an LIR decides to assign /47 to all their customers, and in the future, they need to come back to the NCC for more space, they will need to justify it according to the existing policy at that time. I may understand (even if I don't agree) that somebody want to have the NCC keep doing some evaluation on this. If we want to go this way, we will need to define with a short text what we want. So, opinions? Regards, Jordi ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. From danny at danysek.cz Wed May 22 16:47:22 2019 From: danny at danysek.cz (Daniel Suchy) Date: Wed, 22 May 2019 16:47:22 +0200 Subject: [address-policy-wg] informal discussion about removing 5.4.2. Assignments shorter than a /48 to a single End Site In-Reply-To: <0C6B1FE5-E655-47F3-815E-F4BD3EBF07C6@consulintel.es> References: <0C6B1FE5-E655-47F3-815E-F4BD3EBF07C6@consulintel.es> Message-ID: <49d9dd83-7af8-0a62-3946-8444214a19d3@danysek.cz> Hello, I support section 5.4.2 removal as proposed. It just adds additional administrative overhead to NCC and validity of such assignments can be eventually reviewed during standard ARC process. - Daniel On 5/22/19 4:25 PM, JORDI PALET MARTINEZ via address-policy-wg wrote: > Hi all, > > As commented this morning at the end of the WG meeting, I've been thinking about this issue many times and in fact, in AFRINIC, APNIC and LACNIC, as part of *other* more complex IPv6 policy proposals, we successfully achieved consensus on removing the equivalent text. > > ARIN has also changed this. In my opinion, the way they handle it, is too complex and not needed, but if someone want to read: https://www.arin.net/participate/policy/nrpm/#6-5-8-2-2-extra-large-sites > > I've not (yet) done this in RIPE because I thought it is a so small change that doesn't make sense to tackle alone, but this morning I heard otherwise. > > So ... here we are. By the way, as I always state, I will love some other folks that are willing to contribute, if so let me know in private so we can even organize an on-site meeting. However, in this case I think this policy proposal is just an "empty" one (only remove text, so nothing to draft ...) ... see below. > > This is our actual text (https://www.ripe.net/publications/docs/ripe-707#assignments_shorter): > *** > 5.4.2. Assignments shorter than a /48 to a single End Site > When a single End Site requires an assignment shorter than a /48, it must request the assignment with documentation or materials that justify the request. Requests for multiple or additional prefixes exceeding a /48 assignment for a single End Site will be processed and reviewed (i.e., evaluation of justification) at the RIR/NIR level. > > Note: There is no experience at the present time with the assignment of multiple network prefixes to the same End Site. Having the RIR review all such assignments is intended to be a temporary measure until some experience has been gained and some common policies can be developed. In addition, additional work at defining policies in this space will likely be carried out in the near future. > *** > > In my opinion (as I've done in other RIRs), we should just *remove* the complete section. > > Extreme example case. If an LIR decides to assign /47 to all their customers, and in the future, they need to come back to the NCC for more space, they will need to justify it according to the existing policy at that time. > > I may understand (even if I don't agree) that somebody want to have the NCC keep doing some evaluation on this. If we want to go this way, we will need to define with a short text what we want. > > So, opinions? > > Regards, > Jordi > > > > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.theipv6company.com > The IPv6 Company > > This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. > > > > > From sander at steffann.nl Thu May 23 13:35:00 2019 From: sander at steffann.nl (Sander Steffann) Date: Thu, 23 May 2019 11:35:00 +0000 Subject: [address-policy-wg] Prefix size Message-ID: <5D740E01-0956-4752-809E-07B793B115D6@steffann.nl> Hi, Yesterday in the APWG session I promised to go to the routing WG and notify them of the possibility of IPv4 prefix lengths growing longer than /24 in the future. I think Geoff Huston just already made an excellent presentation that included that point, so thank you Geoff! Cheers, Sander -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: Message signed with OpenPGP URL: From phessler at theapt.org Wed May 29 10:25:10 2019 From: phessler at theapt.org (Peter Hessler) Date: Wed, 29 May 2019 10:25:10 +0200 Subject: [address-policy-wg] 2019-02 Review Phase (IPv4 Waiting List Implementation) In-Reply-To: References: Message-ID: <20190529082509.GT67787@gir.theapt.org> On 2019 May 12 (Sun) at 11:56:02 +0200 (+0200), Hansen, Christoffer wrote: : :On 07/05/2019 12:57, Randy Bush wrote: :> On 06/05/2019 13:10, Marco Schmidt wrote: :>> Policy proposal 2019-02, "IPv4 Waiting List Implementation" :>> is now in the Review Phase. :> :> we are here to do what we can to make the internet work. this :> helps by making connectivity as available as possible given :> the circumstances. : :Agrees with Randys comment. : :+1 from here. : : -Christoffer : I also agree with the policy proposal. -- Of course there's no reason for it, it's just our policy. From wusel+ml at uu.org Wed May 29 10:57:24 2019 From: wusel+ml at uu.org (Kai 'wusel' Siering) Date: Wed, 29 May 2019 10:57:24 +0200 Subject: [address-policy-wg] 2019-02 Review Phase (IPv4 Waiting List Implementation) In-Reply-To: References: Message-ID: <9a59a1eb-bcdf-80e3-5629-0e9cec6f50fa@uu.org> Hi, on 06.05.2019 13:10, Marco Schmidt wrote: > Dear colleagues, > > Policy proposal 2019-02, "IPv4 Waiting List Implementation" is now in the Review Phase. > > This proposal aims at creating a waiting list based on an allocation size of /24 once the RIPE NCC?s free IPv4 pool is exhausted. > > [?] > > As per the RIPE Policy Development Process (PDP), the purpose of this four week Review Phase is to continue discussion of the proposal, taking the impact analysis into consideration, and to review the full draft RIPE Policy Document. As Sebastian Wiesinger wrote in members-discuss: "The IPv4 pool will run out soon and after that there simply will be nothing to grab. In hindsight I wish we had just given out everything without reserving something for newcomers. I don't think it had the intended effect." I don't see this either, hence, while I agree that there should be some wording about the way the (already implicit) waiting list will be implemented/handled, I reject the proposal as-is due to the reduction of the assignment size. Reducing the assignment for new LIRs from /22 to /24 neither helps the community, nor the late-coming LIR in question. IPv4 is gone, we pray every other minute, so we should act accordingly. Regards, -kai From mschmidt at ripe.net Wed May 29 14:17:43 2019 From: mschmidt at ripe.net (Marco Schmidt) Date: Wed, 29 May 2019 14:17:43 +0200 Subject: [address-policy-wg] 2019-05 New Policy Proposal (Revised IPv4 assignment policy for IXPs) Message-ID: Dear colleagues, A new RIPE Policy proposal, 2019-05, "Revised IPv4 assignment policy for IXPs" is now available for discussion. This proposal aims to increase the reserved IPv4 pool for IXPs to a /15 and finetune assignment criteria. You can find the full proposal at: https://www.ripe.net/participate/policies/proposals/2019-05 As per the RIPE Policy Development Process (PDP), the purpose of this four week Discussion Phase is to discuss the proposal and provide feedback to the proposer. At the end of the Discussion Phase, the proposers, with the agreement of the WG Chairs, will decide how to proceed with the proposal. We encourage you to review this proposal and send your comments to before 27 June 2019. Regards, Marco Schmidt Policy Officer RIPE NCC Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum From sander at steffann.nl Wed May 29 14:47:00 2019 From: sander at steffann.nl (Sander Steffann) Date: Wed, 29 May 2019 14:47:00 +0200 Subject: [address-policy-wg] 2019-02 Review Phase (IPv4 Waiting List Implementation) In-Reply-To: <9a59a1eb-bcdf-80e3-5629-0e9cec6f50fa@uu.org> References: <9a59a1eb-bcdf-80e3-5629-0e9cec6f50fa@uu.org> Message-ID: <5BB547E8-15BC-4E63-AA66-1713B78AFD0B@steffann.nl> Hi Kai, > I don't see this either, hence, while I agree that there should be some wording about the way the (already implicit) waiting list will be implemented/handled, I reject the proposal as-is due to the reduction of the assignment size. > > Reducing the assignment for new LIRs from /22 to /24 neither helps the community, nor the late-coming LIR in question. This presentation from RIPE NCC at RIPE77 shows that changing the allocation size does help significantly: https://ripe77.ripe.net/presentations/71-Andrea_Cima_RIPE_77_APWG.pdf slide 14. > IPv4 is gone, we pray every other minute, so we should act accordingly. Unfortunately the world is not as simple as that :'( Cheers, Sander -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: Message signed with OpenPGP URL: From ripe at liopen.fr Wed May 29 15:11:31 2019 From: ripe at liopen.fr (Denis Fondras) Date: Wed, 29 May 2019 15:11:31 +0200 Subject: [address-policy-wg] 2019-05 New Policy Proposal (Revised IPv4 assignment policy for IXPs) In-Reply-To: References: Message-ID: <20190529131131.GQ53067@carcass.ledeuns.net> On Wed, May 29, 2019 at 02:17:43PM +0200, Marco Schmidt wrote: > This proposal aims to increase the reserved IPv4 pool for IXPs to a /15 and finetune assignment criteria. > > You can find the full proposal at: > https://www.ripe.net/participate/policies/proposals/2019-05 > Just because of "It no longer provides for IXPs that need more than a /23 of IPv4 space" I am against this proposal. Denis From nick at foobar.org Wed May 29 15:41:00 2019 From: nick at foobar.org (Nick Hilliard) Date: Wed, 29 May 2019 14:41:00 +0100 Subject: [address-policy-wg] 2019-05 New Policy Proposal (Revised IPv4 assignment policy for IXPs) In-Reply-To: <20190529131131.GQ53067@carcass.ledeuns.net> References: <20190529131131.GQ53067@carcass.ledeuns.net> Message-ID: Denis Fondras wrote on 29/05/2019 14:11: > On Wed, May 29, 2019 at 02:17:43PM +0200, Marco Schmidt wrote: >> This proposal aims to increase the reserved IPv4 pool for IXPs to a >> /15 and finetune assignment criteria. >> >> You can find the full proposal at: >> https://www.ripe.net/participate/policies/proposals/2019-05 >> > > Just because of "It no longer provides for IXPs that need more than a > /23 of IPv4 space" I am against this proposal. Could the NCC provide any stats on how many /22s have been assigned under the IXP assignment policy? /23 is 512 hosts, which is large by IXP standards. The PCH IXP directory suggests there are about 20 IXPs worldwide which are larger than 256 connected parties. Nick From alexp at ma.spb.ru Wed May 29 15:42:59 2019 From: alexp at ma.spb.ru (Alexandr Popov) Date: Wed, 29 May 2019 16:42:59 +0300 Subject: [address-policy-wg] 2019-05 New Policy Proposal (Revised IPv4 assignment policy for IXPs) In-Reply-To: References: Message-ID: <7608231559137379@iva8-b333b7f98ab0.qloud-c.yandex.net> IXPs can use Private-Use Networks such as 10.0.0.0/8. There is no technical need to spend a valuable resource for such purposes. 29.05.2019, 15:18, "Marco Schmidt" : > Dear colleagues, > > A new RIPE Policy proposal, 2019-05, "Revised IPv4 assignment policy for IXPs" is now available for discussion. > > This proposal aims to increase the reserved IPv4 pool for IXPs to a /15 and finetune assignment criteria. > > You can find the full proposal at: > https://www.ripe.net/participate/policies/proposals/2019-05 > > As per the RIPE Policy Development Process (PDP), the purpose of this four week Discussion Phase is to discuss the proposal and provide feedback to the proposer. > > At the end of the Discussion Phase, the proposers, with the agreement of the WG Chairs, will decide how to proceed with the proposal. > > We encourage you to review this proposal and send your comments to before 27 June 2019. > > Regards, > > Marco Schmidt > Policy Officer > RIPE NCC > > Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum From dominik at clouvider.co.uk Wed May 29 15:47:35 2019 From: dominik at clouvider.co.uk (Dominik Nowacki) Date: Wed, 29 May 2019 13:47:35 +0000 Subject: [address-policy-wg] 2019-05 New Policy Proposal (Revised IPv4 assignment policy for IXPs) In-Reply-To: <7608231559137379@iva8-b333b7f98ab0.qloud-c.yandex.net> References: , <7608231559137379@iva8-b333b7f98ab0.qloud-c.yandex.net> Message-ID: They can?t. What participant uses it already in their network ? With Kind Regards, Dominik Nowacki Clouvider Limited is a limited company registered in England and Wales. Registered number: 08750969. Registered office: 88 Wood Street, London, United Kingdom, EC2V 7RS. Please note that Clouvider Limited may monitor email traffic data and also the content of email for the purposes of security and staff training. This message contains confidential information and is intended only for the intended recipient. If you do not believe you are the intended recipient you should not disseminate, distribute or copy this e-mail. Please notify abuse at clouvider.net of this e-mail immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Clouvider Limited nor any of its employees therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. On 29 May 2019, at 14:43, Alexandr Popov > wrote: IXPs can use Private-Use Networks such as 10.0.0.0/8. There is no technical need to spend a valuable resource for such purposes. 29.05.2019, 15:18, "Marco Schmidt" >: Dear colleagues, A new RIPE Policy proposal, 2019-05, "Revised IPv4 assignment policy for IXPs" is now available for discussion. This proposal aims to increase the reserved IPv4 pool for IXPs to a /15 and finetune assignment criteria. You can find the full proposal at: https://www.ripe.net/participate/policies/proposals/2019-05 As per the RIPE Policy Development Process (PDP), the purpose of this four week Discussion Phase is to discuss the proposal and provide feedback to the proposer. At the end of the Discussion Phase, the proposers, with the agreement of the WG Chairs, will decide how to proceed with the proposal. We encourage you to review this proposal and send your comments to > before 27 June 2019. Regards, Marco Schmidt Policy Officer RIPE NCC Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum -------------- next part -------------- An HTML attachment was scrubbed... URL: From ripe at liopen.fr Wed May 29 15:58:16 2019 From: ripe at liopen.fr (Denis Fondras) Date: Wed, 29 May 2019 15:58:16 +0200 Subject: [address-policy-wg] 2019-05 New Policy Proposal (Revised IPv4 assignment policy for IXPs) In-Reply-To: <7608231559137379@iva8-b333b7f98ab0.qloud-c.yandex.net> References: <7608231559137379@iva8-b333b7f98ab0.qloud-c.yandex.net> Message-ID: <20190529135816.GR53067@carcass.ledeuns.net> On Wed, May 29, 2019 at 04:42:59PM +0300, Alexandr Popov wrote: > IXPs can use Private-Use Networks such as 10.0.0.0/8. > There is no technical need to spend a valuable resource for such purposes. > It has to be unique. On Wed, May 29, 2019 at 02:41:00PM +0100, Nick Hilliard wrote: > /23 is 512 hosts, which is large by IXP standards. The PCH IXP directory > suggests there are about 20 IXPs worldwide which are larger than 256 > connected parties. > And only 3 with more than 512 connected ASN. But can we imagine some ASN have more than 1 IP on the peering LAN ? I agree there is really a small chance an IXP will ask for more the /23. Still I can't see the point of this limitation. Denis From alexp at ma.spb.ru Wed May 29 16:12:35 2019 From: alexp at ma.spb.ru (Alexandr Popov) Date: Wed, 29 May 2019 17:12:35 +0300 Subject: [address-policy-wg] 2019-05 New Policy Proposal (Revised IPv4 assignment policy for IXPs) In-Reply-To: <20190529135816.GR53067@carcass.ledeuns.net> References: <7608231559137379@iva8-b333b7f98ab0.qloud-c.yandex.net> <20190529135816.GR53067@carcass.ledeuns.net> Message-ID: <7629971559139155@sas2-7b909973f402.qloud-c.yandex.net> The small technical difficulties of using private networks by IXPs are easily solved. Ordinary companies that will lack the IPv4 will have much greater difficulties. Right, the IPs for IXPs should be unique. Perhaps it makes sense to create a policy of allocation Private-Use IPs for IXPs? If IXPs will follow that policy, they will have unique private IPs. 29.05.2019, 16:58, "Denis Fondras" : > On Wed, May 29, 2019 at 04:42:59PM +0300, Alexandr Popov wrote: >> ?IXPs can use Private-Use Networks such as 10.0.0.0/8. >> ?There is no technical need to spend a valuable resource for such purposes. > > It has to be unique. > > On Wed, May 29, 2019 at 02:41:00PM +0100, Nick Hilliard wrote: >> ?/23 is 512 hosts, which is large by IXP standards. The PCH IXP directory >> ?suggests there are about 20 IXPs worldwide which are larger than 256 >> ?connected parties. > > And only 3 with more than 512 connected ASN. But can we imagine some ASN have > more than 1 IP on the peering LAN ? > > I agree there is really a small chance an IXP will ask for more the /23. Still I > can't see the point of this limitation. > > Denis From ripe-wgs at radu-adrian.feurdean.net Wed May 29 16:13:15 2019 From: ripe-wgs at radu-adrian.feurdean.net (Radu-Adrian FEURDEAN) Date: Wed, 29 May 2019 16:13:15 +0200 Subject: [address-policy-wg] =?utf-8?q?2019-05_New_Policy_Proposal_=28Rev?= =?utf-8?q?ised_IPv4_assignment_policy_for_IXPs=29?= In-Reply-To: <20190529131131.GQ53067@carcass.ledeuns.net> References: <20190529131131.GQ53067@carcass.ledeuns.net> Message-ID: <26224ebc-4822-4b65-944a-ff31d862519b@www.fastmail.com> On Wed, May 29, 2019, at 15:11, Denis Fondras wrote: > Just because of "It no longer provides for IXPs that need more than a > /23 of IPv4 > space" I am against this proposal. Hi, The alternative is that in just a few years it will no longer provide IXPs with any space. Right now, according to peeringdb, in RIPE region there are 5 IXPs holding a /21 and 5 (or 4, depending on how you consider the 2 LINX LANs) that hold a /22, and 14 (12, depending on how you count multi-LAN IXPs) that hold a /23. Let's hear their point of view, since building an IXP so big takes a lot of time (took almost 9 years for FranceIX to get there). Those being said, I'm in favour of the proposal. Just one reserve on wording of the assignment of "dust" (less than /24): if a request (for smaller than /24) is being made before the reserved pool exhaustion, will it be taken from he reserved pool or from the "dust" ? -- Radu-Adrian FEURDEAN From wusel+ml at uu.org Wed May 29 16:33:07 2019 From: wusel+ml at uu.org (Kai 'wusel' Siering) Date: Wed, 29 May 2019 16:33:07 +0200 Subject: [address-policy-wg] 2019-05 New Policy Proposal (Revised IPv4 assignment policy for IXPs) In-Reply-To: References: Message-ID: Moin, on 29.05.2019 14:17, Marco Schmidt wrote: > Dear colleagues, > > A new RIPE Policy proposal, 2019-05, "Revised IPv4 assignment policy for IXPs" is now available for discussion. > > This proposal aims to increase the reserved IPv4 pool for IXPs to a /15 and finetune assignment criteria. > > You can find the full proposal at: > https://www.ripe.net/participate/policies/proposals/2019-05 > > [?] Why is there a need for "globally-unique (but not necessarily globally-routed) IPv4 space" for IXPs? The IXPs I've experienced explicitely prohibit announcment (i. e. routing) of their space nor announce it theirselves; so why spend another whole /15 as private address space? Obviously, there is no need for global routabillity, where is the need for global uniqueness and why can't this be solved differently (everyone has to cope with IPv4 scarceness, why can't IXPs)? As the pool of unallocated IPv4 addresses depletes, new IXPs will need to adopt new strategies, just like their customers. I'd support a movement to repurpose e. g. 198.18.0.0/15 for post-exhaustion IXP address space ? if that's coordinated between the RIRs, it would help to support emerging IXPs for some time. Churning even more IPv4 space for local uses feels wrong: I oppose 2019-05. Regards, -kai From ripe at liopen.fr Wed May 29 16:33:38 2019 From: ripe at liopen.fr (Denis Fondras) Date: Wed, 29 May 2019 16:33:38 +0200 Subject: [address-policy-wg] 2019-05 New Policy Proposal (Revised IPv4 assignment policy for IXPs) In-Reply-To: <26224ebc-4822-4b65-944a-ff31d862519b@www.fastmail.com> References: <20190529131131.GQ53067@carcass.ledeuns.net> <26224ebc-4822-4b65-944a-ff31d862519b@www.fastmail.com> Message-ID: <20190529143338.GS53067@carcass.ledeuns.net> On Wed, May 29, 2019 at 04:13:15PM +0200, Radu-Adrian FEURDEAN wrote: > The alternative is that in just a few years it will no longer provide IXPs > with any space. > Well, I agree that standing against this proposal on such a small point is a bit strong (I am totally in favor of reserving a /15 to IXPs) but I think setting in stone a limitation without a rationale does not make sense. I won't argue more, I guess you see my point :) Denis From aris.lambrianidis at ams-ix.net Wed May 29 16:42:07 2019 From: aris.lambrianidis at ams-ix.net (Aris Lambrianidis) Date: Wed, 29 May 2019 16:42:07 +0200 Subject: [address-policy-wg] 2019-05 New Policy Proposal (Revised IPv4 assignment policy for IXPs) In-Reply-To: <7629971559139155@sas2-7b909973f402.qloud-c.yandex.net> References: <7608231559137379@iva8-b333b7f98ab0.qloud-c.yandex.net> <20190529135816.GR53067@carcass.ledeuns.net> <7629971559139155@sas2-7b909973f402.qloud-c.yandex.net> Message-ID: <4A68F6EE-9503-4078-A5BF-11E081822236@ams-ix.net> Hello, Some considerations about the pros and cons of using RFC1918 addresses (as well as other methods) were presented here: https://youtu.be/uJOtfiHDCMw?t=380 With these in mind, I don't think RFC1918 addresses are a clean, scalable solution which works, something which I believe the authors of the original policy had in mind. Kind regards, Aris PS: Perhaps pushing vendors for RFC5549 support is a more long term solution? > On 29 May 2019, at 16:12, Alexandr Popov wrote: > > The small technical difficulties of using private networks by IXPs are easily solved. > Ordinary companies that will lack the IPv4 will have much greater difficulties. > Right, the IPs for IXPs should be unique. > Perhaps it makes sense to create a policy of allocation Private-Use IPs for IXPs? > If IXPs will follow that policy, they will have unique private IPs. > > 29.05.2019, 16:58, "Denis Fondras" : >> On Wed, May 29, 2019 at 04:42:59PM +0300, Alexandr Popov wrote: >>> IXPs can use Private-Use Networks such as 10.0.0.0/8. >>> There is no technical need to spend a valuable resource for such purposes. >> >> It has to be unique. >> >> On Wed, May 29, 2019 at 02:41:00PM +0100, Nick Hilliard wrote: >>> /23 is 512 hosts, which is large by IXP standards. The PCH IXP directory >>> suggests there are about 20 IXPs worldwide which are larger than 256 >>> connected parties. >> >> And only 3 with more than 512 connected ASN. But can we imagine some ASN have >> more than 1 IP on the peering LAN ? >> >> I agree there is really a small chance an IXP will ask for more the /23. Still I >> can't see the point of this limitation. >> >> Denis > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From christoffer at netravnen.de Wed May 29 17:35:58 2019 From: christoffer at netravnen.de (Hansen, Christoffer) Date: Wed, 29 May 2019 17:35:58 +0200 Subject: [address-policy-wg] 2019-05 New Policy Proposal (Revised IPv4 assignment policy for IXPs) In-Reply-To: References: <20190529131131.GQ53067@carcass.ledeuns.net> Message-ID: <720e6b1e-07d6-db8d-d9f0-695739669d0f@netravnen.de> On 29/05/2019 15:41, Nick Hilliard wrote: > Could the NCC provide any stats on how many /22s have been assigned > under the IXP assignment policy? Agreed! Any historical data/graphs are a welcomed addition to the discussion. > /23 is 512 hosts, which is large by IXP standards. The PCH IXP directory > suggests there are about 20 IXPs worldwide which are larger than 256 > connected parties. 20 is very accurate. Roughly the same number when using PeeringDB as data source to do the math. [Connected networks to IXP Lan] ``` curl -snGL -X GET https://peeringdb.com/api/netixlan \ --data-urlencode fields=ix_id,name,ixlan_id | \ jq '.data | group_by(.ixlan_id) | map({"count":length,"data":(unique_by(.ixlan_id)[])}) | sort_by(-.count)' ``` Christoffer -------------- next part -------------- [ { "count": 1261, "data": { "ix_id": 171, "name": "IX.br (PTT.br) S?o Paulo: ATM/MPLA", "ixlan_id": 171 } }, { "count": 924, "data": { "ix_id": 26, "name": "AMS-IX", "ixlan_id": 26 } }, { "count": 915, "data": { "ix_id": 31, "name": "DE-CIX Frankfurt: DE-CIX Frankfurt Peering LAN", "ixlan_id": 31 } }, { "count": 812, "data": { "ix_id": 18, "name": "LINX LON1: Main", "ixlan_id": 18 } }, { "count": 416, "data": { "ix_id": 64, "name": "NL-ix: Main", "ixlan_id": 64 } }, { "count": 378, "data": { "ix_id": 359, "name": "France-IX Paris", "ixlan_id": 359 } }, { "count": 376, "data": { "ix_id": 1, "name": "Equinix Ashburn", "ixlan_id": 1 } }, { "count": 374, "data": { "ix_id": 592, "name": "NAPAfrica IX Johannesburg: Peering", "ixlan_id": 592 } }, { "count": 372, "data": { "ix_id": 491, "name": "EPIX.Katowice", "ixlan_id": 491 } }, { "count": 353, "data": { "ix_id": 158, "name": "Equinix Singapore", "ixlan_id": 158 } }, { "count": 342, "data": { "ix_id": 321, "name": "LINX LON2", "ixlan_id": 321 } }, { "count": 331, "data": { "ix_id": 13, "name": "SIX Seattle: MTU 1500", "ixlan_id": 13 } }, { "count": 318, "data": { "ix_id": 42, "name": "HKIX: HKIX Peering LAN", "ixlan_id": 1432 } }, { "count": 316, "data": { "ix_id": 142, "name": "CoreSite - Any2 California", "ixlan_id": 142 } }, { "count": 278, "data": { "ix_id": 255, "name": "Equinix Paris: Equinix IX - PA Metro", "ixlan_id": 255 } }, { "count": 269, "data": { "ix_id": 2, "name": "Equinix Chicago", "ixlan_id": 2 } }, { "count": 260, "data": { "ix_id": 177, "name": "IX.br (PTT.br) Rio de Janeiro: ATM/MPLA", "ixlan_id": 177 } }, { "count": 259, "data": { "ix_id": 474, "name": "EPIX.Warszawa-KIX", "ixlan_id": 474 } }, { "count": 254, "data": { "ix_id": 358, "name": "DATAIX", "ixlan_id": 358 } }, { "count": 252, "data": { "ix_id": 35, "name": "MIX-IT", "ixlan_id": 35 } }, { "count": 251, "data": { "ix_id": 100, "name": "MSK-IX Moscow: MSK-IX peering network", "ixlan_id": 100 } }, { "count": 241, "data": { "ix_id": 24, "name": "TorIX", "ixlan_id": 24 } }, { "count": 231, "data": { "ix_id": 53, "name": "LONAP: LON0", "ixlan_id": 53 } }, { "count": 227, "data": { "ix_id": 94, "name": "Equinix Sydney", "ixlan_id": 94 } }, { "count": 226, "data": { "ix_id": 5, "name": "Equinix San Jose", "ixlan_id": 5 } }, { "count": 222, "data": { "ix_id": 780, "name": "MegaIX Sydney: MegaIX", "ixlan_id": 780 } }, { "count": 222, "data": { "ix_id": 804, "name": "DE-CIX New York: DE-CIX New York Peering LAN", "ixlan_id": 804 } }, { "count": 221, "data": { "ix_id": 126, "name": "BBIX Tokyo", "ixlan_id": 126 } }, { "count": 219, "data": { "ix_id": 832, "name": "Mumbai IX: Mumbai IX", "ixlan_id": 1361 } }, { "count": 213, "data": { "ix_id": 30, "name": "JPIX TOKYO", "ixlan_id": 30 } }, { "count": 205, "data": { "ix_id": 14, "name": "NYIIX", "ixlan_id": 14 } }, { "count": 201, "data": { "ix_id": 70, "name": "Netnod Stockholm: STH-A -- MTU1500", "ixlan_id": 70 } }, { "count": 192, "data": { "ix_id": 716, "name": "IX Australia NSW: NSW-IX", "ixlan_id": 716 } }, { "count": 191, "data": { "ix_id": 597, "name": "NAPAfrica IX Cape Town", "ixlan_id": 597 } }, { "count": 184, "data": { "ix_id": 3, "name": "Equinix Dallas", "ixlan_id": 3 } }, { "count": 182, "data": { "ix_id": 60, "name": "SwissIX: Peering", "ixlan_id": 60 } }, { "count": 181, "data": { "ix_id": 95, "name": "JPNAP Tokyo", "ixlan_id": 95 } }, { "count": 177, "data": { "ix_id": 125, "name": "Equinix Hong Kong", "ixlan_id": 125 } }, { "count": 177, "data": { "ix_id": 264, "name": "Equinix Warsaw (PLIX)", "ixlan_id": 264 } }, { "count": 167, "data": { "ix_id": 71, "name": "NIX.CZ: Public peering VLAN", "ixlan_id": 71 } }, { "count": 162, "data": { "ix_id": 17, "name": "Equinix Miami (formerly NOTA)", "ixlan_id": 17 } }, { "count": 160, "data": { "ix_id": 123, "name": "KleyReX: Peering LAN", "ixlan_id": 123 } }, { "count": 159, "data": { "ix_id": 1627, "name": "Extreme IX Mumbai: Extreme IX", "ixlan_id": 1408 } }, { "count": 153, "data": { "ix_id": 22, "name": "Digital Realty Atlanta", "ixlan_id": 22 } }, { "count": 151, "data": { "ix_id": 12, "name": "Equinix New York", "ixlan_id": 12 } }, { "count": 151, "data": { "ix_id": 713, "name": "Peering.cz", "ixlan_id": 713 } }, { "count": 148, "data": { "ix_id": 50, "name": "VIX", "ixlan_id": 50 } }, { "count": 132, "data": { "ix_id": 91, "name": "ECIX-DUS", "ixlan_id": 91 } }, { "count": 128, "data": { "ix_id": 954, "name": "FL-IX", "ixlan_id": 954 } }, { "count": 124, "data": { "ix_id": 7, "name": "Equinix Palo Alto", "ixlan_id": 7 } }, { "count": 122, "data": { "ix_id": 173, "name": "IX.br (PTT.br) Porto Alegre: ATM/MPLA", "ixlan_id": 173 } }, { "count": 121, "data": { "ix_id": 167, "name": "Equinix Tokyo", "ixlan_id": 167 } }, { "count": 119, "data": { "ix_id": 1277, "name": "DE-CIX Madrid: DE-CIX Madrid Peering LAN", "ixlan_id": 1250 } }, { "count": 115, "data": { "ix_id": 250, "name": "MyIX", "ixlan_id": 250 } }, { "count": 113, "data": { "ix_id": 655, "name": "GigaNET: Global exchange", "ixlan_id": 655 } }, { "count": 112, "data": { "ix_id": 115, "name": "TOP-IX: Public Peering VLAN", "ixlan_id": 115 } }, { "count": 112, "data": { "ix_id": 327, "name": "DTEL-IX: PUBLIC", "ixlan_id": 1380 } }, { "count": 112, "data": { "ix_id": 1842, "name": "Speed-IX: SPEED-IX", "ixlan_id": 1433 } }, { "count": 111, "data": { "ix_id": 87, "name": "BCIX: BCIX Peering LAN", "ixlan_id": 87 } }, { "count": 111, "data": { "ix_id": 172, "name": "STHIX - Stockholm: STH Peering", "ixlan_id": 172 } }, { "count": 110, "data": { "ix_id": 710, "name": "IX.br (PTT.br) Fortaleza: ATM/MPLA", "ixlan_id": 710 } }, { "count": 109, "data": { "ix_id": 676, "name": "ECIX-FRA", "ixlan_id": 676 } }, { "count": 108, "data": { "ix_id": 63, "name": "ESPANIX Madrid Lower LAN", "ixlan_id": 63 } }, { "count": 108, "data": { "ix_id": 779, "name": "MegaIX Melbourne: MegaIX", "ixlan_id": 779 } }, { "count": 107, "data": { "ix_id": 129, "name": "JINX: JINX Peering", "ixlan_id": 129 } }, { "count": 107, "data": { "ix_id": 429, "name": "SGIX: Peering LAN", "ixlan_id": 429 } }, { "count": 105, "data": { "ix_id": 70, "name": "Netnod Stockholm: STH-B -- MTU1500", "ixlan_id": 1311 } }, { "count": 104, "data": { "ix_id": 4, "name": "Equinix Los Angeles", "ixlan_id": 4 } }, { "count": 103, "data": { "ix_id": 119, "name": "Equinix S?o Paulo: Equinix IX - SP Metro", "ixlan_id": 119 } }, { "count": 102, "data": { "ix_id": 583, "name": "LINX Manchester", "ixlan_id": 583 } }, { "count": 101, "data": { "ix_id": 184, "name": "UA-IX", "ixlan_id": 184 } }, { "count": 99, "data": { "ix_id": 375, "name": "OpenIXP / NiCE", "ixlan_id": 375 } }, { "count": 94, "data": { "ix_id": 2035, "name": "Eurasia Peering IX: Peering LAN", "ixlan_id": 1480 } }, { "count": 93, "data": { "ix_id": 52, "name": "KINX", "ixlan_id": 52 } }, { "count": 93, "data": { "ix_id": 1514, "name": "PIT Santiago - PIT Chile: LAN", "ixlan_id": 1350 } }, { "count": 92, "data": { "ix_id": 165, "name": "NWAX: Primary Peering VLAN", "ixlan_id": 165 } }, { "count": 92, "data": { "ix_id": 248, "name": "DE-CIX Munich: DE-CIX Munich Peering LAN", "ixlan_id": 248 } }, { "count": 92, "data": { "ix_id": 1323, "name": "Extreme IX Delhi: Extreme IX LAN", "ixlan_id": 1268 } }, { "count": 91, "data": { "ix_id": 74, "name": "DE-CIX Hamburg: DE-CIX Hamburg Peering LAN", "ixlan_id": 74 } }, { "count": 91, "data": { "ix_id": 446, "name": "MICE: Shared Peering", "ixlan_id": 446 } }, { "count": 88, "data": { "ix_id": 481, "name": "Thinx", "ixlan_id": 481 } }, { "count": 87, "data": { "ix_id": 69, "name": "LyonIX: lyonix-peering", "ixlan_id": 69 } }, { "count": 87, "data": { "ix_id": 482, "name": "TPIX", "ixlan_id": 482 } }, { "count": 85, "data": { "ix_id": 1214, "name": "DE-CIX Dusseldorf: DE-CIX Dusseldorf Peering LAN", "ixlan_id": 1214 } }, { "count": 84, "data": { "ix_id": 969, "name": "NAPAfrica IX Durban", "ixlan_id": 969 } }, { "count": 83, "data": { "ix_id": 48, "name": "INEX LAN1: INEX LAN1", "ixlan_id": 48 } }, { "count": 82, "data": { "ix_id": 297, "name": "LU-CIX", "ixlan_id": 297 } }, { "count": 82, "data": { "ix_id": 331, "name": "BIX.BG: Main", "ixlan_id": 331 } }, { "count": 82, "data": { "ix_id": 1088, "name": "Global-IX", "ixlan_id": 1088 } }, { "count": 81, "data": { "ix_id": 174, "name": "IX.br (PTT.br) Curitiba: ATM/MPLA", "ixlan_id": 174 } }, { "count": 80, "data": { "ix_id": 270, "name": "InterLAN: InterLAN Peering Network", "ixlan_id": 270 } }, { "count": 79, "data": { "ix_id": 181, "name": "CABASE-BUE - IX Argentina (Buenos Aires): BUE", "ixlan_id": 181 } }, { "count": 79, "data": { "ix_id": 781, "name": "MegaIX Brisbane: MegaIX", "ixlan_id": 781 } }, { "count": 77, "data": { "ix_id": 984, "name": "MegaIX Auckland: MegaIX", "ixlan_id": 984 } }, { "count": 75, "data": { "ix_id": 513, "name": "IX Australia VIC: VIC-IX", "ixlan_id": 513 } }, { "count": 73, "data": { "ix_id": 2084, "name": "LocIX: Peering LAN", "ixlan_id": 1508 } }, { "count": 72, "data": { "ix_id": 325, "name": "Digital Realty New York", "ixlan_id": 325 } }, { "count": 70, "data": { "ix_id": 209, "name": "ECIX-BER", "ixlan_id": 209 } }, { "count": 70, "data": { "ix_id": 1149, "name": "DE-CIX Marseille: DE-CIX Marseille Peering LAN", "ixlan_id": 1149 } }, { "count": 69, "data": { "ix_id": 977, "name": "AKL-IX: AKL-IX", "ixlan_id": 977 } }, { "count": 68, "data": { "ix_id": 564, "name": "JPIX OSAKA", "ixlan_id": 564 } }, { "count": 68, "data": { "ix_id": 587, "name": "UAE-IX: UAE-IX Peering LAN", "ixlan_id": 587 } }, { "count": 66, "data": { "ix_id": 59, "name": "BNIX", "ixlan_id": 59 } }, { "count": 66, "data": { "ix_id": 145, "name": "JPNAP Osaka", "ixlan_id": 145 } }, { "count": 66, "data": { "ix_id": 254, "name": "CoreSite - Any2 Denver ", "ixlan_id": 254 } }, { "count": 66, "data": { "ix_id": 823, "name": "TPIX-TW", "ixlan_id": 823 } }, { "count": 65, "data": { "ix_id": 21, "name": "IX Australia WA: WA-IX", "ixlan_id": 21 } }, { "count": 65, "data": { "ix_id": 107, "name": "MSK-IX Saint-Petersburg: MSK-IX Saint-Petersburg peering network", "ixlan_id": 107 } }, { "count": 65, "data": { "ix_id": 291, "name": "ECIX-HAM", "ixlan_id": 291 } }, { "count": 64, "data": { "ix_id": 121, "name": "NaMeX Rome IXP: VLAN Peering", "ixlan_id": 121 } }, { "count": 64, "data": { "ix_id": 249, "name": "KCIX", "ixlan_id": 249 } }, { "count": 63, "data": { "ix_id": 155, "name": "SFMIX", "ixlan_id": 155 } }, { "count": 63, "data": { "ix_id": 2274, "name": "EVIX: Peering LAN", "ixlan_id": 1552 } }, { "count": 62, "data": { "ix_id": 699, "name": "NetIX", "ixlan_id": 699 } }, { "count": 62, "data": { "ix_id": 1249, "name": "DE-CIX Dallas: DE-CIX Dallas Peering LAN", "ixlan_id": 1241 } }, { "count": 60, "data": { "ix_id": 880, "name": "France-IX Marseille", "ixlan_id": 880 } }, { "count": 58, "data": { "ix_id": 576, "name": "IX Australia QLD: QLD-IX", "ixlan_id": 576 } }, { "count": 57, "data": { "ix_id": 83, "name": "NIX1", "ixlan_id": 83 } }, { "count": 57, "data": { "ix_id": 863, "name": "VANIX", "ixlan_id": 863 } }, { "count": 57, "data": { "ix_id": 909, "name": "BBIX Singapore", "ixlan_id": 909 } }, { "count": 56, "data": { "ix_id": 662, "name": "Phoenix IX: Production", "ixlan_id": 662 } }, { "count": 55, "data": { "ix_id": 128, "name": "SOLIX", "ixlan_id": 128 } }, { "count": 55, "data": { "ix_id": 326, "name": "B-IX", "ixlan_id": 326 } }, { "count": 55, "data": { "ix_id": 1086, "name": "MASS-IX: ISP Peering LAN", "ixlan_id": 1086 } }, { "count": 55, "data": { "ix_id": 1242, "name": "W-IX: vlan800", "ixlan_id": 1239 } }, { "count": 55, "data": { "ix_id": 2149, "name": "PITER-IX: SPB_PEERING_VLAN", "ixlan_id": 1530 } }, { "count": 55, "data": { "ix_id": 2149, "name": "PITER-IX: MSK_PEERING_VLAN", "ixlan_id": 1531 } }, { "count": 54, "data": { "ix_id": 34, "name": "SFINX", "ixlan_id": 34 } }, { "count": 53, "data": { "ix_id": 97, "name": "APE", "ixlan_id": 97 } }, { "count": 51, "data": { "ix_id": 639, "name": "YYCIX", "ixlan_id": 639 } }, { "count": 50, "data": { "ix_id": 777, "name": "LINX NoVA", "ixlan_id": 777 } }, { "count": 50, "data": { "ix_id": 1146, "name": "ESPANIX Madrid Upper LAN", "ixlan_id": 1146 } }, { "count": 49, "data": { "ix_id": 73, "name": "ECIX-MUC / INXS by ecix", "ixlan_id": 73 } }, { "count": 49, "data": { "ix_id": 488, "name": "IXPN Lagos", "ixlan_id": 488 } }, { "count": 48, "data": { "ix_id": 55, "name": "BiX", "ixlan_id": 55 } }, { "count": 48, "data": { "ix_id": 105, "name": "PIPE Networks Sydney", "ixlan_id": 105 } }, { "count": 48, "data": { "ix_id": 387, "name": "INEX LAN2", "ixlan_id": 387 } }, { "count": 48, "data": { "ix_id": 565, "name": "Boston Internet Exchange", "ixlan_id": 565 } }, { "count": 47, "data": { "ix_id": 29, "name": "Equinix Zurich: Equinix IX - ZH Metro", "ixlan_id": 29 } }, { "count": 47, "data": { "ix_id": 577, "name": "AMS-IX Hong Kong", "ixlan_id": 577 } }, { "count": 47, "data": { "ix_id": 786, "name": "BBIX Osaka", "ixlan_id": 786 } }, { "count": 46, "data": { "ix_id": 299, "name": "NIX.SK", "ixlan_id": 299 } }, { "count": 45, "data": { "ix_id": 84, "name": "SIX.SK", "ixlan_id": 84 } }, { "count": 44, "data": { "ix_id": 610, "name": "DINX: DINX Peering", "ixlan_id": 610 } }, { "count": 44, "data": { "ix_id": 1235, "name": "MegaIX Perth: MegaIX", "ixlan_id": 1235 } }, { "count": 43, "data": { "ix_id": 705, "name": "IX.br (PTT.br) Recife: ATM/MPLA", "ixlan_id": 705 } }, { "count": 42, "data": { "ix_id": 98, "name": "FICIX 2 (Helsinki): IPv4+IPv6 MTU 1500", "ixlan_id": 98 } }, { "count": 42, "data": { "ix_id": 240, "name": "MINAP Milan: MINAP", "ixlan_id": 240 } }, { "count": 42, "data": { "ix_id": 70, "name": "Netnod Stockholm: STH-A -- MTU4470", "ixlan_id": 1310 } }, { "count": 42, "data": { "ix_id": 70, "name": "Netnod Stockholm: STH-B -- MTU4470", "ixlan_id": 1312 } }, { "count": 42, "data": { "ix_id": 210, "name": "IIX", "ixlan_id": 1379 } }, { "count": 41, "data": { "ix_id": 62, "name": "CATNIX", "ixlan_id": 62 } }, { "count": 41, "data": { "ix_id": 347, "name": "GR-IX::Athens: Peering Lan", "ixlan_id": 347 } }, { "count": 41, "data": { "ix_id": 1997, "name": "Equinix London: Equinix IX - LD Metro", "ixlan_id": 1464 } }, { "count": 41, "data": { "ix_id": 193, "name": "Netnod Copenhagen: 9K-BLUE", "ixlan_id": 1475 } }, { "count": 41, "data": { "ix_id": 355, "name": "QIX", "ixlan_id": 1669 } }, { "count": 40, "data": { "ix_id": 33, "name": "CIXP", "ixlan_id": 33 } }, { "count": 40, "data": { "ix_id": 82, "name": "PacificWave", "ixlan_id": 82 } }, { "count": 40, "data": { "ix_id": 301, "name": "RoNIX", "ixlan_id": 301 } }, { "count": 40, "data": { "ix_id": 303, "name": "CIX", "ixlan_id": 303 } }, { "count": 40, "data": { "ix_id": 1207, "name": "IX-Denver: IX-Denver Fabric", "ixlan_id": 1207 } }, { "count": 39, "data": { "ix_id": 11, "name": "Equinix Seattle", "ixlan_id": 11 } }, { "count": 39, "data": { "ix_id": 176, "name": "IX.br (PTT.br) Belo Horizonte: ATM/MPLA", "ixlan_id": 176 } }, { "count": 39, "data": { "ix_id": 178, "name": "IX.br (PTT.br) Bras?lia: ATM/MPLA", "ixlan_id": 178 } }, { "count": 39, "data": { "ix_id": 311, "name": "VSIX: Primary", "ixlan_id": 311 } }, { "count": 39, "data": { "ix_id": 344, "name": "CINX: CINX Peering", "ixlan_id": 344 } }, { "count": 39, "data": { "ix_id": 453, "name": "FIXO", "ixlan_id": 453 } }, { "count": 39, "data": { "ix_id": 986, "name": "MidWest-IX - Indy", "ixlan_id": 986 } }, { "count": 39, "data": { "ix_id": 1449, "name": "BBIX Hong Kong", "ixlan_id": 1322 } }, { "count": 38, "data": { "ix_id": 1623, "name": "AMS-IX India", "ixlan_id": 1370 } }, { "count": 38, "data": { "ix_id": 1998, "name": "Equinix Frankfurt: Equinix IX - FR Metro", "ixlan_id": 1463 } }, { "count": 37, "data": { "ix_id": 236, "name": "KIXP - Nairobi: Peering LAN", "ixlan_id": 236 } }, { "count": 37, "data": { "ix_id": 372, "name": "Balcan-IX", "ixlan_id": 372 } }, { "count": 37, "data": { "ix_id": 415, "name": "IX.br (PTT.br) Campinas: ATM/MPLA", "ixlan_id": 415 } }, { "count": 37, "data": { "ix_id": 556, "name": "IX.br (PTT.br) Salvador: ATM/MPLA", "ixlan_id": 556 } }, { "count": 37, "data": { "ix_id": 1006, "name": "DET-IX", "ixlan_id": 1006 } }, { "count": 36, "data": { "ix_id": 239, "name": "ChIX", "ixlan_id": 239 } }, { "count": 36, "data": { "ix_id": 348, "name": "WIX-NZ", "ixlan_id": 348 } }, { "count": 36, "data": { "ix_id": 935, "name": "AMS-IX BA", "ixlan_id": 935 } }, { "count": 36, "data": { "ix_id": 965, "name": "MegaIX Singapore", "ixlan_id": 965 } }, { "count": 36, "data": { "ix_id": 1026, "name": "Equinix Melbourne", "ixlan_id": 1026 } }, { "count": 36, "data": { "ix_id": 193, "name": "Netnod Copenhagen: 9K-GREEN", "ixlan_id": 1474 } }, { "count": 35, "data": { "ix_id": 230, "name": "POZIX", "ixlan_id": 230 } }, { "count": 35, "data": { "ix_id": 338, "name": "CoreSite - Any2 Silicon Valley", "ixlan_id": 338 } }, { "count": 35, "data": { "ix_id": 78, "name": "DIX: DIX LAN", "ixlan_id": 1283 } }, { "count": 34, "data": { "ix_id": 745, "name": "LINX Scotland: LINX Scotland", "ixlan_id": 745 } }, { "count": 33, "data": { "ix_id": 175, "name": "IX.br (PTT.br) Florian?polis: ATM/MPLA", "ixlan_id": 175 } }, { "count": 33, "data": { "ix_id": 944, "name": "AMS-IX Chicago", "ixlan_id": 944 } }, { "count": 33, "data": { "ix_id": 1786, "name": "Extreme IX Chennai: Extreme IX LAN", "ixlan_id": 1421 } }, { "count": 32, "data": { "ix_id": 72, "name": "GigaPIX: LAN1", "ixlan_id": 72 } }, { "count": 32, "data": { "ix_id": 703, "name": "MBIX: Public Peering", "ixlan_id": 703 } }, { "count": 31, "data": { "ix_id": 228, "name": "RIX", "ixlan_id": 228 } }, { "count": 31, "data": { "ix_id": 364, "name": "SMILE-IXP: VLAN333", "ixlan_id": 364 } }, { "count": 31, "data": { "ix_id": 1308, "name": "DF-IX: Main", "ixlan_id": 1261 } }, { "count": 30, "data": { "ix_id": 85, "name": "NDIX", "ixlan_id": 85 } }, { "count": 30, "data": { "ix_id": 424, "name": "SOX d.o.o. Serbia", "ixlan_id": 424 } }, { "count": 30, "data": { "ix_id": 603, "name": "IX.br (PTT.br) Campina Grande: ATM/MPLA", "ixlan_id": 603 } }, { "count": 30, "data": { "ix_id": 1812, "name": "Asteroid Amsterdam: Asteroid Amsterdam Peering LAN", "ixlan_id": 1427 } }, { "count": 30, "data": { "ix_id": 2031, "name": "Equinix Amsterdam: Equinix IX - AM Metro", "ixlan_id": 1476 } }, { "count": 29, "data": { "ix_id": 2005, "name": "BALT-IX: BALT-IX", "ixlan_id": 1469 } }, { "count": 29, "data": { "ix_id": 2163, "name": "FCIX", "ixlan_id": 1533 } }, { "count": 28, "data": { "ix_id": 706, "name": "IX.br (PTT.br) Vit?ria: ATM/MPLA", "ixlan_id": 706 } }, { "count": 28, "data": { "ix_id": 818, "name": "IX.br (PTT.br) Maring?: ATM/MPLA", "ixlan_id": 818 } }, { "count": 28, "data": { "ix_id": 1320, "name": "Hopus", "ixlan_id": 1267 } }, { "count": 27, "data": { "ix_id": 9, "name": "Equinix Atlanta", "ixlan_id": 9 } }, { "count": 27, "data": { "ix_id": 224, "name": "NIXI Mumbai", "ixlan_id": 224 } }, { "count": 27, "data": { "ix_id": 361, "name": "TIX - Tanzania", "ixlan_id": 361 } }, { "count": 27, "data": { "ix_id": 2447, "name": "4b42 Internet Exchange Point: Switzerland", "ixlan_id": 1725 } }, { "count": 26, "data": { "ix_id": 23, "name": "NYIIX Los Angeles", "ixlan_id": 23 } }, { "count": 26, "data": { "ix_id": 1150, "name": "DE-CIX Istanbul: DE-CIX Istanbul Peering LAN", "ixlan_id": 1150 } }, { "count": 26, "data": { "ix_id": 1285, "name": "SIX Seattle (Jumbo): MTU 9000", "ixlan_id": 1257 } }, { "count": 26, "data": { "ix_id": 1329, "name": "Community-IX", "ixlan_id": 1270 } }, { "count": 25, "data": { "ix_id": 313, "name": "R_iX: Main", "ixlan_id": 313 } }, { "count": 25, "data": { "ix_id": 314, "name": "IX.br (PTT.br) Londrina: ATM/MPLA", "ixlan_id": 314 } }, { "count": 25, "data": { "ix_id": 435, "name": "IX Leeds", "ixlan_id": 435 } }, { "count": 25, "data": { "ix_id": 135, "name": "N-IX: Peering", "ixlan_id": 1243 } }, { "count": 25, "data": { "ix_id": 2279, "name": "JBIX: JBIX", "ixlan_id": 1646 } }, { "count": 24, "data": { "ix_id": 43, "name": "TWIX", "ixlan_id": 43 } }, { "count": 24, "data": { "ix_id": 469, "name": "MCIX - Matrix Networks", "ixlan_id": 469 } }, { "count": 24, "data": { "ix_id": 538, "name": "RTIX", "ixlan_id": 538 } }, { "count": 24, "data": { "ix_id": 1178, "name": "MegaIX Ashburn: MegaIX", "ixlan_id": 1178 } }, { "count": 24, "data": { "ix_id": 1354, "name": "Beirut IX", "ixlan_id": 1287 } }, { "count": 23, "data": { "ix_id": 93, "name": "SOX", "ixlan_id": 93 } }, { "count": 23, "data": { "ix_id": 627, "name": "SNAP", "ixlan_id": 627 } }, { "count": 23, "data": { "ix_id": 1025, "name": "BKNIX: Bangkok", "ixlan_id": 1025 } }, { "count": 22, "data": { "ix_id": 711, "name": "IX.br (PTT.br) Bel?m: ATM/MPLA", "ixlan_id": 711 } }, { "count": 22, "data": { "ix_id": 833, "name": "TPAIX", "ixlan_id": 833 } }, { "count": 22, "data": { "ix_id": 948, "name": "Equinix Osaka", "ixlan_id": 948 } }, { "count": 22, "data": { "ix_id": 1228, "name": "CDIX", "ixlan_id": 1228 } }, { "count": 22, "data": { "ix_id": 1303, "name": "CNIX", "ixlan_id": 1307 } }, { "count": 22, "data": { "ix_id": 1684, "name": "IX.br (PTT.br) Aracaju: ATM/MLPA", "ixlan_id": 1405 } }, { "count": 22, "data": { "ix_id": 1977, "name": "CLOUD-IX MSK", "ixlan_id": 1500 } }, { "count": 21, "data": { "ix_id": 92, "name": "DIX-IE", "ixlan_id": 92 } }, { "count": 21, "data": { "ix_id": 253, "name": "NAP.EC - UIO", "ixlan_id": 253 } }, { "count": 21, "data": { "ix_id": 319, "name": "SIX SI", "ixlan_id": 319 } }, { "count": 21, "data": { "ix_id": 350, "name": "MSK-IX Ekaterinburg", "ixlan_id": 350 } }, { "count": 21, "data": { "ix_id": 691, "name": "IX Australia SA: SA-IX", "ixlan_id": 691 } }, { "count": 21, "data": { "ix_id": 809, "name": "OmahaIX", "ixlan_id": 809 } }, { "count": 21, "data": { "ix_id": 1175, "name": "MegaIX Los Angeles", "ixlan_id": 1175 } }, { "count": 21, "data": { "ix_id": 1387, "name": "DataLine-IX", "ixlan_id": 1292 } }, { "count": 21, "data": { "ix_id": 526, "name": "LIXP: public peering vlan", "ixlan_id": 1422 } }, { "count": 20, "data": { "ix_id": 204, "name": "CoreSite - Any2 NorthEast", "ixlan_id": 204 } }, { "count": 20, "data": { "ix_id": 328, "name": "TREX: Unicast Peering", "ixlan_id": 328 } }, { "count": 20, "data": { "ix_id": 694, "name": "GIXA: Peering LAN", "ixlan_id": 694 } }, { "count": 20, "data": { "ix_id": 1067, "name": "CABASE-COR - IX Argentina (Cordoba): COR", "ixlan_id": 1067 } }, { "count": 20, "data": { "ix_id": 1923, "name": "Equinix Stockholm: Equinix IX - SK Metro", "ixlan_id": 1452 } }, { "count": 19, "data": { "ix_id": 373, "name": "Equinix Toronto", "ixlan_id": 373 } }, { "count": 19, "data": { "ix_id": 542, "name": "Litix: Litix", "ixlan_id": 1471 } }, { "count": 18, "data": { "ix_id": 195, "name": "PIX Vancouver", "ixlan_id": 195 } }, { "count": 18, "data": { "ix_id": 241, "name": "npIX PTS", "ixlan_id": 241 } }, { "count": 18, "data": { "ix_id": 673, "name": "CyrusOne IX Houston", "ixlan_id": 673 } }, { "count": 18, "data": { "ix_id": 829, "name": "SLIX - Salt Lake City Internet Exchange", "ixlan_id": 829 } }, { "count": 18, "data": { "ix_id": 1209, "name": "CNX: Internet Peering", "ixlan_id": 1209 } }, { "count": 18, "data": { "ix_id": 1212, "name": "MGMix Montgomery", "ixlan_id": 1212 } }, { "count": 18, "data": { "ix_id": 1332, "name": "FICIX 1 (Espoo): IPv4+IPv6 MTU 1500", "ixlan_id": 1294 } }, { "count": 18, "data": { "ix_id": 2210, "name": "ANI-IX Delhi", "ixlan_id": 1543 } }, { "count": 17, "data": { "ix_id": 110, "name": "PIPE Networks Brisbane", "ixlan_id": 110 } }, { "count": 17, "data": { "ix_id": 212, "name": "BW-IX Stuttgart / S-IX: PeeringLAN", "ixlan_id": 212 } }, { "count": 17, "data": { "ix_id": 512, "name": "PIRIX", "ixlan_id": 512 } }, { "count": 17, "data": { "ix_id": 707, "name": "IX.br (PTT.br) Manaus: ATM/MPLA", "ixlan_id": 707 } }, { "count": 17, "data": { "ix_id": 790, "name": "IX.br (PTT.br) Lajeado: ATM/MLPA", "ixlan_id": 790 } }, { "count": 17, "data": { "ix_id": 1089, "name": "T-CIX", "ixlan_id": 1089 } }, { "count": 17, "data": { "ix_id": 1073, "name": "SAIX: Public Peering LAN", "ixlan_id": 1304 } }, { "count": 17, "data": { "ix_id": 1829, "name": "YXEIX: YXEIX", "ixlan_id": 1428 } }, { "count": 17, "data": { "ix_id": 1869, "name": "STHIX - Copenhagen: CPH Peering", "ixlan_id": 1447 } }, { "count": 17, "data": { "ix_id": 2452, "name": "UNM-Exch Canada-West: Main", "ixlan_id": 1730 } }, { "count": 16, "data": { "ix_id": 235, "name": "NIXI Chennai", "ixlan_id": 235 } }, { "count": 16, "data": { "ix_id": 267, "name": "DRF IX", "ixlan_id": 267 } }, { "count": 16, "data": { "ix_id": 575, "name": "IX.br (PTT.br) Goi?nia: ATM/MPLA", "ixlan_id": 575 } }, { "count": 16, "data": { "ix_id": 709, "name": "IX.br (PTT.br) S?o Jos? do Rio Preto: ATM/MPLA", "ixlan_id": 709 } }, { "count": 16, "data": { "ix_id": 1868, "name": "STHIX - Gothenburg: GBG Peering", "ixlan_id": 1442 } }, { "count": 16, "data": { "ix_id": 1927, "name": "Equinix Manchester: Equinix IX - MA Metro", "ixlan_id": 1453 } }, { "count": 16, "data": { "ix_id": 1816, "name": "A.IX", "ixlan_id": 1507 } }, { "count": 16, "data": { "ix_id": 2516, "name": "BDIX: Main", "ixlan_id": 1804 } }, { "count": 15, "data": { "ix_id": 88, "name": "iAIX", "ixlan_id": 88 } }, { "count": 15, "data": { "ix_id": 223, "name": "MSK-IX Novosibirsk", "ixlan_id": 223 } }, { "count": 15, "data": { "ix_id": 422, "name": "UIXP", "ixlan_id": 422 } }, { "count": 15, "data": { "ix_id": 708, "name": "IX.br (PTT.br) Natal: ATM/MPLA", "ixlan_id": 708 } }, { "count": 15, "data": { "ix_id": 851, "name": "ArmIX: Peering", "ixlan_id": 851 } }, { "count": 15, "data": { "ix_id": 945, "name": "CABASE-ROS - IX Argentina (Rosario): ROS", "ixlan_id": 945 } }, { "count": 15, "data": { "ix_id": 1180, "name": "MegaIX Dallas", "ixlan_id": 1180 } }, { "count": 15, "data": { "ix_id": 1519, "name": "MidWest-IX - St. Louis: Main", "ixlan_id": 1383 } }, { "count": 15, "data": { "ix_id": 1925, "name": "Equinix Milan: Equinix IX - ML Metro", "ixlan_id": 1454 } }, { "count": 15, "data": { "ix_id": 1984, "name": "RomandIX: Romandix Lan", "ixlan_id": 1462 } }, { "count": 15, "data": { "ix_id": 2062, "name": "Bharat IX - Mumbai: Bharat IX Peering LAN", "ixlan_id": 1489 } }, { "count": 15, "data": { "ix_id": 2078, "name": "IX.br (PTT.br) Teresina: ATM/MPLA", "ixlan_id": 1499 } }, { "count": 15, "data": { "ix_id": 2088, "name": "PhillyIX", "ixlan_id": 1516 } }, { "count": 15, "data": { "ix_id": 2245, "name": "NIXA: Peering LAN", "ixlan_id": 1555 } }, { "count": 14, "data": { "ix_id": 89, "name": "MadIX", "ixlan_id": 89 } }, { "count": 14, "data": { "ix_id": 198, "name": "NIXI Delhi", "ixlan_id": 198 } }, { "count": 14, "data": { "ix_id": 273, "name": "TIX", "ixlan_id": 273 } }, { "count": 14, "data": { "ix_id": 298, "name": "NIX2", "ixlan_id": 298 } }, { "count": 14, "data": { "ix_id": 383, "name": "LIX-LV", "ixlan_id": 383 } }, { "count": 14, "data": { "ix_id": 881, "name": "Lillix", "ixlan_id": 881 } }, { "count": 14, "data": { "ix_id": 906, "name": "HFXIX", "ixlan_id": 906 } }, { "count": 14, "data": { "ix_id": 1516, "name": "IX.LODZ.PL: LAN 1", "ixlan_id": 1351 } }, { "count": 14, "data": { "ix_id": 1522, "name": "IXpy: ISPs", "ixlan_id": 1353 } }, { "count": 14, "data": { "ix_id": 1561, "name": "PhOpenIX-Manila", "ixlan_id": 1537 } }, { "count": 13, "data": { "ix_id": 421, "name": "Angola-IXP / ANG-IX", "ixlan_id": 421 } }, { "count": 13, "data": { "ix_id": 776, "name": "WPGIX", "ixlan_id": 776 } }, { "count": 13, "data": { "ix_id": 866, "name": "SH-IX", "ixlan_id": 866 } }, { "count": 13, "data": { "ix_id": 938, "name": "TahoeIX: Peering", "ixlan_id": 938 } }, { "count": 13, "data": { "ix_id": 967, "name": "DjIX", "ixlan_id": 967 } }, { "count": 13, "data": { "ix_id": 1056, "name": "MegaIX Sofia: MegaIX", "ixlan_id": 1056 } }, { "count": 13, "data": { "ix_id": 1926, "name": "Equinix Dublin: Equinix IX - DB Metro", "ixlan_id": 1459 } }, { "count": 13, "data": { "ix_id": 1978, "name": "CLOUD-IX SPB", "ixlan_id": 1501 } }, { "count": 13, "data": { "ix_id": 876, "name": "RED-IX", "ixlan_id": 1511 } }, { "count": 13, "data": { "ix_id": 2131, "name": "Equinix Lisbon: Equinix IX - LS Metro", "ixlan_id": 1524 } }, { "count": 13, "data": { "ix_id": 2454, "name": "CSL Thai-IX Malaysia: THAI-IX", "ixlan_id": 1733 } }, { "count": 13, "data": { "ix_id": 363, "name": "SUPRnet: SUPRnet", "ixlan_id": 1888 } }, { "count": 12, "data": { "ix_id": 190, "name": "TLLIX", "ixlan_id": 190 } }, { "count": 12, "data": { "ix_id": 192, "name": "Netnod Gothenburg: MTU1500", "ixlan_id": 192 } }, { "count": 12, "data": { "ix_id": 226, "name": "CoreSite - Any2 Chicago", "ixlan_id": 226 } }, { "count": 12, "data": { "ix_id": 366, "name": "AMS-IX Caribbean", "ixlan_id": 366 } }, { "count": 12, "data": { "ix_id": 543, "name": "Rheintal IX", "ixlan_id": 543 } }, { "count": 12, "data": { "ix_id": 563, "name": "JXIX", "ixlan_id": 563 } }, { "count": 12, "data": { "ix_id": 828, "name": "RZ-IX", "ixlan_id": 828 } }, { "count": 12, "data": { "ix_id": 859, "name": "IX.br (PTT.br) Cuiab?: ATM/MPLA", "ixlan_id": 859 } }, { "count": 12, "data": { "ix_id": 869, "name": "OhioIX: Ohio IX Public Peering LAN", "ixlan_id": 869 } }, { "count": 12, "data": { "ix_id": 904, "name": "CABASE-LPL - IX Argentina (La Plata): LPL", "ixlan_id": 904 } }, { "count": 12, "data": { "ix_id": 1070, "name": "CABASE-MZA - IX Argentina (Mendoza): MZA", "ixlan_id": 1070 } }, { "count": 12, "data": { "ix_id": 1131, "name": "DE-CIX Palermo: DE-CIX Palermo Peering LAN", "ixlan_id": 1131 } }, { "count": 12, "data": { "ix_id": 1276, "name": "IX.br (PTT.br) Foz do Igua?u: ATM/MLPA", "ixlan_id": 1255 } }, { "count": 12, "data": { "ix_id": 1023, "name": "CRIX: Peering LAN", "ixlan_id": 1341 } }, { "count": 12, "data": { "ix_id": 1464, "name": "Equinix Helsinki: Equinix IX - HE Metro", "ixlan_id": 1360 } }, { "count": 12, "data": { "ix_id": 1794, "name": "IX Palmas: Peering Network", "ixlan_id": 1425 } }, { "count": 12, "data": { "ix_id": 1983, "name": "IX.br (PTT.br) Jo?o Pessoa: ATM/MLPA", "ixlan_id": 1461 } }, { "count": 12, "data": { "ix_id": 2086, "name": "IX.br (PTT.br) S?o Lu?s: ATM/MPLA", "ixlan_id": 1510 } }, { "count": 12, "data": { "ix_id": 2102, "name": "MMIX: MMIX YGN Peering LAN", "ixlan_id": 1545 } }, { "count": 12, "data": { "ix_id": 2495, "name": "CSL Thai-IX Bangkok: Main", "ixlan_id": 1784 } }, { "count": 12, "data": { "ix_id": 2531, "name": "DE-CIX Lisbon: DE-CIX Lisbon Peering LAN", "ixlan_id": 1820 } }, { "count": 11, "data": { "ix_id": 96, "name": "WIX", "ixlan_id": 96 } }, { "count": 11, "data": { "ix_id": 111, "name": "PIPE Networks Melbourne", "ixlan_id": 111 } }, { "count": 11, "data": { "ix_id": 231, "name": "MalmIX Malmo / IXOR", "ixlan_id": 231 } }, { "count": 11, "data": { "ix_id": 499, "name": "MKE-IX", "ixlan_id": 499 } }, { "count": 11, "data": { "ix_id": 638, "name": "IX.br (PTT.br) S?o Jos? dos Campos: ATM/MPLA", "ixlan_id": 638 } }, { "count": 11, "data": { "ix_id": 778, "name": "CIX KR", "ixlan_id": 778 } }, { "count": 11, "data": { "ix_id": 911, "name": "CABASE-POS - IX Argentina (Posadas): POS", "ixlan_id": 911 } }, { "count": 11, "data": { "ix_id": 1007, "name": "angonix", "ixlan_id": 1007 } }, { "count": 11, "data": { "ix_id": 1171, "name": "KIVIX: Main", "ixlan_id": 1171 } }, { "count": 11, "data": { "ix_id": 1262, "name": "INEX Cork: Peering LAN", "ixlan_id": 1249 } }, { "count": 11, "data": { "ix_id": 1932, "name": "YJSNPIX: CAN-LAN-01", "ixlan_id": 1458 } }, { "count": 11, "data": { "ix_id": 2494, "name": "CSL Thai-IX Singapore: Main", "ixlan_id": 1783 } }, { "count": 11, "data": { "ix_id": 2522, "name": "Sejong Neutral-IX", "ixlan_id": 1811 } }, { "count": 10, "data": { "ix_id": 194, "name": "Netnod Sundsvall: MTU1500", "ixlan_id": 194 } }, { "count": 10, "data": { "ix_id": 221, "name": "OttIX", "ixlan_id": 221 } }, { "count": 10, "data": { "ix_id": 377, "name": "AAIX", "ixlan_id": 377 } }, { "count": 10, "data": { "ix_id": 380, "name": "MSK-IX Rostov-on-Don", "ixlan_id": 380 } }, { "count": 10, "data": { "ix_id": 864, "name": "BR-IX: PEER", "ixlan_id": 864 } }, { "count": 10, "data": { "ix_id": 930, "name": "CABASE-NQN - IX Argentina (Neuquen): NQN", "ixlan_id": 930 } }, { "count": 10, "data": { "ix_id": 940, "name": "TTIX", "ixlan_id": 940 } }, { "count": 10, "data": { "ix_id": 1002, "name": "RVA-IX", "ixlan_id": 1002 } }, { "count": 10, "data": { "ix_id": 1016, "name": "LINX Cardiff: LINX Cardiff", "ixlan_id": 1016 } }, { "count": 10, "data": { "ix_id": 1019, "name": "AuvernIX: AuvernIX LAN", "ixlan_id": 1019 } }, { "count": 10, "data": { "ix_id": 1032, "name": "RINEX", "ixlan_id": 1032 } }, { "count": 10, "data": { "ix_id": 1066, "name": "CABASE-BHB - IX Argentina (Bahia Blanca): BHB", "ixlan_id": 1066 } }, { "count": 10, "data": { "ix_id": 1174, "name": "MegaIX Seattle: MegaIX", "ixlan_id": 1174 } }, { "count": 10, "data": { "ix_id": 252, "name": "NAP Colombia: Main", "ixlan_id": 1316 } }, { "count": 10, "data": { "ix_id": 1485, "name": "CABASE-SZP - IX Argentina (Saenz Pe?a): SZP", "ixlan_id": 1333 } }, { "count": 10, "data": { "ix_id": 1790, "name": "GREX", "ixlan_id": 1423 } }, { "count": 10, "data": { "ix_id": 72, "name": "GigaPIX: LAN2", "ixlan_id": 1438 } }, { "count": 10, "data": { "ix_id": 2291, "name": "IX.br (PTT.br) Macei?: ATM/MPLA", "ixlan_id": 1557 } }, { "count": 10, "data": { "ix_id": 2299, "name": "SAIX Saudi Arabia", "ixlan_id": 1563 } }, { "count": 10, "data": { "ix_id": 225, "name": "TH-IX", "ixlan_id": 1578 } }, { "count": 10, "data": { "ix_id": 2386, "name": "GR-IX::Thessaloniki: Peering LAN", "ixlan_id": 1652 } }, { "count": 10, "data": { "ix_id": 2476, "name": "JKT-IX: Main", "ixlan_id": 1762 } }, { "count": 9, "data": { "ix_id": 40, "name": "PARIX", "ixlan_id": 40 } }, { "count": 9, "data": { "ix_id": 336, "name": "TOUIX", "ixlan_id": 336 } }, { "count": 9, "data": { "ix_id": 392, "name": "MD-IX", "ixlan_id": 392 } }, { "count": 9, "data": { "ix_id": 393, "name": "IIX Israel", "ixlan_id": 393 } }, { "count": 9, "data": { "ix_id": 633, "name": "Sea-IX", "ixlan_id": 633 } }, { "count": 9, "data": { "ix_id": 1508, "name": "MIXP: Peering", "ixlan_id": 1344 } }, { "count": 9, "data": { "ix_id": 1663, "name": "RIX (RYUKYUIX): RYUKYUIX-001", "ixlan_id": 1385 } }, { "count": 9, "data": { "ix_id": 1764, "name": "CABASE-JUJ - IX Argentina (Jujuy): JUJ", "ixlan_id": 1413 } }, { "count": 9, "data": { "ix_id": 1776, "name": "GABIX: peering", "ixlan_id": 1418 } }, { "count": 9, "data": { "ix_id": 1999, "name": "PIT-IX: Peering-1500", "ixlan_id": 1465 } }, { "count": 9, "data": { "ix_id": 2145, "name": "KG-IX Bishkek: peering network", "ixlan_id": 1528 } }, { "count": 9, "data": { "ix_id": 2149, "name": "PITER-IX: TLL_PEERING VLAN", "ixlan_id": 1532 } }, { "count": 9, "data": { "ix_id": 1991, "name": "PIT Arica - PIT Chile: LAN", "ixlan_id": 1546 } }, { "count": 9, "data": { "ix_id": 2332, "name": "PNG Neutral Internet Exchange: Main", "ixlan_id": 1594 } }, { "count": 9, "data": { "ix_id": 2345, "name": "GetaFIX: Main", "ixlan_id": 1607 } }, { "count": 9, "data": { "ix_id": 1154, "name": "SFO-IX: SFO-IX", "ixlan_id": 1622 } }, { "count": 9, "data": { "ix_id": 2601, "name": "NLocIX: Peering LAN", "ixlan_id": 1898 } }, { "count": 8, "data": { "ix_id": 170, "name": "OCIX Duesseldorf", "ixlan_id": 170 } }, { "count": 8, "data": { "ix_id": 256, "name": "Digital Realty Phoenix", "ixlan_id": 256 } }, { "count": 8, "data": { "ix_id": 529, "name": "KRS-IX", "ixlan_id": 529 } }, { "count": 8, "data": { "ix_id": 593, "name": "Equinix Miami", "ixlan_id": 593 } }, { "count": 8, "data": { "ix_id": 626, "name": "IIX JI", "ixlan_id": 626 } }, { "count": 8, "data": { "ix_id": 822, "name": "Sibir-IX", "ixlan_id": 822 } }, { "count": 8, "data": { "ix_id": 2066, "name": "IXP.MX - Mexico City: Primary", "ixlan_id": 896 } }, { "count": 8, "data": { "ix_id": 1009, "name": "Tirol-IX", "ixlan_id": 1009 } }, { "count": 8, "data": { "ix_id": 1172, "name": "CHN-IX Beijing", "ixlan_id": 1172 } }, { "count": 8, "data": { "ix_id": 1484, "name": "CABASE-NGB - IX Argentina (Pilar): NGB", "ixlan_id": 1331 } }, { "count": 8, "data": { "ix_id": 1042, "name": "NAP.EC - GYE", "ixlan_id": 1356 } }, { "count": 8, "data": { "ix_id": 1658, "name": "npIX JWL", "ixlan_id": 1373 } }, { "count": 8, "data": { "ix_id": 1670, "name": "BreizhIX: BREIZHIX-PEERING-LAN", "ixlan_id": 1388 } }, { "count": 8, "data": { "ix_id": 1785, "name": "Extreme IX Hyderabad: Extreme IX LAN", "ixlan_id": 1420 } }, { "count": 8, "data": { "ix_id": 1915, "name": "PIT Concepcion - PIT Chile: LAN", "ixlan_id": 1449 } }, { "count": 8, "data": { "ix_id": 2013, "name": "Community-IX.ch: Peering", "ixlan_id": 1473 } }, { "count": 8, "data": { "ix_id": 2094, "name": "HVIX", "ixlan_id": 1512 } }, { "count": 8, "data": { "ix_id": 2289, "name": "Equinix Bogota: Equinix IX - BG Metro", "ixlan_id": 1556 } }, { "count": 8, "data": { "ix_id": 2312, "name": "TR-IX: TR-IX", "ixlan_id": 1568 } }, { "count": 8, "data": { "ix_id": 2250, "name": "KAZ-GOV-IX: 195.12.116.0/23", "ixlan_id": 1681 } }, { "count": 8, "data": { "ix_id": 2469, "name": "MoeIX Osaka: Main", "ixlan_id": 1751 } }, { "count": 8, "data": { "ix_id": 2552, "name": "BDIXP: Peering LAN", "ixlan_id": 1850 } }, { "count": 8, "data": { "ix_id": 2585, "name": "STLIX: Main", "ixlan_id": 1881 } }, { "count": 7, "data": { "ix_id": 287, "name": "Crimea-IX", "ixlan_id": 287 } }, { "count": 7, "data": { "ix_id": 322, "name": "Digital Realty Dallas", "ixlan_id": 322 } }, { "count": 7, "data": { "ix_id": 334, "name": "KAZ-IX", "ixlan_id": 334 } }, { "count": 7, "data": { "ix_id": 340, "name": "ULN-IX", "ixlan_id": 340 } }, { "count": 7, "data": { "ix_id": 410, "name": "FR-IX", "ixlan_id": 410 } }, { "count": 7, "data": { "ix_id": 452, "name": "BIX Jakarta", "ixlan_id": 452 } }, { "count": 7, "data": { "ix_id": 558, "name": "IX.br (PTT.br) Caxias do Sul: ATM/MPLA", "ixlan_id": 558 } }, { "count": 7, "data": { "ix_id": 607, "name": "MIX MNDC", "ixlan_id": 607 } }, { "count": 7, "data": { "ix_id": 796, "name": "BREM-IX", "ixlan_id": 796 } }, { "count": 7, "data": { "ix_id": 1160, "name": "NIXVAL-ix: Peering LAN1", "ixlan_id": 1160 } }, { "count": 7, "data": { "ix_id": 1169, "name": "YEGIX", "ixlan_id": 1169 } }, { "count": 7, "data": { "ix_id": 1307, "name": "MegaIX Toronto: MegaIX", "ixlan_id": 1260 } }, { "count": 7, "data": { "ix_id": 98, "name": "FICIX 2 (Helsinki): IPv6 MTU 9000", "ixlan_id": 1297 } }, { "count": 7, "data": { "ix_id": 1487, "name": "CABASE-BRC - IX Argentina (Bariloche): BRC", "ixlan_id": 1329 } }, { "count": 7, "data": { "ix_id": 1482, "name": "CABASE-PER - IX Argentina (Pergamino): PER", "ixlan_id": 1332 } }, { "count": 7, "data": { "ix_id": 1541, "name": "KIXP - Mombasa: Peering LAN", "ixlan_id": 1365 } }, { "count": 7, "data": { "ix_id": 1634, "name": "SCL-IX Chile: Main", "ixlan_id": 1371 } }, { "count": 7, "data": { "ix_id": 810, "name": "CIVIX", "ixlan_id": 1443 } }, { "count": 7, "data": { "ix_id": 2253, "name": "ix.kw", "ixlan_id": 1551 } }, { "count": 7, "data": { "ix_id": 2381, "name": "WAF-IX, Lagos: Main", "ixlan_id": 1644 } }, { "count": 7, "data": { "ix_id": 2443, "name": "MoeIX San Francisco: Main", "ixlan_id": 1723 } }, { "count": 7, "data": { "ix_id": 2195, "name": "AMR-IX: AMR-IX Peering LAN", "ixlan_id": 1738 } }, { "count": 7, "data": { "ix_id": 2501, "name": "LNK-IX: Peering VLAN", "ixlan_id": 1790 } }, { "count": 7, "data": { "ix_id": 2511, "name": "MS-IX: MS-IX Peering LAN", "ixlan_id": 1810 } }, { "count": 6, "data": { "ix_id": 112, "name": "PIPE Networks Adelaide", "ixlan_id": 112 } }, { "count": 6, "data": { "ix_id": 379, "name": "MSK-IX Samara", "ixlan_id": 379 } }, { "count": 6, "data": { "ix_id": 381, "name": "REUNIX", "ixlan_id": 381 } }, { "count": 6, "data": { "ix_id": 528, "name": "MOZIX", "ixlan_id": 528 } }, { "count": 6, "data": { "ix_id": 573, "name": "HIX Haiti", "ixlan_id": 573 } }, { "count": 6, "data": { "ix_id": 1013, "name": "NOVO NIX", "ixlan_id": 1013 } }, { "count": 6, "data": { "ix_id": 1017, "name": "BENIN-IX", "ixlan_id": 1017 } }, { "count": 6, "data": { "ix_id": 1038, "name": "NashIX", "ixlan_id": 1038 } }, { "count": 6, "data": { "ix_id": 1068, "name": "CABASE-DLC - IX Argentina (Santa Teresita): DLC", "ixlan_id": 1068 } }, { "count": 6, "data": { "ix_id": 1069, "name": "CABASE-MDQ - IX Argentina (Mar del Plata): MDQ", "ixlan_id": 1069 } }, { "count": 6, "data": { "ix_id": 1151, "name": "CentralIX", "ixlan_id": 1151 } }, { "count": 6, "data": { "ix_id": 1335, "name": "MGIX: Peering", "ixlan_id": 1274 } }, { "count": 6, "data": { "ix_id": 1054, "name": "TransIX Network", "ixlan_id": 1327 } }, { "count": 6, "data": { "ix_id": 1489, "name": "Aloha-IX: MTU1500", "ixlan_id": 1337 } }, { "count": 6, "data": { "ix_id": 1917, "name": "PIT Temuco - PIT Chile: LAN", "ixlan_id": 1451 } }, { "count": 6, "data": { "ix_id": 2032, "name": "Sacramento-IX: ProductionVLAN", "ixlan_id": 1477 } }, { "count": 6, "data": { "ix_id": 2036, "name": "MEX-IX: McAllen Peering LAN", "ixlan_id": 1481 } }, { "count": 6, "data": { "ix_id": 71, "name": "NIX.CZ: FENIX VLAN", "ixlan_id": 1488 } }, { "count": 6, "data": { "ix_id": 2130, "name": "Equinix Madrid: Equinix IX - MD Metro", "ixlan_id": 1523 } }, { "count": 6, "data": { "ix_id": 2176, "name": "PIT entel", "ixlan_id": 1538 } }, { "count": 6, "data": { "ix_id": 2355, "name": "btIX: TTPL-LAN", "ixlan_id": 1618 } }, { "count": 6, "data": { "ix_id": 2341, "name": "REDIX Chennai: Peering LAN", "ixlan_id": 1631 } }, { "count": 6, "data": { "ix_id": 2343, "name": "LL-IX: Bucharest, RO", "ixlan_id": 1674 } }, { "count": 6, "data": { "ix_id": 2553, "name": "LVIV-IX: Main", "ixlan_id": 1846 } }, { "count": 6, "data": { "ix_id": 2571, "name": "SBIX: Switzerland", "ixlan_id": 1867 } }, { "count": 5, "data": { "ix_id": 10, "name": "Equinix Vienna (VA)", "ixlan_id": 10 } }, { "count": 5, "data": { "ix_id": 44, "name": "Manila IX", "ixlan_id": 44 } }, { "count": 5, "data": { "ix_id": 154, "name": "BAYANTEL", "ixlan_id": 154 } }, { "count": 5, "data": { "ix_id": 197, "name": "PIX Toronto", "ixlan_id": 197 } }, { "count": 5, "data": { "ix_id": 260, "name": "OCIX", "ixlan_id": 260 } }, { "count": 5, "data": { "ix_id": 288, "name": "ACTIX", "ixlan_id": 288 } }, { "count": 5, "data": { "ix_id": 332, "name": "CoreSite - Any2 New York", "ixlan_id": 332 } }, { "count": 5, "data": { "ix_id": 349, "name": "CHIX-NZ", "ixlan_id": 349 } }, { "count": 5, "data": { "ix_id": 378, "name": "MSK-IX Vladivostok", "ixlan_id": 378 } }, { "count": 5, "data": { "ix_id": 400, "name": "LIPTAM", "ixlan_id": 400 } }, { "count": 5, "data": { "ix_id": 492, "name": "FICIX 3 (Oulu): IPv4+IPv6 MTU 1500", "ixlan_id": 492 } }, { "count": 5, "data": { "ix_id": 672, "name": "CyrusOne IX Dallas", "ixlan_id": 672 } }, { "count": 5, "data": { "ix_id": 762, "name": "DO-IX", "ixlan_id": 762 } }, { "count": 5, "data": { "ix_id": 922, "name": "IXP Namibia", "ixlan_id": 922 } }, { "count": 5, "data": { "ix_id": 957, "name": "MiamiIX", "ixlan_id": 957 } }, { "count": 5, "data": { "ix_id": 1046, "name": "CGIX", "ixlan_id": 1046 } }, { "count": 5, "data": { "ix_id": 1168, "name": "Kherson Traffic Exchange", "ixlan_id": 1168 } }, { "count": 5, "data": { "ix_id": 1187, "name": "SYMC-IX Bangkok: SYMC-IX LAN1", "ixlan_id": 1187 } }, { "count": 5, "data": { "ix_id": 1201, "name": "AIXP: Peering", "ixlan_id": 1201 } }, { "count": 5, "data": { "ix_id": 1421, "name": "BW-IX Karlsruhe: PeeringLAN", "ixlan_id": 1306 } }, { "count": 5, "data": { "ix_id": 192, "name": "Netnod Gothenburg: MTU4470", "ixlan_id": 1313 } }, { "count": 5, "data": { "ix_id": 1468, "name": "Asia Smart IX [BBIX Asia]", "ixlan_id": 1324 } }, { "count": 5, "data": { "ix_id": 1490, "name": "Richmond-IX: MTU-1500", "ixlan_id": 1343 } }, { "count": 5, "data": { "ix_id": 1577, "name": "IIFON IX Kolkata: Main", "ixlan_id": 1359 } }, { "count": 5, "data": { "ix_id": 1317, "name": "NIXI Kolkata", "ixlan_id": 1397 } }, { "count": 5, "data": { "ix_id": 1847, "name": "IX.br (PTT.br) Santa Maria: ATM/MLPA", "ixlan_id": 1437 } }, { "count": 5, "data": { "ix_id": 2070, "name": "MonctonIX: MonctonIX", "ixlan_id": 1493 } }, { "count": 5, "data": { "ix_id": 1981, "name": "CLOUD-IX KIEV", "ixlan_id": 1504 } }, { "count": 5, "data": { "ix_id": 1982, "name": "CLOUD-IX EKT", "ixlan_id": 1505 } }, { "count": 5, "data": { "ix_id": 1679, "name": "NNENIX: NNENIX-IXP-LAN", "ixlan_id": 1526 } }, { "count": 5, "data": { "ix_id": 2167, "name": "Extreme IX Kolkata: Extreme IX LAN", "ixlan_id": 1534 } }, { "count": 5, "data": { "ix_id": 2343, "name": "LL-IX: Prague, CZ", "ixlan_id": 1605 } }, { "count": 5, "data": { "ix_id": 2362, "name": "KIXP - Mombasa icolo: Main", "ixlan_id": 1624 } }, { "count": 5, "data": { "ix_id": 2486, "name": "CMH-IX: Main", "ixlan_id": 1773 } }, { "count": 5, "data": { "ix_id": 2497, "name": "KazNIX", "ixlan_id": 1786 } }, { "count": 5, "data": { "ix_id": 2568, "name": "TN-IX: TN-IX", "ixlan_id": 1864 } }, { "count": 5, "data": { "ix_id": 2569, "name": "NL-ix 2", "ixlan_id": 1865 } }, { "count": 4, "data": { "ix_id": 41, "name": "NYCX", "ixlan_id": 41 } }, { "count": 4, "data": { "ix_id": 148, "name": "EuroGIX", "ixlan_id": 148 } }, { "count": 4, "data": { "ix_id": 151, "name": "BigApe", "ixlan_id": 151 } }, { "count": 4, "data": { "ix_id": 274, "name": "CAIX", "ixlan_id": 274 } }, { "count": 4, "data": { "ix_id": 398, "name": "MSK-IX Kazan", "ixlan_id": 398 } }, { "count": 4, "data": { "ix_id": 428, "name": "NASA-AIX", "ixlan_id": 428 } }, { "count": 4, "data": { "ix_id": 496, "name": "BNIIX", "ixlan_id": 496 } }, { "count": 4, "data": { "ix_id": 506, "name": "GTIIX", "ixlan_id": 506 } }, { "count": 4, "data": { "ix_id": 727, "name": "MIX-BT", "ixlan_id": 727 } }, { "count": 4, "data": { "ix_id": 760, "name": "CyrusOne IX Phoenix", "ixlan_id": 760 } }, { "count": 4, "data": { "ix_id": 854, "name": "HTN-IX", "ixlan_id": 854 } }, { "count": 4, "data": { "ix_id": 971, "name": "VIX.VU", "ixlan_id": 971 } }, { "count": 4, "data": { "ix_id": 1071, "name": "CABASE-PMY - IX Argentina (Puerto Madryn): PMY", "ixlan_id": 1071 } }, { "count": 4, "data": { "ix_id": 1072, "name": "CABASE-SFE - IX Argentina (Santa Fe): SFE", "ixlan_id": 1072 } }, { "count": 4, "data": { "ix_id": 1105, "name": "TunIXP", "ixlan_id": 1105 } }, { "count": 4, "data": { "ix_id": 1123, "name": "IXP-HN", "ixlan_id": 1123 } }, { "count": 4, "data": { "ix_id": 1156, "name": "United Peering - UP-IXP", "ixlan_id": 1156 } }, { "count": 4, "data": { "ix_id": 1229, "name": "CODIX", "ixlan_id": 1229 } }, { "count": 4, "data": { "ix_id": 18, "name": "LINX LON1: Multicast", "ixlan_id": 1288 } }, { "count": 4, "data": { "ix_id": 1332, "name": "FICIX 1 (Espoo): IPv6 MTU 9000", "ixlan_id": 1295 } }, { "count": 4, "data": { "ix_id": 194, "name": "Netnod Sundsvall: MTU4470", "ixlan_id": 1315 } }, { "count": 4, "data": { "ix_id": 1480, "name": "CABASE-JUN - IX Argentina (Junin): JUN", "ixlan_id": 1330 } }, { "count": 4, "data": { "ix_id": 1488, "name": "Vegas-IX: MTU-1500", "ixlan_id": 1346 } }, { "count": 4, "data": { "ix_id": 1312, "name": "OuestIX: OUESTIX-NANTES", "ixlan_id": 1363 } }, { "count": 4, "data": { "ix_id": 1668, "name": "CIX-ATL", "ixlan_id": 1389 } }, { "count": 4, "data": { "ix_id": 1660, "name": "IXP Ecuador - STD", "ixlan_id": 1424 } }, { "count": 4, "data": { "ix_id": 1861, "name": "CN-IX-SH: CN-IX-SH", "ixlan_id": 1440 } }, { "count": 4, "data": { "ix_id": 2040, "name": "CABASE-RST - IX Argentina (Resistencia): RST", "ixlan_id": 1483 } }, { "count": 4, "data": { "ix_id": 2004, "name": "ANIX - Albanian Neutral Internet eXchange: Peering-VLan", "ixlan_id": 1495 } }, { "count": 4, "data": { "ix_id": 2093, "name": "CABASE-UAQ - IX Argentina (San Juan): UAQ", "ixlan_id": 1514 } }, { "count": 4, "data": { "ix_id": 2124, "name": "CFiX (Central Florida Internet Exchange)", "ixlan_id": 1522 } }, { "count": 4, "data": { "ix_id": 2318, "name": "Dallas-IX: Main", "ixlan_id": 1574 } }, { "count": 4, "data": { "ix_id": 2325, "name": "EMF-IX: Main", "ixlan_id": 1583 } }, { "count": 4, "data": { "ix_id": 2388, "name": "TGIX: Main", "ixlan_id": 1654 } }, { "count": 4, "data": { "ix_id": 2343, "name": "LL-IX: Frankfurt, DE", "ixlan_id": 1675 } }, { "count": 4, "data": { "ix_id": 2272, "name": "TTIX2: 131.72.77.240/28", "ixlan_id": 1718 } }, { "count": 4, "data": { "ix_id": 2467, "name": "BBIX Thailand: Main", "ixlan_id": 1749 } }, { "count": 4, "data": { "ix_id": 2286, "name": "MidWest-IX - Cleveland: 206.82.109.0/24", "ixlan_id": 1782 } }, { "count": 3, "data": { "ix_id": 76, "name": "GN-IX", "ixlan_id": 76 } }, { "count": 3, "data": { "ix_id": 127, "name": "Oregon Internet Exchange (OIX)", "ixlan_id": 127 } }, { "count": 3, "data": { "ix_id": 234, "name": "NSPIXP3", "ixlan_id": 234 } }, { "count": 3, "data": { "ix_id": 257, "name": "Netnod Lulea: 9K-BLUE", "ixlan_id": 257 } }, { "count": 3, "data": { "ix_id": 269, "name": "TransACT IX", "ixlan_id": 269 } }, { "count": 3, "data": { "ix_id": 275, "name": "BY-IX", "ixlan_id": 275 } }, { "count": 3, "data": { "ix_id": 281, "name": "MEIX", "ixlan_id": 281 } }, { "count": 3, "data": { "ix_id": 317, "name": "GIX", "ixlan_id": 317 } }, { "count": 3, "data": { "ix_id": 333, "name": "CoreSite - Any2 Boston", "ixlan_id": 333 } }, { "count": 3, "data": { "ix_id": 1420, "name": "TRDIX Trondheim", "ixlan_id": 342 } }, { "count": 3, "data": { "ix_id": 368, "name": "GigaPIX Oporto: LAN-PORTO", "ixlan_id": 368 } }, { "count": 3, "data": { "ix_id": 430, "name": "GraX", "ixlan_id": 430 } }, { "count": 3, "data": { "ix_id": 476, "name": "AZIX", "ixlan_id": 476 } }, { "count": 3, "data": { "ix_id": 487, "name": "CyIX", "ixlan_id": 487 } }, { "count": 3, "data": { "ix_id": 514, "name": "COIX", "ixlan_id": 514 } }, { "count": 3, "data": { "ix_id": 559, "name": "SIX.SK Ko?ice", "ixlan_id": 559 } }, { "count": 3, "data": { "ix_id": 580, "name": "MSK-IX Stavropol", "ixlan_id": 580 } }, { "count": 3, "data": { "ix_id": 582, "name": "BIX Bergen", "ixlan_id": 582 } }, { "count": 3, "data": { "ix_id": 598, "name": "NIXI Hyderabad", "ixlan_id": 598 } }, { "count": 3, "data": { "ix_id": 602, "name": "Echigo-IX", "ixlan_id": 602 } }, { "count": 3, "data": { "ix_id": 606, "name": "C2IX", "ixlan_id": 606 } }, { "count": 3, "data": { "ix_id": 635, "name": "OMSK-IX", "ixlan_id": 635 } }, { "count": 3, "data": { "ix_id": 674, "name": "CyrusOne IX Austin", "ixlan_id": 674 } }, { "count": 3, "data": { "ix_id": 766, "name": "DN-IX", "ixlan_id": 766 } }, { "count": 3, "data": { "ix_id": 916, "name": "CitranetIX", "ixlan_id": 916 } }, { "count": 3, "data": { "ix_id": 1095, "name": "IIX-RI", "ixlan_id": 1095 } }, { "count": 3, "data": { "ix_id": 1134, "name": "Guyanix", "ixlan_id": 1134 } }, { "count": 3, "data": { "ix_id": 1302, "name": "IX Liverpool: Titanic", "ixlan_id": 1263 } }, { "count": 3, "data": { "ix_id": 1302, "name": "IX Liverpool: Mersey", "ixlan_id": 1265 } }, { "count": 3, "data": { "ix_id": 1304, "name": "Doha-IX: QDC-1", "ixlan_id": 1269 } }, { "count": 3, "data": { "ix_id": 492, "name": "FICIX 3 (Oulu): IPv6 MTU 9000", "ixlan_id": 1299 } }, { "count": 3, "data": { "ix_id": 1486, "name": "CABASE-SLT - IX Argentina (Salta): SLT", "ixlan_id": 1336 } }, { "count": 3, "data": { "ix_id": 1533, "name": "inet2: vlan888", "ixlan_id": 1357 } }, { "count": 3, "data": { "ix_id": 1574, "name": "TIX Tanzania - Mwanza IXP: Peering", "ixlan_id": 1358 } }, { "count": 3, "data": { "ix_id": 1628, "name": "MegaIX Las Vegas: MegaIX", "ixlan_id": 1366 } }, { "count": 3, "data": { "ix_id": 655, "name": "GigaNET: Odessa local exchange", "ixlan_id": 1415 } }, { "count": 3, "data": { "ix_id": 655, "name": "GigaNET: Kharkov local exchange", "ixlan_id": 1416 } }, { "count": 3, "data": { "ix_id": 655, "name": "GigaNET: Moscow local exchange", "ixlan_id": 1417 } }, { "count": 3, "data": { "ix_id": 1863, "name": "CN-IX-GZ: CN-IX-GZ", "ixlan_id": 1441 } }, { "count": 3, "data": { "ix_id": 2039, "name": "CABASE-OGB - IX Argentina (Moreno): OGB", "ixlan_id": 1482 } }, { "count": 3, "data": { "ix_id": 2050, "name": "GPIEX: GPIEX", "ixlan_id": 1485 } }, { "count": 3, "data": { "ix_id": 2051, "name": "IF-IX: Ivano-frankivsk local exchange", "ixlan_id": 1486 } }, { "count": 3, "data": { "ix_id": 1980, "name": "CLOUD-IX KHA", "ixlan_id": 1503 } }, { "count": 3, "data": { "ix_id": 2182, "name": "Equinix Denver: Equinix IX - DE Metro", "ixlan_id": 1540 } }, { "count": 3, "data": { "ix_id": 2276, "name": "IXP.mk: Peering LAN", "ixlan_id": 1554 } }, { "count": 3, "data": { "ix_id": 2301, "name": "MARIIX: MARIIX", "ixlan_id": 1564 } }, { "count": 3, "data": { "ix_id": 2186, "name": "Baltimore IX: LAN", "ixlan_id": 1592 } }, { "count": 3, "data": { "ix_id": 2387, "name": "SJIX: Main", "ixlan_id": 1653 } }, { "count": 3, "data": { "ix_id": 2343, "name": "LL-IX: Kharkiv, UA", "ixlan_id": 1676 } }, { "count": 3, "data": { "ix_id": 1423, "name": "WRIX: WRIX", "ixlan_id": 1688 } }, { "count": 3, "data": { "ix_id": 2457, "name": "SR-IX: Main", "ixlan_id": 1736 } }, { "count": 3, "data": { "ix_id": 2537, "name": "STIX", "ixlan_id": 1833 } }, { "count": 3, "data": { "ix_id": 2563, "name": "JIX - Darwin: Darwin", "ixlan_id": 1858 } }, { "count": 3, "data": { "ix_id": 2564, "name": "iX-OKC: Main", "ixlan_id": 1859 } }, { "count": 3, "data": { "ix_id": 2566, "name": "MoeIX Zhengzhou: Main", "ixlan_id": 1862 } }, { "count": 3, "data": { "ix_id": 2567, "name": "MoeIX Hong Kong: Main", "ixlan_id": 1863 } }, { "count": 2, "data": { "ix_id": 81, "name": "SD-NAP", "ixlan_id": 81 } }, { "count": 2, "data": { "ix_id": 187, "name": "TIX-LAN", "ixlan_id": 187 } }, { "count": 2, "data": { "ix_id": 189, "name": "HIX", "ixlan_id": 189 } }, { "count": 2, "data": { "ix_id": 258, "name": "Norrnod", "ixlan_id": 258 } }, { "count": 2, "data": { "ix_id": 262, "name": "SISPA", "ixlan_id": 262 } }, { "count": 2, "data": { "ix_id": 316, "name": "ExWest", "ixlan_id": 316 } }, { "count": 2, "data": { "ix_id": 477, "name": "CBIX", "ixlan_id": 477 } }, { "count": 2, "data": { "ix_id": 615, "name": "LuIXP", "ixlan_id": 615 } }, { "count": 2, "data": { "ix_id": 624, "name": "TP-IX", "ixlan_id": 624 } }, { "count": 2, "data": { "ix_id": 815, "name": "NNOV-IX", "ixlan_id": 815 } }, { "count": 2, "data": { "ix_id": 867, "name": "OCIX Frankfurt", "ixlan_id": 867 } }, { "count": 2, "data": { "ix_id": 983, "name": "UNY-IX", "ixlan_id": 983 } }, { "count": 2, "data": { "ix_id": 1028, "name": "Nap Peru", "ixlan_id": 1028 } }, { "count": 2, "data": { "ix_id": 1094, "name": "GE-CIX", "ixlan_id": 1094 } }, { "count": 2, "data": { "ix_id": 1127, "name": "MARTINIX", "ixlan_id": 1127 } }, { "count": 2, "data": { "ix_id": 1210, "name": "M-IX", "ixlan_id": 1210 } }, { "count": 2, "data": { "ix_id": 129, "name": "JINX: JINX Voice", "ixlan_id": 1245 } }, { "count": 2, "data": { "ix_id": 1483, "name": "CABASE-TUC - IX Argentina (Tucuman): TUC", "ixlan_id": 1334 } }, { "count": 2, "data": { "ix_id": 1481, "name": "CABASE-SLU - IX Argentina (San Luis): SLU", "ixlan_id": 1335 } }, { "count": 2, "data": { "ix_id": 1489, "name": "Aloha-IX: MTU9000", "ixlan_id": 1338 } }, { "count": 2, "data": { "ix_id": 311, "name": "VSIX: Secondary", "ixlan_id": 1342 } }, { "count": 2, "data": { "ix_id": 1302, "name": "IX Liverpool: Internet of Things LAN", "ixlan_id": 1354 } }, { "count": 2, "data": { "ix_id": 1418, "name": "TIX Troms?", "ixlan_id": 1399 } }, { "count": 2, "data": { "ix_id": 1419, "name": "SIX Stavanger", "ixlan_id": 1400 } }, { "count": 2, "data": { "ix_id": 1919, "name": "APLIX: Aplix L2", "ixlan_id": 1448 } }, { "count": 2, "data": { "ix_id": 1862, "name": "CN-IX-BJ: CN-IX-BJ", "ixlan_id": 1455 } }, { "count": 2, "data": { "ix_id": 1933, "name": "PCIX", "ixlan_id": 1456 } }, { "count": 2, "data": { "ix_id": 1958, "name": "MESH-IX: public-unicast", "ixlan_id": 1460 } }, { "count": 2, "data": { "ix_id": 1428, "name": "GrenoblIX: grenoblix-peering", "ixlan_id": 1472 } }, { "count": 2, "data": { "ix_id": 1582, "name": "MegaFon-IX: Main", "ixlan_id": 1491 } }, { "count": 2, "data": { "ix_id": 993, "name": "PIX Palestine", "ixlan_id": 1506 } }, { "count": 2, "data": { "ix_id": 1798, "name": "CABASE-TDL - IX Argentina (Tandil): TDL", "ixlan_id": 1517 } }, { "count": 2, "data": { "ix_id": 1302, "name": "IX Liverpool: GRX Peering Exchange (5G)", "ixlan_id": 1541 } }, { "count": 2, "data": { "ix_id": 2251, "name": "Remki Internet Exchange (RIX): Remki IX", "ixlan_id": 1549 } }, { "count": 2, "data": { "ix_id": 2320, "name": "SIXP Sudan: Main", "ixlan_id": 1576 } }, { "count": 2, "data": { "ix_id": 2365, "name": "CHIX-CH: Main", "ixlan_id": 1627 } }, { "count": 2, "data": { "ix_id": 2410, "name": "SoIXP", "ixlan_id": 1683 } }, { "count": 2, "data": { "ix_id": 1773, "name": "VNIX-DN", "ixlan_id": 1757 } }, { "count": 2, "data": { "ix_id": 1771, "name": "VNIX-HCM", "ixlan_id": 1758 } }, { "count": 2, "data": { "ix_id": 1772, "name": "VNIX-HN", "ixlan_id": 1759 } }, { "count": 2, "data": { "ix_id": 2541, "name": "CAMIX Douala: Main", "ixlan_id": 1834 } }, { "count": 1, "data": { "ix_id": 16, "name": "MAE West", "ixlan_id": 16 } }, { "count": 1, "data": { "ix_id": 32, "name": "SFIX", "ixlan_id": 32 } }, { "count": 1, "data": { "ix_id": 77, "name": "LIX", "ixlan_id": 77 } }, { "count": 1, "data": { "ix_id": 114, "name": "PIPE Networks Hobart", "ixlan_id": 114 } }, { "count": 1, "data": { "ix_id": 141, "name": "TampaIX", "ixlan_id": 141 } }, { "count": 1, "data": { "ix_id": 146, "name": "GIX Gothenburg", "ixlan_id": 146 } }, { "count": 1, "data": { "ix_id": 196, "name": "PIX Montreal", "ixlan_id": 196 } }, { "count": 1, "data": { "ix_id": 199, "name": "YRIX", "ixlan_id": 199 } }, { "count": 1, "data": { "ix_id": 205, "name": "CoreSite - Any2 Miami", "ixlan_id": 205 } }, { "count": 1, "data": { "ix_id": 463, "name": "GU-IX", "ixlan_id": 463 } }, { "count": 1, "data": { "ix_id": 524, "name": "CePIX.pl", "ixlan_id": 524 } }, { "count": 1, "data": { "ix_id": 566, "name": "PNIX", "ixlan_id": 566 } }, { "count": 1, "data": { "ix_id": 631, "name": "PacificIX", "ixlan_id": 631 } }, { "count": 1, "data": { "ix_id": 640, "name": "GCIIX", "ixlan_id": 640 } }, { "count": 1, "data": { "ix_id": 985, "name": "IX Brighton", "ixlan_id": 985 } }, { "count": 1, "data": { "ix_id": 1040, "name": "NormandIX", "ixlan_id": 1040 } }, { "count": 1, "data": { "ix_id": 1183, "name": "6NGIX", "ixlan_id": 1183 } }, { "count": 1, "data": { "ix_id": 1191, "name": "SerinIX IX", "ixlan_id": 1191 } }, { "count": 1, "data": { "ix_id": 1284, "name": "CHN-IX Guangzhou", "ixlan_id": 1256 } }, { "count": 1, "data": { "ix_id": 662, "name": "Phoenix IX: Jumbo", "ixlan_id": 1303 } }, { "count": 1, "data": { "ix_id": 1469, "name": "UNIFI-IX: Main Lan", "ixlan_id": 1323 } }, { "count": 1, "data": { "ix_id": 1488, "name": "Vegas-IX: MTU-9000", "ixlan_id": 1347 } }, { "count": 1, "data": { "ix_id": 1490, "name": "Richmond-IX: MTU-9000", "ixlan_id": 1348 } }, { "count": 1, "data": { "ix_id": 1669, "name": "BAIKAL-IX: Peering LAN", "ixlan_id": 1387 } }, { "count": 1, "data": { "ix_id": 1754, "name": "Montenegro Internet eXchange Point: MIXP", "ixlan_id": 1414 } }, { "count": 1, "data": { "ix_id": 1833, "name": "IXP Ecuador - MEC", "ixlan_id": 1439 } }, { "count": 1, "data": { "ix_id": 1886, "name": "Cnean", "ixlan_id": 1446 } }, { "count": 1, "data": { "ix_id": 1916, "name": "PIT Osorno - PIT Chile: LAN", "ixlan_id": 1450 } }, { "count": 1, "data": { "ix_id": 655, "name": "GigaNET: Warsaw local exchange", "ixlan_id": 1484 } }, { "count": 1, "data": { "ix_id": 1870, "name": "IXPN Abuja", "ixlan_id": 1498 } }, { "count": 1, "data": { "ix_id": 2116, "name": "GOREX: GOREX", "ixlan_id": 1520 } }, { "count": 1, "data": { "ix_id": 2317, "name": "Charlotte-IX: Main", "ixlan_id": 1573 } }, { "count": 1, "data": { "ix_id": 2319, "name": "Houston-IX: Main", "ixlan_id": 1575 } }, { "count": 1, "data": { "ix_id": 2368, "name": "CABASE-VDM - IX Argentina (Viedma): Main", "ixlan_id": 1630 } }, { "count": 1, "data": { "ix_id": 2407, "name": "MISPA-IXP: Main", "ixlan_id": 1678 } }, { "count": 1, "data": { "ix_id": 2414, "name": "IXPN Kano: Main", "ixlan_id": 1689 } }, { "count": 1, "data": { "ix_id": 2286, "name": "MidWest-IX - Cleveland: Cleveland IX", "ixlan_id": 1781 } }, { "count": 1, "data": { "ix_id": 2496, "name": "BelgiumIX: Peeringlan", "ixlan_id": 1785 } }, { "count": 1, "data": { "ix_id": 2520, "name": "IXP-GUINEE: Main", "ixlan_id": 1808 } }, { "count": 1, "data": { "ix_id": 2527, "name": "Turk-IX: Main", "ixlan_id": 1816 } }, { "count": 1, "data": { "ix_id": 2558, "name": "NYIIX Philadelphia: Main", "ixlan_id": 1852 } }, { "count": 1, "data": { "ix_id": 2587, "name": "DE-CIX Delhi: Main", "ixlan_id": 1883 } } ] From gert at space.net Wed May 29 17:45:09 2019 From: gert at space.net (Gert Doering) Date: Wed, 29 May 2019 17:45:09 +0200 Subject: [address-policy-wg] 2019-05 New Policy Proposal (Revised IPv4 assignment policy for IXPs) In-Reply-To: <7608231559137379@iva8-b333b7f98ab0.qloud-c.yandex.net> References: <7608231559137379@iva8-b333b7f98ab0.qloud-c.yandex.net> Message-ID: <20190529154508.GR25123@Space.Net> Hi, On Wed, May 29, 2019 at 04:42:59PM +0300, Alexandr Popov wrote: > IXPs can use Private-Use Networks such as 10.0.0.0/8. > There is no technical need to spend a valuable resource for such purposes. IXPs say they need globally unique space, and they are the experts here. Could people *not* having experience in running an actual IXP please refrain from commenting on the technical aspects on "how an IXP should be run!"? Of course you're all free to agree or disagree with the proposal, but leave the actual IXP operations to those who do this as their daily job. Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- 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 Wed May 29 17:48:17 2019 From: gert at space.net (Gert Doering) Date: Wed, 29 May 2019 17:48:17 +0200 Subject: [address-policy-wg] 2019-05 New Policy Proposal (Revised IPv4 assignment policy for IXPs) In-Reply-To: <26224ebc-4822-4b65-944a-ff31d862519b@www.fastmail.com> References: <20190529131131.GQ53067@carcass.ledeuns.net> <26224ebc-4822-4b65-944a-ff31d862519b@www.fastmail.com> Message-ID: <20190529154817.GS25123@Space.Net> Hi, On Wed, May 29, 2019 at 04:13:15PM +0200, Radu-Adrian FEURDEAN wrote: > Those being said, I'm in favour of the proposal. Just one reserve > on wording of the assignment of "dust" (less than /24): if a request > (for smaller than /24) is being made before the reserved pool > exhaustion, will it be taken from he reserved pool or from the > "dust" ? Does this matter? Seriously: an IXP would only ever receive a "smaller than /24" assignment if they ask for it. And if they ask for it ("a /27 is sufficient enough, we're a small Island and there are only 10 ISPs here"), will it make a difference if they receive a dust-/27 or something from the IXP pool? (I could see arguments either way - so far the proposal is leaving it as an implementation detail to the NCC) Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From alexp at ma.spb.ru Wed May 29 18:05:18 2019 From: alexp at ma.spb.ru (Alexandr Popov) Date: Wed, 29 May 2019 19:05:18 +0300 Subject: [address-policy-wg] 2019-05 New Policy Proposal (Revised IPv4 assignment policy for IXPs) In-Reply-To: <4A68F6EE-9503-4078-A5BF-11E081822236@ams-ix.net> References: <7608231559137379@iva8-b333b7f98ab0.qloud-c.yandex.net> <20190529135816.GR53067@carcass.ledeuns.net> <7629971559139155@sas2-7b909973f402.qloud-c.yandex.net> <4A68F6EE-9503-4078-A5BF-11E081822236@ams-ix.net> Message-ID: <1627911559145918@sas2-a1efad875d04.qloud-c.yandex.net> An HTML attachment was scrubbed... URL: From nick at foobar.org Wed May 29 18:39:07 2019 From: nick at foobar.org (Nick Hilliard) Date: Wed, 29 May 2019 17:39:07 +0100 Subject: [address-policy-wg] 2019-05 New Policy Proposal (Revised IPv4 assignment policy for IXPs) In-Reply-To: <20190529154508.GR25123@Space.Net> References: <7608231559137379@iva8-b333b7f98ab0.qloud-c.yandex.net> <20190529154508.GR25123@Space.Net> Message-ID: Gert Doering wrote on 29/05/2019 16:45: > IXPs say they need globally unique space, and they are the experts here. From an architectural point of view, it's a good idea to use publicly registered numbering resources when interconnecting with third parties. IXPs are an extreme case of this because the same resource block is used to connect to multiple parties at the same time. One of the reasons this can cause problems is that the address block of the peering LAN often ends up redistributed in the IXP participant's routing tables. Lots of organisations redistribute rfc1997 address space internally in their own networks for their own purposes, so if this conflicts with the IXP peering LAN address block, the organisation is going to end up with connectivity problems. There are other reasons this can cause problems, but this is one of the more obvious ones. Nick From npediaditi at ripe.net Wed May 29 18:42:49 2019 From: npediaditi at ripe.net (Nikolas Pediaditis) Date: Wed, 29 May 2019 18:42:49 +0200 Subject: [address-policy-wg] 2019-05 New Policy Proposal (Revised IPv4 assignment policy for IXPs) In-Reply-To: References: <20190529131131.GQ53067@carcass.ledeuns.net> Message-ID: Dear Nick, all, On 29 May 2019, at 15:41, Nick Hilliard wrote: > Could the NCC provide any stats on how many /22s have been assigned under the IXP assignment policy? Since September 2012, when the current IXP assignment policy came into effect, the RIPE NCC has issued 1x /22 and 3x /23 assignments to IXPs. Prior to this policy becoming active we had received specific requests from IXPs (for IP blocks not restricted to be used exclusively for their peering LANs). From these requests: - 23 were approved with a size of /23 - 1 with a size of /23,/24 - 9 with a size of /22 - 1 with a size of /23,/23,/24 Finally please note that, as some IXPs are also LIRs, they can use parts of their IPv4 allocations for their peering LANs (i.e. referring to some IP blocks larger than a /22 that have been mentioned in this thread). These are not considered as direct IXP assignments. I hope this helps. Kind regards, Nikolas Pediaditis Assistant Manager Registration Services & Policy Development RIPE NCC > On 29 May 2019, at 15:41, Nick Hilliard wrote: > > Denis Fondras wrote on 29/05/2019 14:11: >> On Wed, May 29, 2019 at 02:17:43PM +0200, Marco Schmidt wrote: >>> This proposal aims to increase the reserved IPv4 pool for IXPs to a >>> /15 and finetune assignment criteria. >>> You can find the full proposal at: https://www.ripe.net/participate/policies/proposals/2019-05 >> Just because of "It no longer provides for IXPs that need more than a >> /23 of IPv4 space" I am against this proposal. > > Could the NCC provide any stats on how many /22s have been assigned under the IXP assignment policy? > > /23 is 512 hosts, which is large by IXP standards. The PCH IXP directory suggests there are about 20 IXPs worldwide which are larger than 256 connected parties. > > Nick > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2640 bytes Desc: not available URL: From wusel+ml at uu.org Wed May 29 18:47:34 2019 From: wusel+ml at uu.org (Kai 'wusel' Siering) Date: Wed, 29 May 2019 18:47:34 +0200 Subject: [address-policy-wg] 2019-05 New Policy Proposal (Revised IPv4 assignment policy for IXPs) In-Reply-To: <20190529154508.GR25123@Space.Net> References: <7608231559137379@iva8-b333b7f98ab0.qloud-c.yandex.net> <20190529154508.GR25123@Space.Net> Message-ID: <8c1ef976-cc0f-2161-8af4-a9896d96b58f@uu.org> On 29.05.2019 17:45, Gert Doering wrote: > IXPs say they need globally unique space, and they are the experts here. The same was true some years back, when the mobile operators asked for some dozen /16s for their customers. They didn't get those blocks, they were forced to look for alternatives, they found alternatives. ("NATs are good. CGNs doubly so.") Given the circumstances, for *any* request of "more v4 space for my use case" it is just and equitable to request a documented evidence the suggested soluion is the *only* way to accomplish the goal. I don't agree that it is the APWG chair's decision which request needs to be backed by facts and which isn't. Regards, -kai From ripe-wgs at radu-adrian.feurdean.net Wed May 29 18:58:28 2019 From: ripe-wgs at radu-adrian.feurdean.net (Radu-Adrian FEURDEAN) Date: Wed, 29 May 2019 18:58:28 +0200 Subject: [address-policy-wg] =?utf-8?q?2019-05_New_Policy_Proposal_=28Rev?= =?utf-8?q?ised_IPv4_assignment_policy_for_IXPs=29?= In-Reply-To: <20190529154817.GS25123@Space.Net> References: <20190529131131.GQ53067@carcass.ledeuns.net> <26224ebc-4822-4b65-944a-ff31d862519b@www.fastmail.com> <20190529154817.GS25123@Space.Net> Message-ID: <714f4589-c688-4b60-a9b0-e6aafd20c324@www.fastmail.com> On Wed, May 29, 2019, at 17:48, Gert Doering wrote: > Does this matter? For the IXP - definitely no. For the rest of the pool - maybe. This is why I was asking. -- Radu-Adrian FEURDEAN From gert at space.net Wed May 29 19:41:33 2019 From: gert at space.net (Gert Doering) Date: Wed, 29 May 2019 19:41:33 +0200 Subject: [address-policy-wg] 2019-05 New Policy Proposal (Revised IPv4 assignment policy for IXPs) In-Reply-To: <8c1ef976-cc0f-2161-8af4-a9896d96b58f@uu.org> References: <7608231559137379@iva8-b333b7f98ab0.qloud-c.yandex.net> <20190529154508.GR25123@Space.Net> <8c1ef976-cc0f-2161-8af4-a9896d96b58f@uu.org> Message-ID: <20190529174133.GV25123@Space.Net> Hi, On Wed, May 29, 2019 at 06:47:34PM +0200, Kai 'wusel' Siering wrote: > On 29.05.2019 17:45, Gert Doering wrote: > > IXPs say they need globally unique space, and they are the experts here. > > The same was true some years back, when the mobile operators asked for some dozen /16s for their customers. They didn't get those blocks, they were forced to look for alternatives, they found alternatives. ("NATs are good. CGNs doubly so.") As far as I know, everybody who presented "documented need" *did* get their blocks. At least, this has always been the IPv4 policy as soon as there was space to allocate - and there has never been a clause "for this-and-that access technology, you can't have space". Neither for DSL, nor cable, nor for mobile. If mobile providers decided to not follow this route because they found it too complicated, or too cumbersome to document what some considered trade secrets and went with CGNAT instead - that's certainly their own decision, but was never mandated by policy. > Given the circumstances, for *any* request of "more v4 space for my use case" it is just and equitable to request a documented evidence the suggested soluion is the *only* way to accomplish the goal. I don't agree that it is the APWG chair's decision which request needs to be backed by facts and which isn't. Since you've run an IXP yourself in the past, you should know the technical requirements quite well. So I'm not sure exactly what point you're trying to make. Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From tore at fud.no Fri May 31 09:08:30 2019 From: tore at fud.no (Tore Anderson) Date: Fri, 31 May 2019 09:08:30 +0200 Subject: [address-policy-wg] 2019-05 New Policy Proposal (Revised IPv4 assignment policy for IXPs) In-Reply-To: References: Message-ID: * Marco Schmidt > A new RIPE Policy proposal, 2019-05, "Revised IPv4 assignment policy for IXPs" is now available for discussion. I am positive to this policy proposal. A suggestion, though: use the /16 set aside in ?5.2 Unforeseen circumstances? for expanding the IXP pool. The unforeseen circumstances reservation is 185.0.0.0/16 while the IXP pool is 185.1.0.0/16. They combine nicely into 185.0.0.0/15. This might be helpful for operators that might want to exempt known IXP ranges from uRPF filtering, for example. Also, I am wondering about the thinking behind giving out /24s by default when the minimum assignment size is reduced /27. Why not right-size the assignment all the way down to the minimum assignment size, thus maximising the amount of future entrants the pool can support? There's nothing special about the /24 boundary for the IXP use case, to the best of my knowledge. Tore From gert at space.net Fri May 31 09:15:16 2019 From: gert at space.net (Gert Doering) Date: Fri, 31 May 2019 09:15:16 +0200 Subject: [address-policy-wg] 2019-05 New Policy Proposal (Revised IPv4 assignment policy for IXPs) In-Reply-To: References: Message-ID: <20190531071516.GL25123@Space.Net> Hi, On Fri, May 31, 2019 at 09:08:30AM +0200, Tore Anderson wrote: > Also, I am wondering about the thinking behind giving out /24s > by default when the minimum assignment size is reduced /27. Why not > right-size the assignment all the way down to the minimum assignment > size, thus maximising the amount of future entrants the pool can > support? There's nothing special about the /24 boundary for the IXP > use case, to the best of my knowledge. We briefly touched this in the WG session last Wednesday. Doing it this way removes the discussion about "larger address block for routing reasons" *if* the IXP in question decides that they do want to announce their prefix. So, as written today, "if you don't know", you get a /24 which could be routed later. "If you are sure you're small and do not want this announced", you can ask for a /27.../25. Not advocating anything, just relaying what was the explanation given. Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From wolfgang.tremmel at de-cix.net Fri May 31 09:17:15 2019 From: wolfgang.tremmel at de-cix.net (Wolfgang Tremmel) Date: Fri, 31 May 2019 07:17:15 +0000 Subject: [address-policy-wg] 2019-05 New Policy Proposal (Revised IPv4 assignment policy for IXPs) In-Reply-To: References: Message-ID: <24671A50-E5A6-40F1-8DB0-7BB2298ABB51@de-cix.net> Hi, > On 31. May 2019, at 09:08, Tore Anderson wrote: > > Also, I am wondering about the thinking behind giving out /24s by default when the minimum assignment size is reduced /27. Why not right-size the assignment all the way down to the minimum assignment size, thus maximising the amount of future entrants the pool can support? There's nothing special about the /24 boundary for the IXP use case, to the best of my knowledge. when opening a new exchange there are no customers connected yet, all you have is a business plan. So everything is kind of speculative and you can easily adjust your plan that you need a /24 - so why add additional workload to the NCC to review business plans? An honest IXP operator can request something smaller if he knows that the exchange will not grow beyond a small number of customers within the first 5 years or so. best regards Wolfgang -- Wolfgang Tremmel Phone +49 69 1730902 26 | Fax +49 69 4056 2716 | Mobile +49 171 8600 816 | wolfgang.tremmel at de-cix.net Executive Directors: Harald A. Summa and Sebastian Seifert | Trade Registry: AG Cologne, HRB 51135 DE-CIX Management GmbH | Lindleystrasse 12 | 60314 Frankfurt am Main | Germany | www.de-cix.net -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4191 bytes Desc: not available URL: From wolfgang.tremmel at de-cix.net Fri May 31 09:22:41 2019 From: wolfgang.tremmel at de-cix.net (Wolfgang Tremmel) Date: Fri, 31 May 2019 07:22:41 +0000 Subject: [address-policy-wg] 2019-05 New Policy Proposal (Revised IPv4 assignment policy for IXPs) In-Reply-To: <7629971559139155@sas2-7b909973f402.qloud-c.yandex.net> References: <7608231559137379@iva8-b333b7f98ab0.qloud-c.yandex.net> <20190529135816.GR53067@carcass.ledeuns.net> <7629971559139155@sas2-7b909973f402.qloud-c.yandex.net> Message-ID: Hello, > On 29. May 2019, at 16:12, Alexandr Popov wrote: > > The small technical difficulties of using private networks by IXPs are easily solved. well, you are mistaken. Here is a (not complete) list of reasons private networks cannot be used.... - Customers connect to multiple exchanges. Some of them with the same router. So each IXP peering LAN must be unique or you have the risk of having the same peering LAN twice (or more) to connect to on the same router. Which does not work. - Private IP space may be already in use at customers. And be routed within their AS. Thats the obvious argument, but not the only one. - Provisioning automation (at the customer side). We once used private IPv4 space to test customers for compliance during the connect phase and we encountered problems especially with large networks where engineers were not allowed to configure the routers directly but had to use some tool, which simply did not allow the engineer to configure any private IPv4 address on an interface. So IMHO private IPv4 space is not an option. Neither is using the same IXP lan on every exchange. best regards Wolfgang -- Wolfgang Tremmel Phone +49 69 1730902 26 | Fax +49 69 4056 2716 | Mobile +49 171 8600 816 | wolfgang.tremmel at de-cix.net Executive Directors: Harald A. Summa and Sebastian Seifert | Trade Registry: AG Cologne, HRB 51135 DE-CIX Management GmbH | Lindleystrasse 12 | 60314 Frankfurt am Main | Germany | www.de-cix.net -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4191 bytes Desc: not available URL: From tore at fud.no Fri May 31 09:41:22 2019 From: tore at fud.no (Tore Anderson) Date: Fri, 31 May 2019 09:41:22 +0200 Subject: [address-policy-wg] 2019-05 New Policy Proposal (Revised IPv4 assignment policy for IXPs) In-Reply-To: <20190531071516.GL25123@Space.Net> References: <20190531071516.GL25123@Space.Net> Message-ID: * Gert Doering > On Fri, May 31, 2019 at 09:08:30AM +0200, Tore Anderson wrote: >> Also, I am wondering about the thinking behind giving out /24s >> by default when the minimum assignment size is reduced /27. Why not >> right-size the assignment all the way down to the minimum assignment >> size, thus maximising the amount of future entrants the pool can >> support? There's nothing special about the /24 boundary for the IXP >> use case, to the best of my knowledge. > > We briefly touched this in the WG session last Wednesday. Doing it > this way removes the discussion about "larger address block for routing > reasons" *if* the IXP in question decides that they do want to announce > their prefix. > > So, as written today, "if you don't know", you get a /24 which could > be routed later. "If you are sure you're small and do not want this > announced", you can ask for a /27.../25. > > Not advocating anything, just relaying what was the explanation given. Right. Looking at the DFZ, there is only a single advertisement coming out of the current IXP pool?: https://stat.ripe.net/widget/routing-status#w.resource=185.1.0.0%2F16 Considering how extremely uncommon this configuration is, I'd prefer it to be the other way around, i.e., that a small IXP with a dozen members would need to explain why they need a /24 in order to get it, otherwise they'd get a /27 by default. If we give out /27s by default to such small IXPs each /24 in the pool can accommodate 8 IXPs. With the current (and proposed) policy we'd need a /21 to accommodate those same 8 IXPs (as I do not imagine any of them explicitly requesting something smaller than what's on offer by default). This seems wasteful. [1] I was told on IRC that the reason for the specific advertisement seen is to provide some kind of quasi-OOB Internet transit service to the IXP members. If that is correct it seems to me to possibly run afoul of the first bullet in section 6.1, but whatever. Tore From alexp at ma.spb.ru Fri May 31 09:43:17 2019 From: alexp at ma.spb.ru (Alexandr Popov) Date: Fri, 31 May 2019 10:43:17 +0300 Subject: [address-policy-wg] 2019-05 New Policy Proposal (Revised IPv4 assignment policy for IXPs) In-Reply-To: References: <7608231559137379@iva8-b333b7f98ab0.qloud-c.yandex.net> <20190529135816.GR53067@carcass.ledeuns.net> <7629971559139155@sas2-7b909973f402.qloud-c.yandex.net> Message-ID: <6366311559288597@sas1-50036f4033a1.qloud-c.yandex.net> Hello, I do not argue, it creates some difficulties. But they CAN be solved. I think it?s wrong to give a priority to get IPv4 for IPXs. Because, in many other areas, there are no similar solutions. I mean companies providing services for ordinary users. Mail servers, etc. 31.05.2019, 10:22, "Wolfgang Tremmel" : > Hello, > >> ?On 29. May 2019, at 16:12, Alexandr Popov wrote: >> >> ?The small technical difficulties of using private networks by IXPs are easily solved. > > well, you are mistaken. > > Here is a (not complete) list of reasons private networks cannot be used.... > > - Customers connect to multiple exchanges. Some of them with the same router. So each IXP peering LAN must be unique or you have the risk of having the same peering LAN twice (or more) to connect to on the same router. Which does not work. > > - Private IP space may be already in use at customers. And be routed within their AS. Thats the obvious argument, but not the only one. > > - Provisioning automation (at the customer side). We once used private IPv4 space to test customers for compliance during the connect phase and we encountered problems especially with large networks where engineers were not allowed to configure the routers directly but had to use some tool, which simply did not allow the engineer to configure any private IPv4 address on an interface. > > So IMHO private IPv4 space is not an option. Neither is using the same IXP lan on every exchange. > > best regards > Wolfgang > > -- > Wolfgang Tremmel > > Phone +49 69 1730902 26 | Fax +49 69 4056 2716 | Mobile +49 171 8600 816 | wolfgang.tremmel at de-cix.net > Executive Directors: Harald A. Summa and Sebastian Seifert | Trade Registry: AG Cologne, HRB 51135 > DE-CIX Management GmbH | Lindleystrasse 12 | 60314 Frankfurt am Main | Germany | www.de-cix.net From wolfgang.tremmel at de-cix.net Fri May 31 09:46:56 2019 From: wolfgang.tremmel at de-cix.net (Wolfgang Tremmel) Date: Fri, 31 May 2019 07:46:56 +0000 Subject: [address-policy-wg] 2019-05 New Policy Proposal (Revised IPv4 assignment policy for IXPs) In-Reply-To: References: <20190531071516.GL25123@Space.Net> Message-ID: > On 31. May 2019, at 09:41, Tore Anderson wrote: > > Considering how extremely uncommon this configuration is, I'd prefer it to be the other way around, i.e., that a small IXP with a dozen members would need to explain why they need a /24 in order to get it, otherwise they'd get a /27 by default. when an IXP first applies for an allocation out of the pool it has zero customers. It only has a business plan and how many customers it *expects* to have. Which easily can be "tweaked". So to avoid that RIPE NCC checks business plans we should stick with /24 as default. best regards, Wolfgang -- Wolfgang Tremmel Phone +49 69 1730902 0 | Fax +49 69 4056 2716 | | wolfgang.tremmel at de-cix.net Executive Directors: Harald A. Summa and Sebastian Seifert | Trade Registry: AG Cologne, HRB 51135 DE-CIX Management GmbH | Lindleystrasse 12 | 60314 Frankfurt am Main | Germany | www.de-cix.net -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4191 bytes Desc: not available URL: From tore at fud.no Fri May 31 09:55:53 2019 From: tore at fud.no (Tore Anderson) Date: Fri, 31 May 2019 09:55:53 +0200 Subject: [address-policy-wg] 2019-05 New Policy Proposal (Revised IPv4 assignment policy for IXPs) In-Reply-To: <24671A50-E5A6-40F1-8DB0-7BB2298ABB51@de-cix.net> References: <24671A50-E5A6-40F1-8DB0-7BB2298ABB51@de-cix.net> Message-ID: <8656722a-a9dc-a24a-5385-0547be6dc868@fud.no> * Wolfgang Tremmel > when opening a new exchange there are no customers connected yet, all you have is a business plan. So everything is kind of speculative and you can easily adjust your plan that you need a /24 - so why add additional workload to the NCC to review business plans? Hi, Using this rationale, why stop at /24? Why not give /23s by default - that is the only way to ascertain that the NCC does not have to review business plans, after all? I don't see how /24 is special in this context. Also note that ?stopping the NCC from reviewing business plans? is not a stated objective of this policy proposal. In any case, if the IXP manages to fill up its /x with members the policy allows for replacing it with with a /x+1. > An honest IXP operator can request something smaller if he knows that the exchange will not grow beyond a small number of customers within the first 5 years or so. You are implying that small IXPs that do not need more than /{27..25} are being dishonest if they don't say so instead of taking the default /24 on offer. Note that there is nothing in the proposed policy that requires or even encourages them to do so, however. So why would they? Tore From nick at foobar.org Fri May 31 10:22:45 2019 From: nick at foobar.org (Nick Hilliard) Date: Fri, 31 May 2019 09:22:45 +0100 Subject: [address-policy-wg] 2019-05 New Policy Proposal (Revised IPv4 assignment policy for IXPs) In-Reply-To: References: <20190531071516.GL25123@Space.Net> Message-ID: <1cf4aa12-c483-5eda-1430-5a10977d7230@foobar.org> Tore Anderson wrote on 31/05/2019 08:41: > Looking at the DFZ, there is only a single advertisement coming out > of the current IXP pool?: > > https://stat.ripe.net/widget/routing-status#w.resource=185.1.0.0%2F16 The prefix in question is 185.1.69.0/24. > [1] I was told on IRC that the reason for the specific advertisement > seen is to provide some kind of quasi-OOB Internet transit service to > the IXP members. The prefix in question is 185.1.69.0/24 (INEX Cork). Putting my INEX CTO hat on for a moment, I can confirm that INEX does not provide a quasi-OOB Internet transit service for its members. Nick From tore at fud.no Fri May 31 12:26:45 2019 From: tore at fud.no (Tore Anderson) Date: Fri, 31 May 2019 12:26:45 +0200 Subject: [address-policy-wg] 2019-02 Review Phase (IPv4 Waiting List Implementation) In-Reply-To: References: Message-ID: * Marco Schmidt > Policy proposal 2019-02, "IPv4 Waiting List Implementation" is now in the Review Phase. Support. Tore