Re: Transition Planning for IPv6 as mandated by the US Govt
No, and no. Shouldn't be a surprise. (all is the dealbreaker, certain agencies are on the ball, but most are barely experimenting). On Sat, 15 Mar 2008, Glen Kent wrote: : :Hi, : :I was just reading :http://www.whitehouse.gov/omb/egov/b-1-information.html#IPV6, released :some time back in 2005, and it seems that the US Govt. had set the :target date of 30th June 2008 for all federal govt agencies to move :their network backbones to IPv6. This deadline is almost here. Are we :any close for this transition? : :I have another related question: : :Do all ISPs atleast support tunneling the IPv6 pkts to some end point? :For example, is there a way for an IPv6 enthusiast to send his IPv6 :packet from his laptop to a remote IPv6 server in the current :circumstances if his ISP does not actively support native IPv6? : :Cheers, :Glen :
Re: How Not to Multihome
On Mon, 8 Oct 2007, Patrick W. Gilmore wrote: :To be clear, I am not suggesting de-aggregating every CIDR down to / :24s. But the global table doesn't grow any more whether the customer :announces the /24 from their own ASN, or if you muti-originate it :from two upstreams - or just one upstream for that matter. So there :is no legitimate reason to _not_ announce it, but there is a reason :to announce it. Bingo. And, I'd hazard to guess that many readers of this thread have broken more than a single unwritten rule. I recall being chastised relentlessly years back for doing ibgp over a gre tunnel as I saved up for a real trunk. Guess what - it worked wonders in the short term (though I'll admit I'm embarrassed to rehash it). Bottom line (getting back to the original question) is yes, it's ok, so long as you handle due diligence with the owner of the cidr space. RFC, no, courtesy among peers, yup. cheers, brian
Re: Using Mobile Phone email addys for monitoring
: Some mobile phones you can talk to via AT commandset, either :via USB cable or something else. (eg: I have used a Nokia 6230 with usb :cable.. you can also use bluetooth). If you pay $5 or whatnot for unlimited :SMS on a el-cheapo plan, it might work better than using the SMTP gateway :(when tied to Nagios, etc..) as you can send SMS messages with the AT :commandset. : :Assuming, for the moment, that there's a cell signal available in :your data center... Not always the case, unfortunately. I recall a datacenter in BOS that went so far as to nearly eliminate RF using corrugated aluminum inside the walls (you know who you are :) The simple answer is that it depends on how critical such notifications are. Address it as you would your upstream connectivity, and make it as redunant as is justified. For my meager purposes, smtp is usually fine. For truly critical issues, my nms will use a dedicated phone line to dial a handful of on-call techs, with no more info than caller-id. If that id shows up on their phones, immediate investigation is needed. It's embarrassingly primitive, but it's never failed. Cheers, Brian
Re: what the heck do i do now?
On Wed, 31 Jan 2007, Barry Shein wrote: :One problem we have is that we tend to see the internet as a perfect :simulation of a fair and just system, at least as a first goal. : :I don't know if that's possible or not. I don't know if anyone has :actually explored the issue deeply. One problem is that there are many :different notions of justice present globally. Probably thousands with :significant real-world referents. : : Ultimately, the problem is that the idealism which was more or less the rule a decade ago has taken a backseat to commercialism and what some see as practicality; and arguably, some consider such a reasonable excuse for lax maintenance (to the tune of if it's not hurting me/my customers, it's not a priority). Considering the time passed since maps went defunct, Paul is entirely justified in doing whatever is necessary to cluebat the offending networks, imho.
Re: Undersea fiber cut after Taiwan earthquake - PCCW / Singtel / KT e tc connectivity disrupted
That's news? The same still happens with much land-based sonet, where diverse paths still share the same entrance to a given facility. Unless each end can negotiate cost sharing for diverse paths, or unless the owner of the fiber can cost justify the same, chances are you're not going to see the ideal. Money will always speak louder than idealism. Undersea paths complicate this even further. On Sun, 21 Jan 2007, Rod Beck wrote: :What's really interesing is the fragility of the existing telecom infrastructure. These six cables were apparently very close to each other in the water. In other words, despite all the preaching about physical diversity, it was ignored in practice. Indeed, undersea cables very often use the same conduits for terrestrial backhaul since it is the most cost effective solution. However, that means that diversifying across undersea cables does not buy the sort of physical diversity that is anticipated. : :Roderick S. Beck :EMEA and North American Sales :Hibernia Atlantic
Re: Geo location to IP mapping
cough scam_snake_oil_etc /cough On Mon, 15 May 2006, Alain Hebert wrote: : :GeoIP - http://www.maxmind.com/geoip/ : :Ashe Canvar wrote: : : : Hi all, : : Can any of you please recommend some IP-to-geo mapping database / web : service ? : : I would like to get resolution down to city if possible. : : Thanks and Regards,
Re: Geo location to IP mapping
I'm not quite comfortable with the idea of building a market audience based on data with at best dubious accuracy. On Mon, 15 May 2006, Martin Hannigan wrote: :At 12:49 PM 5/15/2006, Brian Wallingford wrote: : :cough scam_snake_oil_etc /cough : : :How so?
Re: Welcome back, Ma Bell
Not that mind-boggling. The FCC under the Bush administration has been a joke from the get-go. (This coming from a very right-leaning independent). This is the ultimate shell game, considering ATT's antics last year. cheers, brian On Sun, 5 Mar 2006, Fergie wrote: : :Reuters and CNN/Money also reporting same: : : http://money.cnn.com/2006/03/05/news/companies/att_bellsouth/index.htm : :Mind-boggling. : :- ferg : : : :-- Suresh Ramasubramanian [EMAIL PROTECTED] wrote: : :This is from Dave Farber's list .. : : Subject: Everything old is new again : From: Kevin G. Barkes : : NEWS ALERT : from The Wall Street Journal : : ATT is planning to acquire BellSouth for roughly $65 billion. A : deal between the two could be announced as early as Monday. : :I somehow wonder if the old executives at Ma Bell had already worked :out a timeline for resurrecting her well before she was split up .. : :--srs :-- :Suresh Ramasubramanian ([EMAIL PROTECTED]) : : :-- :Fergie, a.k.a. Paul Ferguson : Engineering Architecture for the Internet : [EMAIL PROTECTED] or [EMAIL PROTECTED] : ferg's tech blog: http://fergdawg.blogspot.com/ : : : -- ___ Brian Wallingford Director, Network Operations MegaNet Communications, TCIX, Inc. ~~~
Re: Okay, I'm just going to _assume_...
It's official - pigs are aloft, the forecast for Hell is freezing rain, the Sox have nearly broken the Curse (and will... :), and Cisco has taken over Looney Tunes. The end is near. No, no operational content... Did John Chambers have an aneurysm recently? On Thu, 21 Oct 2004, Bill Woodcock wrote: : :...that there's some operational content somewhere in here: : :http://www.cisco.com/edu/peterpacket/ : :...though I'm on kind of a slow link, so I'm still looking. My eternal :thanks to Suresh for finding this. My day is complete. : :-Bill
Re: FW: The worst abuse e-mail ever, sverige.net
:Let's put this in perspective. Say a hypothetical sysadmin were to :disable any and all authentication on his SSH server. And that :someone then used SSH from your network to run code that sysadmin :didn't like on that machine. Would you then consider it reasonable if :the sysadmin proposed: : : The only responsible thing to do is filter port 22, smarthost for : your users, and inform them about using the alternate submission : port with authenticated SSH in order to work with enterprise SSH : servers - or IPSec VPNs, for that matter. This is simply the best : practice, at this point in time. : Apples oranges; thanks for playing, please try again...
Lucent/Ascend/Cascade B-STDX images
I've exhausted all my resources, and have not found a definitive method for upgrading a production switch from cp40 to cp50. Is it as simple as hot-swapping the standby, ignoring the capability mismatch, changing the active cp, then doing the same for the master cp? Also, curious if the images for these blades are interchangeable. Any input would be most appreciated. cheers, brian
Re: Hurricane Frances impacts
:The networks in Broward, Palm Beach, Martin, Brevard counties appear to :be the most impacted. Cellular had problems due to wireless sites being :without power. The wireless industry brought in 500 new generators in :advance of the hurricane, but needed to wait until the hurricane passed :before sending them out to the cell sites. Miami and Orlando also have :sites down due to power issues and connectivity to local carriers. : :The various local access line providers in Florida, Florida has a lot of :tiny LATAs and phone companies, report some access lines are down but :haven't published any counts. Cable networks have the same issues with :local cable service. No reports of damage to telephone central offices or :cable headends. : :Due to power outages and local access network problems, bank networks and :cash machines are out of service in most of the affected counties. : :No reports of problems to any NAPs, POPs, data centers or fiber trunks. :They generally have permanent generators. So if you have local :connectivity, Internet access is working. Streaming audio/video from :Florida television and radio stations over the Internet did not have any :problems. Any details on the status of natural gas lines in FL, and approximately how many facilities use such for generator power vs diesel?
RE: (UPDATE) Can a Customer take their IP's with them? (Court says yes!)
On Tue, 29 Jun 2004, David Schwartz wrote: : : : What I AM looking for is a commentary from the internet community, : strictly relating to the fact that a judge has issued a TRO that forces an : ISP (NAC) to allow a third-party, who WILL NOT be a Customer of NAC, to be : able to use IP Space allocated to NAC. In other words, I am asking people : to if they agree with my position, lawsuit or not, that non-portable IP's : should not be portable between parties, especially by a state superior : court ordered TRO. : : It is at least my opinion that this is a ludicrous argument. While this :would certainly cause problems if everyone did it and it isn't the norm, :it's ridiculous to argue that there could never exist a situation where this :might not be the best temporary solution to a legitimate dispute between :parties. : : Consider, for example, if I'm a large customer single-homed to one ISP. :They go out of business and can't continue to provide me with service with :four hours notice. Consider Randy's ealier recollection, which many should also recall. In the context of the currently publicly available documents, any further discussion is less than operationally relevant. cheers, brian
Interesting BIND error
We've been seeing the following on all of our (9.2.1) authoritative nameservers since approximately 10am today. Googling has turned up nothing; I'm currently trying to glean some useful netflow data. Just wondering if this is local, or if others have suddenly seen the same. Seems harmless enough, but the logging is eating a disproportionate amount of cpu. Feb 12 16:25:07 ns1 named[3150]: internal_send: 244.254.254.254#53: Invalid argument Feb 12 16:25:07 ns1 named[3150]: socket.c:1100: unexpected error: Feb 12 16:25:07 ns1 named[3150]: internal_send: 244.254.254.254#53: Invalid argument Feb 12 16:25:07 ns1 named[3150]: socket.c:1100: unexpected error: Feb 12 16:25:07 ns1 named[3150]: internal_send: 244.254.254.254#53: Invalid argument Feb 12 16:25:07 ns1 named[3150]: socket.c:1100: unexpected error: Feb 12 16:25:07 ns1 named[3150]: internal_send: 244.254.254.254#53: Invalid argument From socket.c: #undef ALWAYS_HARD /* * The other error types depend on whether or not the * socket is UDP or TCP. If it is UDP, some errors * that we expect to be fatal under TCP are merely * annoying, and are really soft errors. * * However, these soft errors are still returned as * a status. */ isc_sockaddr_format(dev-address, addrbuf, sizeof(addrbuf)); isc__strerror(send_errno, strbuf, sizeof(strbuf)); UNEXPECTED_ERROR(__FILE__, __LINE__, internal_send: %s: %s, addrbuf, strbuf); dev-result = isc__errno2result(send_errno); return (DOIO_HARD);
Re: Verizon mail troubles
:But they've never had a sonet outage once in our entire time of doing :business with them. So they do employ competent people. Plenty of them. :But they aren't concerned with IP or SMTP. Absolutely. Without delving into regulatory details, prior to the initiation of VADI (possibly the most egregious misnomer in history) and again now since VADI has been decomissioned, we're quite happy with their competence at layers 1 2. There's no question that there's a certain amount of social engineering involved in contacting (or being allowed to contact) competent folk. It's advisable to be sure that any staff who will be contacting them are fully versed in any services they will be discussing. The clueful staff at VZ are much more receptive and accessible when they know in advance that they can expect to pick up a likewise-clued individual. cheers, brian
Re: Any 1U - 2U Ethernet switches that can handle 4K VLANs?
On Sun, 25 Jan 2004, Alexei Roudnev wrote: : :L3 switchiong is just term for idiots - it is ROUTING in old terms. So, :VLAN's means _routing_. Um, no, VLAN does not infer routing. 802.1q and even Cisco's ugly proprietary ISL both operate at layer two. As to L3 switching and the spin involved in such, it's an old, predictable story, which we all wrote off as marketing drivel at least a couple years ago...
RE: AOL fixing Microsoft default settings
On Fri, 24 Oct 2003, Terry Baranski wrote: :The without notice part is perhaps somewhat unsettling. I can :appreciate that attempting to explain this type of change to the AOL :user base would be challenging, but I'd submit that third-party software :making OS changes like this without the user's knowledge could be thin :ice territory. Where is the line drawn once this path is chosen? Seems this would be suitable for inclusion in the license agreement to which most check I agree without reading. If it hasn't been, it could certainly fall into the thin ice category, given the multitude of legal eaglets willing to push for class-actions. In any event, this begs a policy discussion more than an operational one.
TNT issues workaround
I haven't seen specific details posted here, so: Like many others, we've had a few TNTs online for years without hiccups or reboots until this week. Beginning late Sunday, we saw seemingly random blade reboots, and total system crashes. Errors ranged from memory leaks to infinite loops on the controller blade, but all blades were susceptible. HDLC2 blades seemed to be particularly vulnerable. We saw boxes that had been rock-solid for very long periods suddenly rebooting at periods ranging from 20 minutes to 4 hours, with no obvious cause (i.e., nothing more specific than the above). Border and core filtering of icmp echo * did little good. On the suggestion of some folks on another list, and against my better judgment, we disabled route caching in order to free up additional memory (though memory did not appear fragmented). This stabilized all involved boxes, and surprisingly, did not result in significant degradation of end user performance. Granted, it's not a true fix, but it may get you a few extra Z's at night. hth, brian
Re: Cisco IOS Vulnerability
On Thu, 17 Jul 2003 [EMAIL PROTECTED] wrote: :should be obtained through the Software Center on the Cisco worldwide website :at http://www.cisco.com/tacpage/sw-center/sw-ios.html I'm getting a 404 not found for that URL, while logged into CCO.
Re: Looking for advice on datacenter electrical/generator
On Fri, 4 Apr 2003, David Lesher wrote: : A) Piped natural gas is highly reliable here in the East. I've : not had ^ in 10+ years. : an outage Agreed; same here, though in the northeast, we do lie on what's considered a fairly significant fault line. Of course, should such come into play, geographical diversity of critical services would likely be of more importance. I'd suspect a quake in the northeast would have similar operational impact to a blizzard in SJ :) cheers, brian
Re: What could have been done differently?
On Tue, 28 Jan 2003, Steven M. Bellovin wrote: :They do have a lousy track record. I'm convinced, though, that :they're sincere about wanting to improve, and they're really trying :very hard. In fact, I hope that some other vendors follow their :lead. My big worry isn't the micro-issues like buffer overflows :-- it's the meta-issue of an overall too-complex architecture. I :don't think they have a handle on that yet. Excellent point. I have been saying this since the dawn of Windows 3.x. Obviously, software engineering for such a large project as an(y) OS needs to be distributed. MS has long been remiss in facilitating (mandating?) coordination between project teams pre-market. You're absolutely correct that complexity is now the issue, and it could have been mitigated early on. (Who knows what? Is who still employed? If not, where are who's notes? Who knows if who shared his notes with what?, Who's on third?...) Now, it's going to cost loads of $$ to get everyone on the same page (or chapter), if that's even in the cards. For MS, it's a game of picking the right fiscal/social/political tradeoff. It's extremely complex now, as the project has taken on a life of its own. Someone let the suits take control early on, and we all know the rest of the story. Any further discussion will likely be nothing more than educated conjecture (as was the above). cheers, brian
Re: clear blue sf with out power
Over a day of downtime due to a short? Whose side is the short on - PGE's or Navisite's? There's no excuse for a delay this long, on either end. Of course, all info regarding this outage has been second-hand, so I'll reserve judgment. I'd have expected some level of local news coverage if PGE was at fault, though. On Mon, 20 Jan 2003, John Kinsella wrote: : :From what Internap has told me, power went out at Navisite (I'm getting :tired of name changes) at 10:15 on 1/19 due to PGE de-energizing the grid :that feeds the DC due to a short. No ETA on when the grid will be back. : :John : :Scott Granados said: : : Anyone know what's up with Clearblue in SF, 650 Townsend St. : : I've been getting alerts that they have been with out power now for a : couple days and are still on generator power.
RE: Arin Smack down?
On Thu, 21 Nov 2002, Martin Renschler (EWU) wrote: : :tried the link and entered my PacBell home DSL static IP address and was shocked to :see my private name come up behind CustName field! Wrong Address though. : :Isn't this violating privacy rules? Geez! :/Martin :(private mail not representing my employer's opinion...) How else would one prove utilization levels to ARIN when in need of additional cidr space? And... what privacy rules? I've yet to see a privacy policy published that indicates a firm will not share with it's affiliates/parthers information necessary for providing service.
Re: VeriSign Moves DNS Server To Boost Security
On Fri, 8 Nov 2002, David Diaz wrote: : :Would that be in front of, or behind Big Red (firewall)? : :Seriously...would their policies affect the integrity of the root :zone server files? Rhetorical question? :) Obviously, such a move would be unrealistic if subjective filtering could affect the viability of J. I'm sure the powers that be in that region would understand that. I'm partial to Randy's thoughts regarding trust; though, Hong Kong would seem, for many (albeit political) reasons to be a better/simpler choice. IMHO, of course. : :At 15:43 -0800 11/8/02, Randy Bush wrote: : The real question isn't why J has moved a few miles to a different : Verisign building, but where in the world should J move? : :i have been pushing bejing for a few years. except it would be :nice to have built some operational understanding and trust with :those folk first, perhaps by asking them to secondary arpa for a :while. : :randy
RE: ATT NYC
On Thu, 29 Aug 2002, NAIDOO Kesva FTLD/IAP wrote: : :Has anybody mentioned the benefits of ISIS as an IGP to them. : Of course, ISIS is no more resilient against the deletion of igp configuration than OSPF. cheers, brian
RE: PSINet/Cogent Latency
Good for you, Phil. Chime in again when you've got something useful to offer. In the meantime, you may want to review Economics 101 along with certain queueing schemes, especially RED (no, I'm not endorsing the idea of oversubscribing to the extreme, but then again, neither was Alex). Also, re-read the previous post. There's a big difference between choice and facility. Did you grow up spending Summers in the Hamptons with no conception of the value of a dollar, or are you simply trolling? -brian On Mon, 22 Jul 2002, Phil Rosenthal wrote: : :Actually, I wouldn't think about getting T1, DS3 or OC3 in the first :place ;) :Oc-12 is the minimum link I would even look at -- and my preference is :gig-e... Even if there is only 90 megs on the interface... : :--Phil : :-Original Message- :From: Alex Rubenstein [mailto:[EMAIL PROTECTED]] :Sent: Monday, July 22, 2002 10:02 PM :To: Phil Rosenthal :Cc: [EMAIL PROTECTED] :Subject: RE: PSINet/Cogent Latency : : : : :On Mon, 22 Jul 2002, Phil Rosenthal wrote: : : : I call any upstream link 'over capacity' if either: : 1) There is less than 50mb/s unused : :That must work well for T1's and DS3's. : : : 2) The circuit is more than 50% in use : :I call it 'over capacity' too, but that doesn't mean all the ducks are :in a row to get both sides to realise an upgrade is needed, and even if :they do realise it, to actually get it done. I am sure 2238092 people on :this list can complain of the same problem. : :So, what do you do? You monitor it's usage, making adjustments to make :sure it doesn't get clobbered. You can easily run DS-3s at 35 to 40 :mbit/sec, with little to none increase in latency from the norm. Many :people do this as well, even up to OC12 or higher levels all the time. : : : : : I guess by my definition a DS3 is always 'over capacity' : :Which must work very well for those DS3's doing 10 to 20 mb/s. Do you :upgrade those to OC3 or beyond? : : :-- Alex Rubenstein, AR97, K2AHR, [EMAIL PROTECTED], latency, Al Reuben -- :--Net Access Corporation, 800-NET-ME-36, http://www.nac.net -- : : : :
RE: PSINet/Cogent Latency
On Mon, 22 Jul 2002, Phil Rosenthal wrote: : :With the price of transit where it is today: :#1 Transit is often cheaper than peering (if you factor in port costs on :public exchanges, or link costs for private exchanges) :#2 The difference in price is likely not large enough for me to risk: :saturation, latency, etc... : :My customers pay me to provide them a premium service, and I see value :in providing that service. : :Some people have no problem selling cogent -- what can I say... You get :what you pay for... : :And no, I'm not trolling. Is having a different opinion not allowed :now? :And 40mbit over a 45mbit circuit, if it is to an uplink/peer -- well, if :he has customers who are connected at 100mbit switched uncapped (likely) :-- then many customers (possibly even some DSL customers...) can flood :off his peer links with only a 5mbit stream. Much better. Your prior posts lacked context and continuity. I've always advocated overprovisioning myself, vs. creative buffering, queuing, and/or distracting the end user. The statement I wouldn't think of getting T1, DS3 or OC3 in the fist place, without context, easily lends itself to misinterpretation. cheers, brian : :--Phil : :-Original Message- :From: Brian Wallingford [mailto:[EMAIL PROTECTED]] :Sent: Monday, July 22, 2002 11:13 PM :To: Phil Rosenthal :Cc: 'Alex Rubenstein'; [EMAIL PROTECTED] :Subject: RE: PSINet/Cogent Latency : : :Good for you, Phil. Chime in again when you've got something useful to :offer. : :In the meantime, you may want to review Economics 101 along with certain :queueing schemes, especially RED (no, I'm not endorsing the idea of :oversubscribing to the extreme, but then again, neither was Alex). : :Also, re-read the previous post. There's a big difference between :choice and facility. : :Did you grow up spending Summers in the Hamptons with no conception of :the value of a dollar, or are you simply trolling? : :-brian : : :On Mon, 22 Jul 2002, Phil Rosenthal wrote: : :: ::Actually, I wouldn't think about getting T1, DS3 or OC3 in the first ::place ;) :Oc-12 is the minimum link I would even look at -- and my :preference is :gig-e... Even if there is only 90 megs on the :interface... :: ::--Phil :: ::-Original Message- ::From: Alex Rubenstein [mailto:[EMAIL PROTECTED]] ::Sent: Monday, July 22, 2002 10:02 PM ::To: Phil Rosenthal ::Cc: [EMAIL PROTECTED] ::Subject: RE: PSINet/Cogent Latency :: :: :: :: ::On Mon, 22 Jul 2002, Phil Rosenthal wrote: :: :: :: I call any upstream link 'over capacity' if either: :: 1) There is less than 50mb/s unused :: ::That must work well for T1's and DS3's. :: :: :: 2) The circuit is more than 50% in use :: ::I call it 'over capacity' too, but that doesn't mean all the ducks are ::in a row to get both sides to realise an upgrade is needed, and even if ::they do realise it, to actually get it done. I am sure 2238092 people :on :this list can complain of the same problem. :: ::So, what do you do? You monitor it's usage, making adjustments to make ::sure it doesn't get clobbered. You can easily run DS-3s at 35 to 40 ::mbit/sec, with little to none increase in latency from the norm. Many ::people do this as well, even up to OC12 or higher levels all the time. :: :: :: :: :: I guess by my definition a DS3 is always 'over capacity' :: ::Which must work very well for those DS3's doing 10 to 20 mb/s. Do you ::upgrade those to OC3 or beyond? :: :: ::-- Alex Rubenstein, AR97, K2AHR, [EMAIL PROTECTED], latency, Al Reuben -- ::--Net Access Corporation, 800-NET-ME-36, http://www.nac.net -- :: :: :: :: : : :
Re: Name Server Change-over completed
:I guess the moon is in phase with some star somewhere, and now it's time to :argue who's root is he real root... Barf. Enough already - we all have :our own roots. one guy follows Vixies roots, while I typically roll my :own. Many others do other things. The moon was full last tuesday - I'm normally prepared for the kooks that come out of the woodwork on such days, but you've successfully foiled me on that end with your delay. :The final point of this insanity is that there is NOT a single root. Hasn't :been for a hell of a long time, and I suspect that there never will be :again. By definition, there can be only one root, dns or otherwise. Of course, there are alternate roots to which folks like yourself subscribe - have fun. The inherent/obvious problem is that only folks as misguided as yourself will (ahem) benefit from the use of your root zone. That rather limits the reachability of sites subscribing to your ideals, no? As somebody who's fairly well-versed wrt dns asked earlier, got an rfc#? : Its no joke. : : The only joke here is your lack of knowledge concerning basic networking : concepts like DNS. : :I sayth to you, the parties in interest: Deal with it. It aint gonna :change. Everybody's dealing. Kudos for the comic relief. :The views expressed here are mine, and NOT those of my employers, :associates, or others. Besides, if it *were* the opinion of all of :those people, I doubt there would be a problem to bitch about in the :first place... : Wow - someone employs you? Say Hi to Jim Fleming for me. Apologies to all for the troll reply. cheers, brian
Perspective on ARIN allocations to non-American entities
I've searched the IANA and ICANN sites, and have found no justification for what appear to be ARIN allocations to foreign entities within 66.231. Two serious UCE/hacking attempt offenders are as follows: 66.231.64.0/20 GIGA-BLK-1 66.231.128.0/20 ECON-BLK-1 Both of which appear to be completely unapologetic for their users' activities and refuse to take any action against repeat offenders (10's of thousands of attempts per week here). Why have these blocks apparently been allocated via ARIN? Am I missing something? Cheers, Brian
Re: Perspective on ARIN allocations to non-American entities
:I've searched the IANA and ICANN sites, and have found no justification :for what appear to be ARIN allocations to foreign entities within :66.231. : :Two serious UCE/hacking attempt offenders are as follows: :66.231.64.0/20 GIGA-BLK-1 : : Last I checked, Columbia was part of South America. The 'A' in Arin means :America, the two continents. Granted, that was a poor example. :66.231.128.0/20 ECON-BLK-1 Last I checked, France wasn't in either of the Americas. : :Both of which appear to be completely unapologetic for their users' :activities and refuse to take any action against repeat offenders :(10's of thousands of attempts per week here). Why have these blocks :apparently been allocated via ARIN? : :Am I missing something? : : I'm not sure what you think ARIN has to do with UCE/hacking. ARIN allocates :IP addresses. The regional splitting of the registries is more for reasons of :convenience than anything else and I don't believe there's any special reason :ARIN should deny a request just because the addressees will be using the :block out-of-the region. (Though it is recommended that you use the registry :for your region.) Understood, and I certainly wouldn't expect that any given registry would presume to play policeman for the networks they've allocated. My only point was that one should be able to assume, based on network number, that a given prefix can be looked up via a given registry's database, and that the result should reflect an organization (or a branch of an organization) within that registry's region. : It is common for companies with a presence in multiple regions to deal with :a single regional registry and then use the blocks where they actually need :them. This is much better than them using two for a variety of reasons :including that it makes the registry better able to assess the justification. :So a multinational company might request all the blocks it needs through ARIN :and it's U.S. office. Again, understood. NTT/Verio, among others, is a good example of such. In such a case, the ARIN record should reflect the physical address, and other contact info for the given U.S. office, IMHO, not the foreign address, for what I would think are obvious reasons. Cheers, Brian
