Re: FYI - Suspension of Cogent access to ARIN Whois
Am 06.01.20 um 16:58 schrieb David Guo via NANOG: > Good News! But we still received several spams from Cogent for our RIPE > and APNIC ASNs. They seem to look at changes in more databases than just ARIN... Several months ago I received a new ASN from RIPE for a company that is in business for more than 25 years now, but always used static routing for their PI space from one transit provider. 2 days after the ASN has been registered in the RIPE database somebody from Cogent called me as the admin-c and asked if we need transit for the new ASN or help with BGP. Also, as we all know, Cogent calls or sends emails every few months although you tell them to remove your contact details from their database. Once in, never out... P.S.: Thanks to ARIN for blocking Cogent from the database. Others should do the same until Cogent stops spamming the contacts for sales reasons. Chris
msn/hotmail email admin needed
Hello, would an email admin from msm/hotmail please contact me off-list? We have problems sending emails to msn/hotmail from several ip addresses and trying to find someone who can help. Thanks in advance. Sorry for spamming this list, but establishing a direct contact or opening tickets did not work. Regards, Christian Seitz Network Operations -- --- Telefon: +49 (0)30 - 398 02 0 E-Mail : se...@strato-rz.de Website: http://www.strato.de/ --- STRATO AG Pascalstr. 10 10587 Berlin --- Vorsitzender des Aufsichtsrates: Phil Zamani Vorstand: Damian Schmidt (Vorsitz), Julien Ardisson, Christian Mueller, Christoph Steffens, Rene Wienholtz Amtsgericht Berlin-Charlottenburg HRB 79450
Re: Minimum Allocation Size by RIRs (IPv4)
Hello Fredy, Am 15.11.2011 15:56, schrieb Fredy Kuenzler: I'm trying to compile a comprehensive and up-to-date list of Minimum Allocation Sizes by the various RIRs. Any hint would be appreciated. I have so far: ARIN: https://www.arin.net/knowledge/ip_blocks.html APNIC: http://www.apnic.net/publications/research-and-insights/ip-address-trends/minimum-allocations (seems that they have recently changed from /22 to /24, which is not too helpful...) RIPE NCC: http://www.ripe.net/ripe/docs/ripe-510#5 Nothing found for AFRINIC and LACNIC yet, and legacy space, too. I made such a list some month ago and also found those links: LACNIC: http://lacnic.net/en/registro/index.html AfriNIC: http://www.afrinic.net/Registration/resources.htm ARIN Micro Allocations: https://www.arin.net/knowledge/micro_allocations.html Regards, Christian Seitz Network Operations -- --- Telefon: +49 (0)30 - 398 02 205 Mobil : +49 (0)172 - 389 8714 Telefax: +49 (0)30 - 398 02 222 E-Mail : se...@strato-rz.de Website: http://www.strato.de/ --- STRATO AG Pascalstr. 10 10587 Berlin --- Vorsitzender des Aufsichtsrates: Dirk Backofen Vorstand: Damian Schmidt (Vorsitz), Julien Ardisson, Christian Mueller, Christoph Steffens, Rene Wienholtz Amtsgericht Berlin-Charlottenburg HRB 79450
Re: advertisements of 14/8 and 223/8
Hello, Tomoya Yoshida wrote: I started to advertise for test two /8s and in addition to collecting of unwanted traffic I checked the status of route-views of these two /8s including two experimental prefixes in 27/8 which is allocated to APNIC on Jan 2010 and old 115/8 space. http://www.nttv6.jp/~yoshida/bogon_rviews_20100415_yoshida.pdf For 27/8, It seemse that some ISP still dosen't update their filter or dosen't advertise to route-views by some reasons. Now I'm using 27/8 space and I found that there is no reachability about 10% ASes, at least 2,000 ASes as our test, It can't be said the good situation at all. I will continue to test this month and would like to share about the result somewhere. Also the interesting result is that there is differences between 14/8 and 223/8 on route-views result. Do you have any idea? I have heard from some carriers that they only accept selected /8s, but not from all IP ranges. Perhaps the test announcements should be 4x /10 for example instead of a single /8. Then the announcements should reach more ASes. Regards, Chris
Re: Minimum IPv6 size
Hello, Kevin Oberman wrote: Date: Sat, 03 Oct 2009 09:27:27 +0100 From: James Aldridge j...@mcvax.org --On 2 October 2009 16:43:14 -0700 Kevin Oberman ober...@es.net wrote: Depends on the address space it is assigned from. Most specify a maximum prefix length of 32, but the micro-allocations and the allocations for PI dual-homing are /48. We consider the following to be legal: /* global unicast allocations */ route-filter 2001::/16 prefix-length-range /19-/35; /* 6to4 prefix */ route-filter 2002::/16 prefix-length-range /16-/16; /* RIPE allocations */ route-filter 2003::/18 prefix-length-range /19-/32; /* APNIC allocations */ route-filter 2400::/12 prefix-length-range /13-/32; /* ARIN allocations */ route-filter 2600::/12 prefix-length-range /13-/32; /* ARIN allocations */ route-filter 2610::/23 prefix-length-range /24-/32; /* LACNIC allocations */ route-filter 2800::/12 prefix-length-range /13-/32; /* RIPE allocations */ route-filter 2A00::/12 prefix-length-range /13-/32; /* AfriNIC allocations */ route-filter 2C00::/12 prefix-length-range /13-/32; /* APNIC PI allocations */ route-filter 2001:0DF0::/29 prefix-length-range /40-/48; /* AFRINIC PI allocations */ route-filter 2001:43F8::/29 prefix-length-range /40-/48; /* ARIN PI allocations */ route-filter 2620::/23 prefix-length-range /40-/48; /* ARIN Micro-allocations */ route-filter 2001:0500::/24 prefix-length-range /44-/48; This means accepting prefixes ARIN says we should not, but ARIN does not set our routing policy and I will be on a panel on that issue at NANOG in Dearborn later this month. It might be worth relaxing filtering within 2001::/16. The RIPE NCC appears to be making /48 PI assignments from within 2001:678::/29 (e.g. the RIPE Meeting next week will be using 2001:67c:64::/48) Looks like we need to relax 2001:678::/29 a bit, but I am not sure that we will open up the entire /16. I already have such for ARIN, AfriNIC, and APNIC. Is there some central repository for information on this? We usually seem to find out about such changes out of the ARIN region a bit after the fact. each RIR has an overview of their managed address space with the longest prefixes they are assigning/allocating from their ranges. I currently use those overviews to build IPv6 BGP filters manually. If you build very strict filters, you have to check the overviews more often as with loose filters. https://www.ripe.net/ripe/docs/ripe-ncc-managed-address-space.html http://www.arin.net/reference/ip_blocks.html http://www.arin.net/reference/micro_allocations.html http://www.apnic.net/db/min-alloc.html http://lacnic.net/en/registro/index.html http://www.afrinic.net/Registration/resources.htm There ist also a loose and a strict filter recommendation by Gert Doering [1], but the strict filter is very strict at the moment. It allows only /48s from RIPEs IPv6 PI space 2001:678::/29 for example, although RIPE currently also assignes /47 or /46 from this range. Also there should be some deaggregation allowed. When RIPE allocates a /32 to a LIR and LIR has to deaggregate it for some reason, because he cannot get a second /32, he should be able to use (eg.) 4 bits for deaggreation. I don't want to see a /48 where RIPE allocates only /32 prefixes, but I would accept prefixes up to a /36. [1] http://www.space.net/~gert/RIPE/ipv6-filters.html Regards, Christian Seitz
Re: Anomalies with AS13214 ?
Hello, Jay Hennigan wrote: We're getting cyclops[1] alerts that AS13214 is advertising itself as origin for all of our prefixes. Their anomaly report shows thousands of prefixes originating there. Anyone else seeing evidence of this or being affected? I have also seen this today for our prefixes where Cyclops reported the as path 48285 13214. After sending an e-mail to both ASN I got the following answer from AS48285: Our transit 13214 had interesting router problems affecting bgp origins for the entire bgp table. The next-hop and thus routing was still working fine though. Since we collect bgp data from several transits and announce it to multiple route servers and for our own publicly available bgp-tools, it looked worse than it was, but as far as we can tell it was actually never propagated by them to the Internet except to downstreams, where traffic still worked, although via an unusually short path. Regards, Christian Seitz Network Operations
