- members-discuss - mailman.ripe.net

Update on announce issue
by Bill Lewis 22 May '17

22 May '17

Hi All, Thanks for the feedback on this, it seems the fastest way to have them fix this is to post on here. 3 days of hell later and things have been now been resolved. I would say though, will those companies whose ticketing systems replied en mass please remove them from these lists, it is rather unprofessional -- Bill Lewis Kijoma Broadband

1 0

Re: [members-discuss] Provider announcing IP ranges when they should not be.
by Nick Hilliard 22 May '17

22 May '17

Bill Lewis wrote: > Is there any mechanism in place or tools available to make it easy to > either block this false route or have action taken against the provider > for failing to stop it? - announcement of more specific routes - escalation at their NOC - if it's the UK, try some megaphone diplomacy on the uknof mailing list - talk to their upstream You could threaten lawyers and all that end of things, but bearing in mind that this sort of thing is rarely caused by malice, you're almost always better off being courteous but persistent in getting a mistake corrected. Nick

1 0

Re: [members-discuss] Provider announcing IP ranges when they should not be.
by David Ponzone 22 May '17

22 May '17

Bill, you should contact their upstream and in the meantime, you could try to announce more specific routes, in order to reduce the impact. Of course, if the blocks are both /24, it’s not going to be very efficient as prefixes more specific than /24 will be probably filtered by your upstreams. > Le 22 mai 2017 à 11:44, Bill Lewis <Bill.lewis(a)kijoma.co.uk> a écrit : > > HI all, > > Not sure where I should post this so trying here first. > > Quick question, we changed hosts recently as the former host are moving their DC at the end of this month and our services would not work from their new location (wireless back haul). > > We asked them to remove two of our IP blocks from their routers so they are no longer announced there as we have now got them announced at the new host. > > Last Friday they confirmed by email they had done this, but it is clear they have not as reverse trace routes from some local (to London) sites show they are still announcing them even today. > > This means many resources are unreachable by our clients and is causing significant disruption. > > We have again chased them to resolve this. > > Is there any mechanism in place or tools available to make it easy to either block this false route or have action taken against the provider for failing to stop it? > > Thank you > > -- > Bill Lewis > Kijoma Solutions Ltd > > > ---- > If you don't want to receive emails from the RIPE NCC members-discuss > mailing list, please log in to your LIR Portal account and go to the general page: > https://lirportal.ripe.net/general/ > > Click on "Edit my LIR details", under "Subscribed Mailing Lists". From here, you can add or remove addresses.

1 0

Re: [members-discuss] Provider announcing IP ranges when they should not be.
by Laurent Seror 22 May '17

22 May '17

If you are the maintainer of the Route objects, be sure to edit them to reflect the new AS announcing them. Then you can write to all your previous operator providers to have them reflect that in their prefix-accept rules. L. 2017-05-22 11:44 GMT+02:00 Bill Lewis <Bill.lewis(a)kijoma.co.uk>: > HI all, > > Not sure where I should post this so trying here first. > > Quick question, we changed hosts recently as the former host are moving > their DC at the end of this month and our services would not work from > their new location (wireless back haul). > > We asked them to remove two of our IP blocks from their routers so they > are no longer announced there as we have now got them announced at the new > host. > > Last Friday they confirmed by email they had done this, but it is clear > they have not as reverse trace routes from some local (to London) sites > show they are still announcing them even today. > > This means many resources are unreachable by our clients and is causing > significant disruption. > > We have again chased them to resolve this. > > Is there any mechanism in place or tools available to make it easy to > either block this false route or have action taken against the provider for > failing to stop it? > > Thank you > > -- > Bill Lewis > Kijoma Solutions Ltd > > > ---- > If you don't want to receive emails from the RIPE NCC members-discuss > mailing list, please log in to your LIR Portal account and go to the > general page: > https://lirportal.ripe.net/general/ > > Click on "Edit my LIR details", under "Subscribed Mailing Lists". From > here, you can add or remove addresses. > -- Best Regards - Cordialement, [image: outscale_logo] <https://www.outscale.com> EUROPE / NORTH AMERICA / ASIA Laurent SEROR CEO Direct +33 1 53 27 52 89 Fax. +33 1 83 62 92 89 www.outscale.com [image: logo_facebook] <https://www.facebook.com/outscale/> [image: logo_twitter] <https://twitter.com/outscale> [image: logo_google+] <https://plus.google.com/+Outscale/posts> [image: logo_linkedin] <https://www.linkedin.com/company/outscale> [image: logo_youtube] <https://www.youtube.com/user/outscale> [image: Outscale] <https://www.outscale.com/fr/signature-mail/> ------------------------------ IMPORTANT: Ce message, y compris les documents joints, est susceptible de contenir des informations confidentielles à l’usage exclusif de son/ses destinataire(s). Si vous n’êtes pas destinataire de ce message, nous vous rappelons qu’il vous est strictement interdit de le divulguer, diffuser, reproduire ou utiliser à quelque fin que ce soit. Si vous avez reçu ce message par erreur, merci d’en avertir l’expéditeur et d’effacer ce message et les documents joints de votre système.

