Re: as 14551 contact
You might do well to contact AS701, as those are the same folks that manage 14551 (They never did get global AS rolled out) --h On Tue, Jun 22, 2021 at 8:27 AM Ricardo Patara wrote: > is there anyone from 14551 in the list that could contact me in private? > > i would appreciate. > > thanks > ricardo >
Re: FYI - Suspension of Cogent access to ARIN Whois
On Tue, Jan 7, 2020 at 8:50 AM John Curran wrote: > On 7 Jan 2020, at 5:01 AM, Martijn Schmidt via NANOG > wrote: > > > > Out of curiosity, since we aren't affected by this ourselves, I know of > cases where Cogent has sub-allocated IP space to its customers but which > those customers originate from their own ASN and then announce to multiple > upstream providers. > > > > So while the IP space is registered to Cogent and allocated to its > customer, the AS-path might be something like ^174_456$ but it's entirely > possible that ARIN would observe it as ^123_456$ instead. Are such IP > address blocks affected by the suspension? > > As noted earlier, ARIN has suspended service for all Cogent-registered IP > address blocks - this is being done as a discrete IP block access list > applied to relevant ARIN Whois services, so the routing of the blocks are > immaterial - a customer using a suballocation of Cogent space could be > affected but customers with their own IP blocks blocks that are simply > being routed by Cogent are not affected. > > "suspended service for all Cogent-registered IP address blocks" may be causing a bit of confusion since ARIN offers many services. >From your response, it sounds like it's just an ACL to filter inbound p43 traffic to ARIN's whois service, from Cogent allocated prefixes. ARIN is in the best position to tell who is directly scraping their db and whether this is an effective counter measure. Recent changes would show up easiest in bulk whois data. It's not clear from your message whether they had a bulk whois agreement in place and the status of that type of access. If so, revoking the API key would be a better restriction mechanism than filtering prefixes from reaching accountws.arin.net I haven't look at where ARIN's TAL data is hosted, again depending on how/where it's hosted and how a filter is implemented, it may or may not impact access to the data. deny $TOU_Violator any port 43 deny $TOU_Violator accountws.arin.net deny $TOU_Violator any These all have varying levels of impact. On the one hand I can understand not wanting to disclose the specific action taken, on the other hand it would be interesting to know what the scope of responses are for different types of abuse. > FYI, > /John > > John Curran > President and CEO > American Registry for Internet Numbers > > > >
Re: Google Fiber v6 PD only giving /64
I designed the original numbering plan, but handed it off a while back. Taking a look into this, thanks for the heads up. --Heather On Sat, Jan 5, 2019 at 11:58 PM Chris Adams wrote: > Anybody here from Google Fiber? When I first got it last year, my IPv6 > setup got a /56 prefix delegated. I now see that no matter what size I > request, I only get a /64. Is this intentional? > -- > Chris Adams >
Re: AS3266: BitCanal hijack factory, courtesy of many connectivity providers
https://datatracker.ietf.org/wg/sidr/about/ Being presented at nanog nowish: Architecting Robust BGP Routing Policies Lightning Talk: BGP Transport Security - Do You Care? Lightning Talk: Legal Barriers to Securing the Routing Architecture On Tue, Jun 26, 2018 at 2:31 PM, Mike Hammett wrote: > Authoritative list of shame with supporting evidence? (Yes, I assume there > isn't one and that one would have to be created.) > > Many network operators aren't going to know who's supposed to be on that > list and who isn't. > > > > > - > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com > > - Original Message - > > From: "Job Snijders" > To: "Mike Hammett" > Cc: nanog@nanog.org > Sent: Tuesday, June 26, 2018 1:30:05 PM > Subject: Re: AS3266: BitCanal hijack factory, courtesy of many > connectivity providers > > > On Tue, 26 Jun 2018 at 12:28, Mike Hammett < na...@ics-il.net > wrote: > > > > > Any solution to that? Yell at the IRRs more? > > > > > Or more generally, everyone involved should consider to stop selling > services to well-known BGP hijackers. > > > Kind regards, > > > Job >
Re: Verizon Network Engineer please
If you haven't received a response, try being more specific. Verizon is 100 asn's and full of all kinds of network engineers. On Fri, Aug 22, 2014 at 3:19 PM, Sena, Rich rs...@mitre.org wrote: Can someone contact me please... -- Richard Sena The MITRE Corporation e: rs...@mitre.orgmailto: rs...@mitre.org Principal Engineer 202 Burlington Road v: +1-781-271-3712 Dept: J86E; MS K319 Bedford, MA 01730-1420 f: +1-781-271-2423
mlb.com Geolocation clue/contact needed
Anyone have a contact at mlb.com that could help resolve an ip geolocation issue? (Networking, db.. or someone who can help find the right folks) Alternatively, anyone know who mlb.com buys geolocation data from? It's related to their baseball game streaming/subscription service. Whitelisting individual users is not a scalable solution. offline answers are welcome too -- Thanks, --Heather
Re: Spoofing ASNs (Re: SNMP DDoS: the vulnerability you might not know you have)
This is the RFC that is being violated: http://tools.ietf.org/html/rfc5625#section-6.2 6.2 http://tools.ietf.org/html/rfc5625#section-6.2. Interface Binding Some gateways have been observed to have their DNS proxy listening on both internal (LAN) and external (WAN) interfaces. In this configuration, it is possible for the proxy to be used to mount reflector attacks as described in [RFC5358 http://tools.ietf.org/html/rfc5358]. The DNS proxy in a gateway SHOULD NOT, by default, be accessible from the WAN interfaces of the device. Implemented correctly, CPE receives DNS request and proxies the request internally. Usually they are only listening on the LAN side. Sometimes they take DNS requests from the WAN side. When a local DNS cache is not defined, these requests can leak out to whatever cache is defined. In some cases, the CPE retains the IP address that originally sourced the packet. So you end up with external caches responding to requests from 3rd parties. Add to that spoofing the original packets to the bad CPE and you have that CPE proxying your DNS amplification attack to other caches. Don't blame the cache. The attacker was intending that the CPE amp directly. Fix: CPE should disable DNS proxying by default and require a restricted list of sources (LAN, vpn, etc) when enabled. Also/alternatively require cache to be local. --Heather On Sun, Aug 11, 2013 at 5:45 AM, Florian Weimer f...@deneb.enyo.de wrote: * Jared Mauch: Number of unique IPs that spoofed a packet to me. (eg: I sent a packet to 1.2.3.4 and 5.6.7.8 responded). That's not necessarily proof of spoofing, isn't it? The system in question might legitimately own IP addresses from very different networks. If the system is a router and the service you're pinging is not correctly implemented and it picks up the IP address of the outgoing interface instead of the source address of the request, that's totally expected. I'm not saying that BCP 38 is widely implement (it's not, unless operators have configured exceptions for ICMP traffic from private address, which I very much doubt). I just think you aren't actually measuring spoofing capabilities.
Re: A bit of historical news
Congrats.. now get on with Global AS and merge all those 70x's together! :) --h On Thu, May 30, 2013 at 11:38 PM, Christopher Morrow christopher.mor...@gmail.com wrote: http://www.cidr-report.org/cgi-bin/as-report?as=AS19262view=2.0 note the list of 'withdrawn' ... err, 19262 is no more? now it's borged into the 701 confed?
Re: Google incorrect IPv6 GeoIP
Forwarded to folks I think should be able to help.. --Heather On Thu, Apr 11, 2013 at 7:13 PM, Yang Yu yang.yu.l...@gmail.com wrote: For some reason Google redirects requests from Dreamhost's IPv6 block 2607:f298::/32 to google.com.hk $ wget http://www.google.com --2013-04-11 16:06:45-- http://www.google.com/ Resolving www.google.com... 2607:f8b0:400c:c01::93, 173.194.75.99, 173.194.75.147, ... Connecting to www.google.com|2607:f8b0:400c:c01::93|:80... connected. HTTP request sent, awaiting response... 302 Found Location: http://www.google.com.hk/url?sa=phl=zh-CNpref=hkredirectpval=yesq=http://www.google.com.hk/ust=1365721636015681usg=AFQjCNEa0yI6UdIVf1tqLtCw3qrBC6Akww [following] --2013-04-11 16:06:46-- http://www.google.com.hk/url?sa=phl=zh-CNpref=hkredirectpval=yesq=http://www.google.com.hk/ust=1365721636015681usg=AFQjCNEa0yI6UdIVf1tqLtCw3qrBC6Akww Resolving www.google.com.hk... 2607:f8b0:400c:c01::6a, 173.194.75.105, 173.194.75.99, ... Connecting to www.google.com.hk|2607:f8b0:400c:c01::6a|:80... connected. HTTP request sent, awaiting response... 302 Found Location: http://www.google.com.hk/ [following] --2013-04-11 16:06:46-- http://www.google.com.hk/ Reusing existing connection to www.google.com.hk:80. HTTP request sent, awaiting response... 200 OK Length: unspecified [text/html] Saving to: “index.html” The report IP problem form (https://support.google.com/websearch/contact/ip?rd=1) does not think IPv6 addresses are valid. Can someone help with this issue? Thanks. Yang
Re: BGP RIB Collection
info on bmpreceiver below.. On Tue, Feb 26, 2013 at 12:24 PM, chip chip.g...@gmail.com wrote: Hello all, I have an application that needs to gather BGP RIB data from the routers that connect to all of our upstream providers. Basically I need to know all the routes available from a particular provider. Currently I'm gathering this data via SNMP. While this works it has its draw backs, it takes approximately 20 minutes per view, its nowhere near real-time, and I'm unable to gather information for IPv6. SNMP, however, is faster than screen scraping. All of the XML based access methods seem to take about the same time as well. I've been watching, with keen interest, the i2rs ietf workings, but the project is still in its infancy. BMP seems to be a good solution but I've not found a working client implementation yet. I see that you can actually configure this on some Juniper gear but I can't seem to locate a client to ingest the data the router produces. https://code.google.com/p/bmpreceiver/ and then it can be dumped where ever you want.. iirc, splunk can parse the data. --Heather The BGP Add Paths implementation seems to be the best choice at the moment and exabgp has a working implementation. Are there any other technologies or methods of accessing this data that I've missed or that you've found useful? Thanks! --chip -- Just my $.02, your mileage may vary, batteries not included, etc
Re: Redundant AS's
Hank Nussbacher wrote: On Fri, 20 Mar 2009, Florian Weimer wrote: * Hank Nussbacher: It takes me about 3-5 hours of work to track down and get an old unused ASN to be deallocated. How about updating the 2010 charging model so that LIRs that return ASNs are compensated? I don't think this is a good way of using RIR funds. Why should the old guys receive even more special treatment? RIPE's charging scheme already discriminates heavily against newcomers. I disagree. Older LIRs have more allocations which compensates for the time factor of the algorithm. Older allocations need almost no human handling by the RIR vs a new LIR of a year which has a oodles of tickets that need human intervention. -Hank I don't think old vs new really matters.. pardon me for sticking w/ ARIN in this example.. I can follow their fee structure easiest - and doesn't have the old vs new: (https://www.arin.net/fees/fee_schedule.html) ARIN charges $100/yr for ASN's ... any compensation for returning an ASN should be less than the $100 they charge? Would it make any financial sense to compensate someone $500 for returning an ASN that only generates $100 a year? (Remember that the RIR's are non-profits..) I tend to agree w/ Randy.. it's time and money better spent focusing our efforts on supporting 4byte ASN (and v6 for that matter) Attempts at recovering 2byte ASN's (and v4 space..) are short term solutions, at best extend the 'free pool' for a short and unpredictable period of time, while incurring more headache, expense, and arguing, than working toward supporting the inevitable. --h
Re: Redundant AS's
Hank Nussbacher wrote: At 08:18 AM 18-03-09 +0100, Henk Uijterwaal wrote: It's a bit dated now, but the RIPE report, ASN MIA, sounds like what you're looking for... www.apnic.net/meetings/21/docs/sigs/routing/routing-pres-uijterwaal-asn-mia.ppt When I look at this more recently, the conclusion still seems to be valid: we'll run out of 16 bit ASN's somewhere in 2011 to 2013. There are a lot of unused ASN's out there. Recovering them will postpone the problem by a few years but it won't solve it. The basic problem with recovery is how to decide if an ASN is really no longer used/needed. There is (still) no mechanism to do this. Henk Why not go after low lying fruit first? If an ASN was assigned years ago and hasn't appeared in the RIB for the past year that ASN should be reclaimed. Send warning emails to the registered contacts as well as to the assigning LIR and after 3 months - just reclaim it. -Hank Your making an assumption that globally unique ASN's must show up in the public internet routing table. The only requirement, at least in the ARIN region, for obtaining a globally unique ASN is a unique routing policy or multihoming - therefor your method could lead to a lot of false positives. I won't even get into issues around bad contact data in whois. However, if enough folks believe this a worthwhile effort, at least in the ARIN region, you will have to ask ARIN to pursue this either through the ARIN policy development process or the ARIN consultation and suggestion process...my guess would be suggestion process. Suggestion submission: https://www.arin.net/app/suggestion/ Policy Proposal process: https://www.arin.net/policy/pdp_appendix_b.html for reference... requirements for obtaining an ASN in the ARIN region: Multi-homed NRPM 5 * provide the exterior gateway protocol to be used * provide the IP addresses currently in use on your network * provide the AS number and name of each of your upstream providers/peers * provide verification (reassigned address block, a copy of your signed contract) your organization has contractually agreed to service with at least two of the upstream providers/peers listed on your request * if requesting an additional AS number, provide documentation detailing how the network for the requested ASN is autonomous from all existing ASes in your network Unique Routing Policy NRPM 5 * demonstrate the AS's routing policy will differ from the routing policies of its border peers * if requesting an additional AS number, provide documentation detailing how the network for the requested ASN is autonomous from all existing ASes in your network --Heather -- Heather Schiller Verizon Business Customer Security 1.800.900.0241 IP Address Management hel...@verizonbusiness.com =
Re: do I need to maintain with RADB?
No. Use of a routing registry is not required.. ARIN's, RADB's or otherwise. You might want to check out this presentation: http://nanog.org/meetings/nanog44/abstracts.php?pt=ODg4Jm5hbm9nNDQ=nm=nanog44 This is an entirely different statement from Your globally unique IP's should to be allocated to you in an RIR's database before someone routes them for you For example 207.76.0.0/14 is allocated to us, you can see it in ARIN's whois, but it is not registered in ARIN's IRRD, or any other. As further proof - note that people publicly route resources that aren't registered in a routing registry database or even registered to them by an RIR at all: http://www.cidr-report.org/as2.0/#Bogons I'm not saying this is a good thing.. I would like to see the system drastically improved and secured.. I'm just pointing out how things actually work today. Check w/ your provider, but in most cases you will find that they don't use a route registry. --Heather Heather SchillerVerizon Business Customer Security1.800.900.0241 IP Address Managementhel...@verizonbusiness.com = Jon Lewis wrote: On Thu, 19 Feb 2009, Zaid Ali wrote: Hi, need some advise here. Do I still need to maintain my objects (and pay) RADB? I use ARIN as source and all my route objects can be verified with a whois. If your objects are all maintained via another routing registry (ARIN's, altdb, etc.) and you don't care to maintain objects with radb.ra.net, then you do not need to pay RADB maintenance fees. -- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: Private use of non-RFC1918 IP space
Stephen Sprunk wrote: Patrick W. Gilmore wrote: Except the RIRs won't give you another /48 when you have only used one trillion IP addresses. Keyword: *Another* Are you sure? According to ARIN staff, current implementation of policy is that all requests are approved since there are no defined criteria that would allow them to deny any. So far, nobody's shown interest in plugging that hole in the policy because it'd be a major step forward if IPv6 were popular enough for anyone to bother wasting it... S I believe Stephen is thinking of initial allocation policy - because a subsequent allocation policy in the ARIN region exists: (and it's been modified atleast once in the last few years) Justification to obtain another netblock is .94 HD-Ratio in the current allocation Endusers (minimum allocation is a /48) For a /48 that's about 72% utilization or 184 /56's assigned/used ISP's (minimum allocation is a /32) For a /32 that's about 37% utilization or 6,183,533 /56's assigned ARIN provides a handy chart: http://www.arin.net/policy/nrpm.html#six7
Re: Private use of non-RFC1918 IP space
Skeeve Stevens wrote: Owned by an ISP? It isn't much different than it is now. As long as you are multi-homed you can get a small allocation (/48), APNIC and ARIN have procedures for this. Yes, you have to pay for it, but the addresses will be yours, unlike the RFC1918 ranges which is akin to 2.4Ghz wireless.. lets just share and hope we never interconnect/overlap. I can't find a RFC1918 equivalent for v6 with the exception of 2001:0DB8::/32# which is the ranges that has been assigned for documentation use and is considered to NEVER be routable. In that /32 are 65536 /48's... way more than the RFC1918 we have now. RFC4193 - Unique Local IPv6 Unicast Addresses http://www.iana.org/assignments/ipv6-address-space FC00::/7 Unique Local Unicast[RFC4193] ..maybe they should have called it RFC1918 for IPv6. FWIW, 2001:0DB8::/32 was allocated by APNIC. Not quite the same as being an RFC/IANA delegated/reserved netblock. --heather Heather Schiller Verizon Business Customer Security 1.800.900.0241 IP Address Management hel...@verizonbusiness.com =
Re: Origin ASN seen vs Origin ASN in Whois Records Report?
Joe Abley wrote: On 23 Nov 2008, at 21:17, Stephen Sprunk wrote: Presumably it's from the Origin AS field in WHOIS: Ah, thanks (and also thanks to others who pointed that out off-list). That seems like a weird anachronism, to be honest. Perhaps it's only because nobody has ever tried to use it for anything that there's never been any reason for the ARIN community to propose that the collection of such information be stopped. Joe The policy is relatively new.. (Spring 2007) and adopted by the ARIN community after vetting at 2 meetings.. It's optional, so I can't imagine why anyone would propose that ARIN stop collecting this information. http://www.arin.net/policy/proposals/2006_3.html It may be that it's newness helps w/ the accuracy.. only time will tell. --heather Heather Schiller Verizon Business Customer Security 1.800.900.0241 IP Address Management [EMAIL PROTECTED] =
Origin ASN seen vs Origin ASN in Whois Records Report?
I don't know if a report like this already exists, but I haven't been able to find one. Can someone (CIDR Report? BGPMon? PCH?) offer a report that shows the discrepencies in Origin ASN according to the whois records, and routes in the [global/public] routing table? Publishing it on some regular interval would be even better. ARIN makes available a list of prefixes with OriginAS. I don't know if other RIR's do. ftp://ftp.arin.net/pub/originAS/ To be clear. I want a list of the prefixes where the actual origin ASN seen does not match the one in the whois record. Inconsistent Origin is fair game here. As a transit provider I'm interested in seeing what prefixes I am transiting for my customers that have this discrepancy, so something that shows the full path as part of the results would be most helpful. Thanks, --Heather -- Heather Schiller Verizon Business Customer Security 1.800.900.0241 IP Address Management [EMAIL PROTECTED] =
Re: Reporting abuse to ISP that goes nowhere
If you forward me your ticket numbers privately, I'll take a look. Despite popular belief, we actually have an active abuse team of good folks who care about abuse issues! --Heather ~*~*~*~*~*~*~*~*~*~*~*~ Heather Schiller Customer Security IP Address Management 1.800.900.0241 ~*~*~*~*~*~*~*~*~*~*~*~ Brandon Galbraith wrote: Apologies for the operational content. =) I've been working with a client who has been the victim of several SQL injection attacks. These attacks are being used to insert links to malicious javascript hosted elsewhere using the following domains: seekcc.com google9.info any-park.cn I've reported the abuse several times to the abuse contact listed by ARIN, but it seems to simply be a blackhole at Verizon Business (their address space). How have others handled this problem? Also, if there is a more appropriate forum for this question and forthcoming discussion, please let me know. Thanks! -brandon
Re: community real-time BGP hijack notification service
Gadi Evron wrote: On Fri, 12 Sep 2008, Skywing wrote: It might be useful to have an option to generate an example alert mail for purposes of setting up necessary mail processing rules and that sort. Just a thought. Good point. Any suggestions from folks here on how they would like it to be built? Could you throw up a page that tells a little about what logic is used, what you check, where you get feeds from and how often, so that people can evaluate the differences between checkmy.net, phas, IRU and MYAsn? --Heather - S -Original Message- From: Gadi Evron [mailto:[EMAIL PROTECTED] Sent: Friday, September 12, 2008 3:13 PM To: Kevin Oberman Cc: [EMAIL PROTECTED] Subject: Re: community real-time BGP hijack notification service On Fri, 12 Sep 2008, Kevin Oberman wrote: Looks interesting, but it only takes a fairly short list of ASNs for a prefix. For our big CIDR blocks, we have WAY too many ASNs to enter them all, so it's pretty useless for me. I need to be able to enter at very least a dozen ASes and I suspect may folks have a LOT more then that. I am sure we can fix that, Thanks for the comment! For now, I'll enter some shorter pieces from the block, but I'm most concerned with the pieces that are not currently assigned, so are available for hijack. I have added the larger, unassigned blocks. I'll start adding assigned bits and pieces as well as unassigned pieces, but being able to put all valid origin ASes in the list for the full blocks would be a lot nicer. Please let us know if you encounter any issues. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED]Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
Re: Out of Date Bogon Prefix
Nick, You might want to take a closer look at who is really bogon filtering you. Emailing their upstream providers may not be the most effective method for getting endsites to update their bogon filters. They don't have to listen to us when we forward your note on. We can't force them to accept traffic from you or update their filters. As someone else pointed out, directly contacting the folks who are filtering you may be time consuming but typically draws the best results. I agree with the other comments that if you are going to use a form letter please provide more details about the IP's you are using and your ASN. Please also pass this on to your colleagues Eric and Kevin, who I've heard from lately :) --Heather ~*~*~*~*~*~*~*~*~*~*~*~ Heather Schiller Customer Security IP Address Management 1.800.900.0241 ~*~*~*~*~*~*~*~*~*~*~*~ Nick Downey wrote: This is an heads-up from the Mediacom Network Operations Center about an issue we are seeing. We were recently given an IP scope from ARIN (American Registry for Internet Numbers) that still exists on older Bogon lists many web providers are currently using. A Bogon prefix is a route that should never appear in the Internet routing table. A packet routed over the public Internet (not including over VPN or other tunnels) should never have a source address in a Bogon range. These are commonly found as the source addresses of DDoS attacks. The IP scope referenced is a 173.x.x.x. This IP scope was on the Bogon list and was blocked by all websites using a Bogon prefix up until February of 2008, when it was released by IANA (Internet Assigned Numbers Authority) for public use and an updated Bogon prefix was provided. Mediacom customers that are within this IP range are not able to reach a website hosted by many organizations. Mediacom is individually requesting that these providers update their Bogon prefix to the most current version to resolve this issue immediately. We are requesting assistance from this community to make this issue known and to advise administrators to update to the most current Bogon list. We have provided some reference material that many may find helpful in resolving this issue. Bogons are defined as Martians (private and reserved addresses defined by http://www.ietf.org/rfc/rfc1918.txt RFC 1918 http://www.faqs.org/rfcs/rfc1918.html http://www.faqs.org/rfcs/rfc1918.html and http://www.ietf.org/rfc/rfc3330.txt RFC 3330 http://www.faqs.org/rfcs/rfc3330.html http://www.faqs.org/rfcs/rfc3330.html) and netblocks that have not been allocated to a regional internet registry (RIR) by the Internet Assigned Numbers Authority http://www.iana.org/ http://www.iana.org/. IANA maintains a convenient IPv4 summary page http://www.iana.org/assignments/ipv4-address-space http://www.iana.org/assignments/ipv4-address-space listing allocated and reserved netblocks. Please help to spread the word. Nick Downey Director Network Operations Center Mediacom Communications Main (800)308-6715 Secondary (515)267-1167 [EMAIL PROTECTED] LEGAL DISCLAIMER This E-mail and any attachments are strictly confidential and intended solely for the addressee. You must not disclose, forward or copy this E-mail or attachments to any third party without the prior consent of the sender or Mediacom Communications Corporation. If you are not the intended addressee please notify the sender by return E-mail and delete this E-mail and its attachments.
Re: Verizon and spam reports
Hank Nussbacher wrote: I have tried repeatedly by private email directly to Verizon and I have contacted an ex-UUnet employee, but so far, it would appear that Verizon is running an unattended and unmaintained spam reporting system with emails like this: For questions about these reports please email: [EMAIL PROTECTED] NOTE: there is no need to acknowledge these reports, the email address: [EMAIL PROTECTED] is purely for questions. Some frequently asked questions about this process and its fallout can be found here: http://www.secsup.org/complaints/ The following spam message was received at Thu, 05 Jun 2008 17:03:01 +0300 IP: x.x.1.242 TIMESTAMP: Thu, 05 Jun 2008 17:03:01 +0300 GMT- Problem is they are basing who to send the spam report on an email address that was changed in whois about 2 years ago and it would appear no one is home to update their spam reporting database. Is anyone here from Verizon who can reach out to the people sending these emails to have them fix their database? Thanks, Hank Yes.. Send me your details (IP/ASN/ORG ID) and I'll have someone update the db. --Heather -- ~*~*~*~*~*~*~*~*~*~*~*~ Heather Schiller Customer Security IP Address Management 1.800.900.0241 ~*~*~*~*~*~*~*~*~*~*~*~
Re: IPV6 network feeds
Joe Abley wrote: On 27 May 2008, at 17:45, [EMAIL PROTECTED] wrote: Verizon provides ipv6 connectivity according to their website. I mentioned this on another list, but if anybody has tried to actually turn the words referred to above into service, I would be very happy to hear about how they did it. If Verizon = AS701/702/703 (VerizonBusiness/UUnet/MCI) then you should be able to just call your sales person and ask for it.. We can do native in several locations, and if native isn't available in your location, we can set you up w/ a tunnel and move you over to native when it becomes available. **Any current Verizon Business (fUUnet/MCI) customer can call and ask for IPv6 connectivity. There is no additional charge for turning up IPv6 on your existing connection** If Verizon = AS19262 you'll have to wait a bit longer.. snip that stuff about ATT There seems to be a certain trend towards claiming IPv6 capability in order to win business, hoping that people are just looking for the check in the box and not actual exchange of packets.
Re: IPV6 network feeds
Antonio Querubin wrote: On Mon, 2 Jun 2008, Heather Schiller wrote: If Verizon = AS701/702/703 (VerizonBusiness/UUnet/MCI) then you should be able to just call your sales person and ask for it.. We can do native in several locations, and if native isn't available in your location, we can set you up w/ a tunnel and move you over to native when it becomes available. **Any current Verizon Business (fUUnet/MCI) customer can call and ask for IPv6 connectivity. There is no additional charge for turning up IPv6 on your existing connection** Does that also include connections through resellers? In our case, that's WBS Connect. I asked them about this last year and was told that their contact at Verizon Business had told them IPv6 wasn't available. Has that changed? Antonio Querubin whois: AQ7-ARIN Yes, it includes connections through resellers. Your reseller, in this case, WBS, has to request it and sign the consent form on your behalf. There is no technical limitation to providing the service. --Heather -- ~*~*~*~*~*~*~*~*~*~*~*~ Heather Schiller Customer Security IP Address Management 1.800.900.0241 ~*~*~*~*~*~*~*~*~*~*~*~
Re: [NANOG] Multihoming for small frys?
William Herrin wrote: Hi folks, An administrative question about multihoming: I have a client who needs to multihome with multiple vendors for reliability purposes, currently in the Northern Virginia area and later on with a fail-over site, probably in Hawaii. They have only a very modest need for bandwidth and addresses (think: T1's and a few dozen servers) but they have to have BGP multihoming and can afford to pay for it. The last I heard, the way to make this happen was: Find a service provider with IP blocks available in ARIN's set of /8's that permit /24 announcements (networks 199, 204-207), buy a circuit and request a /24 for multihoming. Then buy circuits from other providers using that ISP's /24 and an AS# from ARIN. Yes, but the order is wrong.. - Order service from 2 providers - Request an ASN from ARIN, show them your documentation that you are getting service from 2 providers to justify your need for an ASN - If you don't meet the utilization requirements for getting a /24, request a /24 for multihoming under ARIN 4.2.3.6. from ONE of your providers (not both). At UUnet/VZB we ask customers to provide their ASN as documentation that they have demonstrated their intent to multihome. If you have existing IP space, and it's less than /24 don't be surprised if someone asks you to renumber. If you have existing IP space /24 or larger, don't be surprised if someone turns you down under the multihoming policy. http://www.arin.net/policy/nrpm.html#four236 4.2.3.6. Reassignments to multihomed downstream customers Under normal circumstances an ISP is required to determine the prefix size of their reassignment to a downstream customer according to the guidelines set forth in RFC 2050. Specifically, a downstream customer justifies their reassignment by demonstrating they have an immediate requirement for 25% of the IP addresses being assigned, and that they have a plan to utilize 50% of their assignment within one year of its receipt. This policy allows a downstream customer's multihoming requirement to serve as justification for a /24 reassignment from their upstream ISP, regardless of host requirements. Downstream customers must provide contact information for all of their upstream providers to the ISP from whom they are requesting a /24. The ISP will then verify the customer's multihoming requirement and may assign the customer a /24, based on this policy. Customers may receive a /24 from only one of their upstream providers under this policy without providing additional justification. ISPs may demonstrate they have made an assignment to a downstream customer under this policy by supplying ARIN with the information they collected from the customer, as described above, or by identifying the AS number of the customer. This information may be requested by ARIN staff when reviewing an ISP's utilization during their request for additional IP addresses space. Is that still the way to make it happen? Are there alternate approaches (besides DNS games) that I should consider? Who should I talk to? Certain well-known companies seem incapable of discussing service that isn't cookie-cutter. It's really pretty straightforward and common actually... but I wouldn't be surprised if sales folks don't know ARIN and/or routing policy. Thanks, Bill Herrin -- ~*~*~*~*~*~*~*~*~*~*~*~ Heather Schiller Customer Security IP Address Management 1.800.900.0241 ~*~*~*~*~*~*~*~*~*~*~*~