1 0

Re: [members-discuss] Provider announcing IP ranges when they should not be.
by Jürgen Jaritsch (juergen.jaritsch＠jmpts.ch) 22 May '17

22 May '17

Hi Bill, What subnet size are you talking about? Several small /24 or something like /19 etc? You can hijack your own prefixes as a quick fix if you're dealing with prefixes >/24: just announce more specific /24 to get the issue mostly bypassed. If this is no option for you, please feel free to share some more details like ASN and affected prefixes. With this details most users will be able to help you to track down the issue :). Best regards Jürgen JARITSCH CEO, Co-Founder JMP Technology Services GmbH Zugerstrasse 76 B CH 6340 Baar Switzerland E-Mail: juergen.jaritsch(a)jmpts.ch Mobil: +43-660-8889638 -----Ursprüngliche Nachricht----- Von: members-discuss [mailto:members-discuss-bounces@ripe.net] Im Auftrag von Bill Lewis Gesendet: Montag, 22. Mai 2017 11:45 An: members-discuss(a)ripe.net Betreff: [members-discuss] Provider announcing IP ranges when they should not be. HI all, Not sure where I should post this so trying here first. Quick question, we changed hosts recently as the former host are moving their DC at the end of this month and our services would not work from their new location (wireless back haul). We asked them to remove two of our IP blocks from their routers so they are no longer announced there as we have now got them announced at the new host. Last Friday they confirmed by email they had done this, but it is clear they have not as reverse trace routes from some local (to London) sites show they are still announcing them even today. This means many resources are unreachable by our clients and is causing significant disruption. We have again chased them to resolve this. Is there any mechanism in place or tools available to make it easy to either block this false route or have action taken against the provider for failing to stop it? Thank you -- Bill Lewis Kijoma Solutions Ltd ---- If you don't want to receive emails from the RIPE NCC members-discuss mailing list, please log in to your LIR Portal account and go to the general page: https://lirportal.ripe.net/general/ Click on "Edit my LIR details", under "Subscribed Mailing Lists". From here, you can add or remove addresses.

1 0

Provider announcing IP ranges when they should not be.
by Bill Lewis 22 May '17

22 May '17

HI all, Not sure where I should post this so trying here first. Quick question, we changed hosts recently as the former host are moving their DC at the end of this month and our services would not work from their new location (wireless back haul). We asked them to remove two of our IP blocks from their routers so they are no longer announced there as we have now got them announced at the new host. Last Friday they confirmed by email they had done this, but it is clear they have not as reverse trace routes from some local (to London) sites show they are still announcing them even today. This means many resources are unreachable by our clients and is causing significant disruption. We have again chased them to resolve this. Is there any mechanism in place or tools available to make it easy to either block this false route or have action taken against the provider for failing to stop it? Thank you -- Bill Lewis Kijoma Solutions Ltd

1 0

Re: [members-discuss] Input from Membership on RIPE NCC Charging Scheme Model
by Muntasir.Ali＠newham.gov.uk 26 Apr '17

26 Apr '17

Hi, As a non-profit LIR with a /16 Legacy IPv4 address space, and only Legacy space within IPv4, we would be opposed to any charging models based on size of IP allocations, especially those which include Legacy space within consideration of calculating what is charged. This is considering that many (not all) of the proposed "solutions" may make it more expensive or infeasible for us to retain membership were they implemented as described. Our main motivation of joining up was for IPv6 address space allocation, so that we can move to enabling IPv6 services on our networks. If it turns out more expensive to retain membership simply because of our Legacy address space, were RIPE to adopt a model based on size of IP address space, then for us, it would make more sense to set up a new business and register that as a brand new LIR without any IPv4 space, and just ask for an IPv6 allocation. If the charging model is based purely on IPv4 space, then in theory if we have no IPv4 registered, we don't get charged anything? We don't need the "free" /22 currently offered to new members. Even though we are currently eligible for the extra /22 on top of our Legacy space, we have chosen not to take up the offer, since we know the /22 would be better served allocated to another RIPE member; hording it makes no sense for us nor for the wider community. Not that I expect it to work that way anyway (creating an LIR with IPv6 allocation and no IPv4 allocation), that's simply not maintainable for RIPE if quite a large number of organisations were to do this, and it may push up costs for the members which do have IPv4 allocations. Which highlights another point - I've noticed there's been no mention or consideration of size of IPv6 allocations when it comes to charging models based on IP allocation. I presume the general membership don't consider this an issue at present due to the vast size of IPv6 address space? What happens for LIRs with only IPv6 space? Why aren't we considering the usage of other resources as well, such as AS number allocations? Also regarding the state of Legacy resources, I raised a ticket to enquire what would happen were we to stop membership. Quoting from the response: [quote] ...so the legacy space is not part of the Internet Registry system. You didn't get it from the RIPE NCC so if you close your LIR you keep it. The IPv6 allocation [...] you did get from the RIPE NCC so if you close your LIR it comes back to us. Your LIR also quailifies [sic] for a /22 of IPv4 and if you closed your LIR after receiving that it would also be returned to us. [/quote] This would imply that actually, RIPE cannot reasonably charge based on size of any Legacy space, because the space doesn't belong to RIPE, and we keep it if we left. By extension, if any charging model based on size of IPv4 allocation includes the Legacy space allocation, then it will make sense for any LIR with legacy space to create a second LIR, separate their legacy and non-legacy space by transferring one to the second LIR, then dropping membership for the LIR with the Legacy space. The remaining LIR with non-legacy space would then be charged less than if it retained all the space. Now this isn't really fair for the LIRs without Legacy space, but from a cost perspective, this would be the logical thing to do for LIRs with Legacy space, especially if they have a large amount of it. So for any proposal to charge based on IPv4 allocation which includes Legacy space, which for above reasons I don't think RIPE can do anyway, I would posture this would not give a fair or desired outcome in the long run, especially for the LIRs without Legacy space. But then, any proposals to charge based on IPv4 allocation which excludes Legacy space, are also arguably not fair either, because those with Legacy space would effectively get a disproportionately cheaper service for what they use, if we decide service charge is to be based on IPv4 usage. So I do not think _any_ proposal to charge based on IPv4 space can give a fair, reasonable, or desired outcome. > > > > Anyway, I believe that implementing a charge that is based on the > > size of the IPv4 resource allocation is fair and it would line up > > with RIPE NCC's goal of safeguarding the resources. Whether > > implementing a cost like the proposed €250/year per /24 or a fee > > based on categories such as the other RIRs are imposing, the model needs to be changed. > > I disagree. I'd rather the costs were distributed based on the costs of providing service to LIRs, which the current charging scheme seems to do quite well, subject to closing loopholes when someone tries to game the system. > > I agree with this. The cost model should be based on the cost of providing the actual service, not the size of address space any organisation may have. Because RIPE need to recover the costs of running their service, it would be fairer and more sensible to charge based on how much service is used, not on resource allocated. Of course this brings questions on what defines "service". Number of tickets raised? Number of objects of the various types in the database for that particular LIR? Frequency of database changes? Usage of tools like RIPE Atlas, other APIs? etc. This is assuming we don't keep the current flat rate scheme or use something similar, which as previously mentioned, appears to work quite well subject to closing loopholes being used for abuse. Regards, Muntasir Ali, Specialist ICT Analyst, ICT oneSource Newham Dockside , 1000 Dockside Road , London E16 2QU DDI: 020 3373 7337, Int: 37337 oneSource - working on behalf of Havering and Newham councils www.onesource.co.uk Follow us on Twitter: @oneSourceUK Please consider the environment before printing this email. ________________________________ NOTE: This communication is sent for and on behalf of the London Borough of Newham. However the views expressed within it are not necessarily the views or policies of the Council. The unauthorised use, disclosure, copying or alteration of this communication and any attachments is forbidden. This communication and any attachments are intended for the addressee only and may be confidential. If this has come to you in error you should immediately permanently destroy it. You should take no action based on it or copy or show it to anyone and telephone the Council immediately with any issues on 020 8430 2000 or any other number provided in the communication. Please note that electronic communication is not considered a secure medium for sending information and therefore maybe at risk. We advise that you understand and accept this lack of security when using this form of communication with us. Although we have taken steps to ensure that this email and attachments are free from any virus, we advise that in keeping with good computing practice the recipient should ensure they are actually virus free and should run current anti-virus software. Please note that email may be monitored and checked to safeguard the council network from viruses, hoax messages or abuse of the Council's systems. Action may be taken against any malicious and deliberate attempts to infect the council network. The information contained in this email maybe subject to public disclosure under the Freedom of Information Act 2000. Unless the information is legally exempt from disclosure the confidentiality of this email and your reply cannot be guaranteed.

36 84

IP Spoofing and NOC Gripes
by Shao Miller 23 Jan '17

23 Jan '17

Good day, folks. Which fora would you recommend regarding the following in the RIPE region?: * Unauthorized route-announcements and IP spoofing concerns * Un-co-operative NOCs -- Shao Miller Chief Executive Officer Synthetel Corporation T: +1.9053927729 <tel:+1.9053927729> E: ripe(a)synthetel.com W: https://www.synthetel.com

1 0

RIPE NCC Charging Scheme Discussion Review
by Nigel Titley 11 Jan '17

11 Jan '17

Dear Colleagues, On the 13th of September 2016, I opened a discussion of the RIPE NCC’s charging scheme model on the members-discuss mailing list: https://www.ripe.net/ripe/mail/archives/members-discuss/2016-September/0023… At the General Meeting (GM) in October, Christian Kaufmann presented a review of the discussion and received further comments from the audience. The minutes of the GM are available at: https://www.ripe.net/participate/meetings/gm/meetings/october-2016/minutes At its meeting on 15 December 2016, the Executive Board reviewed the discussion on the mailing list and from the GM. Firstly, I would like to thank all of those who contributed to this important discussion for the RIPE NCC. A wide range of innovative suggestions and ideas were offered by members from across the service region. However, none of the ideas for alternative models received an overwhelming amount of support from the membership. Other members expressed support for the current charging scheme model. At the next Executive Board Meeting on the 17th March 2017, we will take this discussion into account before proposing a charging scheme to be voted on by the members at the GM in Budapest in May. As always, the Executive Board is available at <exec-board(a)ripe.net> should you wish to contact us regarding this or any other RIPE NCC business. Best regards, Nigel Titley RIPE NCC Executive Board Chairman

1 0

Re: [members-discuss] DNS Reverse Zone Providers
by Tobias Lehner 05 Jan '17

05 Jan '17

Hi, I've decided I will try out the Azure DNS platform. Seems pretty straight forward and pretty cheap. Does anyone know how long it takes to be able to create the domain object. Currently I get the error "server is not authoritative for the zone"? Thanks :) Tobias Mit freundlichen Gr??en Tobias Lehner ............................................................ HARTL EDV GmbH & Co. KG IT-Zentrum 1 94544 Hofkirchen Tel.: +498545969930 Fax: +498545969996 E-Mail: tl(a)hartl-edv.de Homepage: www.hartl-group.de ............................................................ (c)Hartl EDV GmbH & Co. KG, Gesch?ftsf?hrer Peter Hartl | Sitz der Gesellschaft: IT-Zentrum 1, 94544 Hofkirchen | Registergericht: Amtsgericht Passau HRA 12910, Umsatzsteuer-Identifikationsnummer gem?? ? 27a Umsatzsteuergesetz DE 296108866 | Datenschutzbeauftragter Dominik Seifert | Leiterin der Datenverarbeitung Beate Hartl [cid:image001.jpg@329F8795.0001] [9108623352_306296_klein] Hartl EDV ist zertifiziert nach: ISO 9001:2008 Nr. 90502413/3-1 ISO27001:2013 Nr. 01 153 1401466 durch T?V Rheinland Cert GmbH Reliable Data Center Nr. 01 139 1600425 durch T?V Rheinland Cert GmbH Diese E-Mail enth?lt vertrauliche und/oder rechtlich gesch?tzte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrt?mlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese E-Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser E-Mail ist nicht gestattet. This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. Alle Rechte und technische ?nderungen vorbehalten. Von: Tobias Lehner Gesendet: Mittwoch, 28. Dezember 2016 17:20 An: 'members-discuss(a)ripe.net' <members-discuss(a)ripe.net> Betreff: AW: DNS Reverse Zone Providers Hi, Does anybody have experience with Reverse DNS Zones Providers? I decided I do not want to setup own DNS servers just for our reverse zones. Best Regards Tobias Lehner

5 5