October 2001 - Test - lists.nanog.org

FWD: RE: FW: Getting hacked by Digital Isle?
by Christopher Wolff 26 Oct '01

26 Oct '01

Here is the official Digital Isle party line. The part that I like is "3) Respond to this message requesting we stop pinging your server. In this event our pinging will cease in several days." Several days? I'm wondering if I can send a bill to Digital Isle for beta testing their product on my time and bandwidth without even asking me. Regards, Christopher ---------- Original Message ---------------------------------- From: Sean Gleason <sgleason(a)digisle.net> Date: Fri, 26 Oct 2001 01:02:21 +0000 (GMT) Chris, We apologize for any inconvenience caused by pings (ICMP_ECHO packets) coming from our machines. Your server was being pinged as part of our real-time "network weather" mapping system called Best Distributor Selection. BDS is an essential part of Footprint, Digital Island's intelligent network service offering. It is used to optimize performance when your customers access the web resources of our customers. Many large web publishers, such as AOL, CNBC and Blue Mountain, use our Footprint service to speed up the delivery of their web content. Our system intelligently matches browsers to the servers on our Footprint network that will provide the best performance. The dynamic nature of routing and congestion on the Internet make it necessary for us to constantly update our maps. Our network was pinging your system because it appeared to be a name server with a sufficient number of resolution requests for our customer web sites to be placed on the list of network nodes to be constantly observed for Internet congestion. By pinging your name server, we can provide better quality of service to your users when they access the web sites of our expanding customer list. We hope you will consider granting us permission to continue pinging a name server in your domain. Sandpiper Networks merged with Digital Island in December 1999, which is why some of the machines pinging you were in digisle.net. At this point you can: 1) Do nothing. Please accept our apologies and be assured that your machines are not being pinged by a hostile party. 2) Tell us if there is an alternate name server in your IP address space that you would like us to ping. We will direct future ping traffic to it. 3) Respond to this message requesting we stop pinging your server. In this event our pinging will cease in several days. Regards, Sean Gleason Digital Island, Inc. On Thu, 25 Oct 2001, Christopher J. Wolff wrote: > Hello, thank you for your response. Here are the source addresses. > > > IDS246/dos_dos-large-icmp ICMP 167.216.210.50:na 64.212.9.100:na > ns1.bblabs.net 17:30 10-25 > IDS246/dos_dos-large-icmp ICMP 198.30.3.4:na 64.212.9.100:na > ns1.bblabs.net 17:29 10-25 > IDS246/dos_dos-large-icmp ICMP 24.30.1.7:na 64.212.9.100:na > ns1.bblabs.net 17:27 10-25 > IDS246/dos_dos-large-icmp ICMP 212.177.57.41:na 64.212.9.100:na > ns1.bblabs.net 17:27 10-25 > IDS118/scan_Traceroute ICMP ICMP 216.200.14.119:na 64.212.9.100:na > ns1.bblabs.net 17:27 10-25 > IDS118/scan_Traceroute ICMP ICMP 216.32.118.78:na 64.212.9.100:na > ns1.bblabs.net 17:27 10-25 > IDS118/scan_Traceroute ICMP ICMP 207.46.144.74:na 64.212.9.100:na > ns1.bblabs.net 17:27 10-25 > IDS118/scan_Traceroute ICMP ICMP 208.148.96.52:na 64.212.9.100:na > ns1.bblabs.net 17:26 10-25 > IDS246/dos_dos-large-icmp ICMP 212.157.128.115:na 64.212.9.100:na > ns1.bblabs.net 17:26 10-25 > IDS171/icmp_ping zeros ICMP 139.95.253.3:na 64.212.9.100:na > ns1.bblabs.net 17:25 10-25 > IDS171/icmp_ping zeros ICMP 139.95.253.3:na 64.212.9.100:na > ns1.bblabs.net 17:25 10-25 > IDS171/icmp_ping zeros ICMP 139.95.253.3:na 64.212.9.100:na > ns1.bblabs.net 17:25 10-25 > IDS246/dos_dos-large-icmp ICMP 216.235.98.98:na 64.212.9.100:na > ns1.bblabs.net 17:25 10-25 > IDS171/icmp_ping zeros ICMP 139.95.253.3:na 64.212.9.100:na > ns1.bblabs.net 17:24 10-25 > IDS171/icmp_ping zeros ICMP 139.95.253.3:na 64.212.9.100:na > ns1.bblabs.net 17:24 10-25 > IDS171/icmp_ping zeros ICMP 139.95.253.3:na 64.212.9.100:na > ns1.bblabs.net 17:24 10-25 > IDS246/dos_dos-large-icmp ICMP 216.117.43.196:na 64.212.9.100:na > ns1.bblabs.net 17:24 10-25 > IDS246/dos_dos-large-icmp ICMP 216.206.190.125:na 64.212.9.100:na > ns1.bblabs.net 17:23 10-25 > IDS246/dos_dos-large-icmp ICMP 213.174.86.3:na 64.212.9.100:na > ns1.bblabs.net 17:22 10-25 > IDS246/dos_dos-large-icmp ICMP 208.174.0.131:na 64.212.9.100:na > ns1.bblabs.net 17:22 10-25 > IDS118/scan_Traceroute ICMP ICMP 216.200.14.119:na 64.212.9.100:na > ns1.bblabs.net 17:19 10-25 > IDS118/scan_Traceroute ICMP ICMP 216.32.118.78:na 64.212.9.100:na > ns1.bblabs.net 17:19 10-25 > IDS118/scan_Traceroute ICMP ICMP 207.46.144.74:na 64.212.9.100:na > ns1.bblabs.net 17:19 10-25 > IDS118/scan_Traceroute ICMP ICMP 208.148.96.52:na 64.212.9.100:na > ns1.bblabs.net 17:19 10-25 > IDS246/dos_dos-large-icmp ICMP 64.56.69.38:na 64.212.9.100:na > ns1.bblabs.net 17:19 10-25 > IDS246/dos_dos-large-icmp ICMP 213.174.86.3:na 64.212.9.100:na > ns1.bblabs.net 17:19 10-25 > IDS246/dos_dos-large-icmp ICMP 208.172.32.131:na 64.212.9.100:na > ns1.bblabs.net 17:18 10-25 > IDS246/dos_dos-large-icmp ICMP 200.52.171.211:na 64.212.9.100:na > ns1.bblabs.net 17:18 10-25 > IDS246/dos_dos-large-icmp ICMP 206.24.208.131:na 64.212.9.100:na > ns1.bblabs.net 17:18 10-25 > IDS246/dos_dos-large-icmp ICMP 216.44.45.4:na 64.212.9.100:na > ns1.bblabs.net 17:18 10-25 > IDS246/dos_dos-large-icmp ICMP 157.238.44.132:na 64.212.9.100:na > ns1.bblabs.net 17:14 10-25 > IDS246/dos_dos-large-icmp ICMP 148.122.172.38:na 64.212.9.100:na > ns1.bblabs.net 17:14 10-25 > IDS246/dos_dos-large-icmp ICMP 212.155.204.88:na 64.212.9.100:na > ns1.bblabs.net 17:13 10-25 > IDS246/dos_dos-large-icmp ICMP 209.240.197.84:na 64.212.9.100:na > ns1.bblabs.net 17:13 10-25 > IDS118/scan_Traceroute ICMP ICMP 64.242.62.92:na 64.212.9.100:na > ns1.bblabs.net 17:13 10-25 > IDS246/dos_dos-large-icmp ICMP 65.32.4.170:na 64.212.9.100:na > ns1.bblabs.net 17:13 10-25 > IDS118/scan_Traceroute ICMP ICMP 216.200.14.119:na 64.212.9.100:na > ns1.bblabs.net 17:10 10-25 > IDS118/scan_Traceroute ICMP ICMP 216.32.118.78:na 64.212.9.100:na > ns1.bblabs.net 17:10 10-25 > IDS118/scan_Traceroute ICMP ICMP 207.46.144.74:na 64.212.9.100:na > ns1.bblabs.net 17:10 10-25 > IDS118/scan_Traceroute ICMP ICMP 208.148.96.52:na 64.212.9.100:na > ns1.bblabs.net 17:10 10-25 > IDS246/dos_dos-large-icmp ICMP 209.240.77.196:na 64.212.9.100:na > ns1.bblabs.net 17:09 10-25 > IDS246/dos_dos-large-icmp ICMP 207.189.78.249:na 64.212.9.100:na > ns1.bblabs.net 17:08 10-25 > IDS246/dos_dos-large-icmp ICMP 167.216.150.53:na 64.212.9.100:na > ns1.bblabs.net 17:08 10-25 > IDS246/dos_dos-large-icmp ICMP 64.78.164.100:na 64.212.9.100:na > ns1.bblabs.net 17:07 10-25 > IDS118/scan_Traceroute ICMP ICMP 204.201.228.130:na 64.212.9.100:na > ns1.bblabs.net 17:06 10-25 > IDS171/icmp_ping zeros ICMP 163.181.249.3:na 64.212.9.100:na > ns1.bblabs.net 17:06 10-25 > IDS171/icmp_ping zeros ICMP 163.181.249.3:na 64.212.9.100:na > ns1.bblabs.net 17:06 10-25 > IDS171/icmp_ping zeros ICMP 163.181.249.3:na 64.212.9.100:na > ns1.bblabs.net 17:06 10-25 > IDS246/dos_dos-large-icmp ICMP 207.230.26.4:na 64.212.9.100:na > ns1.bblabs.net 17:05 10-25 > IDS246/dos_dos-large-icmp ICMP 216.206.179.5:na 64.212.9.100:na > ns1.bblabs.net 17:05 10-25 > IDS246/dos_dos-large-icmp ICMP 167.216.218.245:na 64.212.9.100:na > ns1.bblabs.net 17:04 10-25 > IDS246/dos_dos-large-icmp ICMP 167.216.216.117:na 64.212.9.100:na > ns1.bblabs.net 17:03 10-25 > IDS118/scan_Traceroute ICMP ICMP 198.31.3.44:na 64.212.9.100:na > ns1.bblabs.net 17:01 10-25 > IDS246/dos_dos-large-icmp ICMP 167.216.133.82:na 64.212.9.100:na > ns1.bblabs.net 16:59 10-25 > IDS118/scan_Traceroute ICMP ICMP 24.130.30.75:na 64.212.9.100:na > ns1.bblabs.net 16:58 10-25 > IDS246/dos_dos-large-icmp ICMP 64.232.139.108:na 64.212.9.100:na > ns1.bblabs.net 16:57 10-25 > IDS171/icmp_ping zeros ICMP 64.92.138.196:na 64.212.9.100:na > ns1.bblabs.net 16:57 10-25 > IDS171/icmp_ping zeros ICMP 64.92.138.196:na 64.212.9.100:na > ns1.bblabs.net 16:57 10-25 > IDS171/icmp_ping zeros ICMP 64.92.138.196:na 64.212.9.100:na > ns1.bblabs.net 16:57 10-25 > IDS246/dos_dos-large-icmp ICMP 64.78.164.100:na 64.212.9.100:na > ns1.bblabs.net 16:57 10-25 > -----Original Message----- > From: Sean Gleason [mailto:sgleason@digisle.net] > Sent: Thursday, October 25, 2001 4:44 PM > To: Christopher J. Wolff > Cc: noc-team(a)digisle.net > Subject: Re: FW: Getting hacked by Digital Isle? > > > > > Could you provide me an IP address so we can investigate further. > > Sean Gleason ---- Digital Island > > > > On Thu, 25 Oct 2001, Christopher J. Wolff wrote: > > > > > I just received a log from my IDS claiming the following attack is taking > > place from your network. If this is true what are you doing and why are > you > > ICMP flooding my primary name server. > > > > > > Log entry: > > > > mailto:abuse@digisle.com for questions > > This ICMP ECHO REQUEST/REPLY is part of the real-time network monitoring > > performed by Digital Island Inc. It is not an attack. If you have > > questions please contact > > > abuse(a)digisle.com........................................................... > > > ............................................................................ > > > ............................................................................ > > > ............................................................................ > > > ............................................................................ > > > ............................................................................ > > > ............................................................................ > > > ............................................................................ > > > ............................................................................ > > > ............................................................................ > > > ............................................................................ > > > ............................................................................ > > > ............................................................................ > > > ............................................................................ > > > ............................................................................ > > ............................................... > > > > > > Regards, > > Christopher J. Wolff, VP, CIO > > Broadband Laboratories, Inc. > > http://www.bblabs.com > > email:chris@bblabs.com > > phone:520.622.4338 x234 > > > > > > >

16 18

RE: Digital Island sponsors DoS attempt?
by Quibell, Marc 26 Oct '01

26 Oct '01

I don't believe I have it backwards, since RFC1191, the one you quoted, states: "A host doing PMTU Discovery must obey the rule that it not send IP datagrams larger than 576 octets unless it has permission from the receiver." So really, unless it get's permission to send larger packets from the receiver, it'll send them at less than 576 bytes. I imagine this'll all change though whenever IPv6 comes about since the min. MTU size will be (approx.) 1200. As another poster stated, IPv6 requires PMTU, so this could become a nasty little problem. Thanks for the rest of the info on the HOW as I am not quite sure either and your scenarios make sense.. Marc -----Original Message----- From: Valdis.Kletnieks(a)vt.edu [mailto:Valdis.Kletnieks@vt.edu] Sent: Friday, October 26, 2001 1:46 PM To: Quibell, Marc Cc: nanog(a)merit.edu Subject: Re: Digital Island sponsors DoS attempt? On Fri, 26 Oct 2001 13:19:51 CDT, "Quibell, Marc" said: > path. Nobody I know, nor have I ever had a problem with "PMTU" and shutting > off ICMP routing. And no I do not believe it is used across the internet, Some of us *have* seen it. > and if it does, it is probably hindering performance since it's probably > using a lower mtu than is allowed, such as 576 or smaller. It would also > have problems running across multi-level routing hierarchies. You have this backwards. RFC791, section 2.1, says: impractical for most hosts and networks. All hosts must be prepared to accept datagrams of up to 576 octets (whether they arrive whole or in fragments). It is recommended that hosts only send datagrams larger than 576 octets if they have assurance that the destination is prepared to accept the larger datagrams. The number 576 is selected to allow a reasonable sized data block to be transmitted in addition to the required header information. For example, this size allows a data block of 512 octets plus 64 header octets to fit in a datagram. The maximal internet header is 60 octets, and a typical internet header is 20 octets, allowing a margin for headers of higher level protocols. So if you're on a LAN that the MTU is 1500, you can be reasonably sure that the other end can catch 1500 byte packets. If you're *leaving* the subnet, you have only send 576-byte packets unless you have reason to believe you can send bigger (PMTU discovery). Some sites just blindly send 1500 bytes anyhow, and *hope* that things get fragmented - but *THAT* behavior is actually against-standard. So the two most prevalent ways to cut the number of packets by 65% or so are to use PMTUd, or to blindly throw 1500 and hope it works..... > Finally, I do not believe PMTU uses pings to discover the PMTU. I believe it > uses TCP or UDP packets at the layers above IP, and it DOES use "ICMP Packet RFC1191 is silent on HOW to do it. IBM specifically chose to use ICMP ECHO to test, rather than the TCP packets, so that PMTU discovery could be done *before* it might actually be needed (since many TCP applications such as SMTP and HTTP don't send a full MTU-sized packet right off the bat because the first few packets are doing negotiation - if you can do PMTU discovery in parallel with that, it can be a win - if you hit a 'frag needed' only after several packets, you get to flush the slow-start timers, retransmit, and a lot of other ugliness.... -- Valdis Kletnieks Operating Systems Analyst Virginia Tech

2 1

Better than ping
by Kevin Loch 26 Oct '01

26 Oct '01

Aside from the silliness of "can I ping you?", someone did make the valuable observation that ping might not be the best way to measure content delivery performance. A better way would be to measure the actual delivery performance by noting the size and delivery time for an actual bonafide request. The traffic directing system could default to random source servers (perhaps with coarse regional constraints) until enough data is gathered to guide future server decisions. As more client requests are received, occasional testing with other source servers could be done to ensure best server selection. A significant drop in throughput could also trigger some re-testing. An additional benefit would be a reasonable guess as to the bandwidth of the end user (dialup, broadband, etc). I see that Apache already has an optional custom-log attribute for transfer time in integer seconds (%T). It would be trivial to modify that to give milliseconds. If you could get this to work right it would be completely non-invasive and should produce better overall results. KL

2 1

Union: 'Close the Facility'
by redhead＠freebsd.redbird.com 26 Oct '01

26 Oct '01

Greetings from 1010wins.com! Reid Fishler recommends you check out this story from 1010 WINS: Union: 'Close the Facility' http://1010wins.com/StoryFolder/story_1648051444_html

2 1

RE: [SOT Rant] Non-hostile probes / opt-in/out
by Patrick W. Gilmore 26 Oct '01

26 Oct '01

At 02:16 PM 10/26/2001 -0500, Quibell, Marc wrote: > >Maybe you should ping NS01.ARMY.MIL about 2400 times in 3 hour and see if >you don't get a visit? Pinging a website 2 times means nothing.. How about 441 times in 2 hours? :) >Marc -- TTFN, patrick

3 2

Re: Fwd: Re: Digital Island sponsors DoS attempt
by Paul A Vixie 26 Oct '01

26 Oct '01

> Until there are standards and technology available to push subscriber > policy to the edge of the network and beyond, the subscriber has > explicitly accepted the overall terms and conditions by which the service > is to be provided. no. i do not agree to receive a smurf attack, no matter whether my contract with a nexthop fails to require them to prevent it from reaching me. > I am assuming in this discussion that when you refer to "benefit", you are > in fact refering to "financial benefit". no, there's no known financial benefit to smurfing me, but the entities who direct such attacks have positive motivation of some kind for doing so -- and i assure you that this benefit to them, whatever it is, is far greater than the benefit to me (which would have to be expressed in negative terms.) > > another test for "welcome" is "if everybody did this, would the recipient > > be injured?" > > An interesting hypothesis, but it is seldom the case that the sender of > traffic knows the details of the recipients infrastructure. i think it's reasonable for a smurfer to know that my infrastructure cannot tolerate multiplicitous input streams from tens of thousands of sources. just as a spammer can indeed know, without doubt, that if millions of senders, all at once, decided to send me unsolicited nonpersonal e-mail, that my inbox would not hold up well. no specific knowledge is required in those cases. in those cases and in other cases where specific knowledge of my infrastructure is not necessary to determine that the traffic would be "not welcome", then it ought not be sent. > > smurf, ddos in general, and spam also classify well by this criteria. it > > Smurf and DDOS attacks are precisely that - attacks. They are > intentionally initiated for the purpose of disrupting infrastructure or > service. They are illegal. in some places, they are illegal. in all places, they are "unwelcome." since a sender of this (or any) traffic may not know the laws in force at the place where the recipient host resides, the broader standard of "unwelcome" is more widely applicable than the narrow standard of "illegal." of course, illegal things ought also not be done. but that'd be a new thread.

7 7

DI pings
by michael＠aplatform.com 26 Oct '01

26 Oct '01

Hello, As one poster pointed out the idea of a web page where on can supply IP ranges to a site that are doing "research" via pings. I have had an issue or concern with some to my site. I sent off an email last night asking for an explanation. The below is an decent response and a way to have ones IP space removed. I dont agrtee 100% with the reasoning but I do like the care offorded. No I dont like not being asked beforehand. But at least there is a response and a vehicle to have it stopped in a timely manner. Michael... ---------- Forwarded message ---------- Date: Fri, 26 Oct 2001 16:57:57 -0400 From: Customer Care at Akamai <ccare(a)akamai.com> To: "'michael(a)aplatform.com'" <michael(a)aplatform.com> Greetings Michael - Our company sometimes does research on Internet connectivity. The goal of our research is to improve download times for end users. No attack to your system was intended or attempted. The activity you saw was a standard ICMP echo request (ping) packet. We're using standard pings which only send one packet per second so there is no risk of a ping flood attack. Pings from different machines are coordinated to prevent a machine from being simultaneously pinged from a multitude of locations. The ping traffic is intended to try and triangulate the location of name-servers with respect to our data- centers in order to provide end users with better performance when they download web pages via the Akamai network. We regret any concern or inconvenience on your part. If you have IP addresses you'd like to be excluded from our testing, please visit the following URL. http://support.akamai.com/cgi-public/cease-pinging.cgi?id=134 Best, Akamai Customer Care

1 0

RE: Fwd: Re: Digital Island sponsors DoS attempt
by Patrick W. Gilmore 26 Oct '01

26 Oct '01

At 04:46 PM 10/26/2001 -0500, Quibell, Marc wrote: >That's great Pat, I especially liked the twist/jump from "upgrading to >DS3...etc" to "Who said I had to use a standardized method to deliver my web >page?". Intead of trying to figure out what your web page has to do with >our- standardized upgrades vs. non-standard, non-internet-community >sanctioned "internet performance enhancement" ping probes- debate, I give >up. I see that the subjects at hand are a big scramble in your gord. >Regardless, have a wonderful weekend. Marc, you continue to latch on to random statements in random e-mails, take them out of context, ignore the main points, and then wonder why people cannot follow your logic. Honestly, I do not blame you for giving up. I still stand by my assertion that the IETF has nothing to do with DI pinging someone. And I stand by my assertion that lots of people do lots of things that are not standardized, and this can frequently be a Good Thing, both for the networks / web pages / whatever involved, and the Internet as a whole. (Feel free to point out that it can also be bad, just so everyone knows you got the last word, even if that was not the point.) Oh, and it's patRICK. Or at least Happy. But not "Pat". Show some simple courtesy and at least look at the signature. >Marc -- TTFN, patrick

1 0

RE: Fwd: Re: Digital Island sponsors DoS attempt
by Quibell, Marc 26 Oct '01

26 Oct '01

That's great Pat, I especially liked the twist/jump from "upgrading to DS3...etc" to "Who said I had to use a standardized method to deliver my web page?". Intead of trying to figure out what your web page has to do with our- standardized upgrades vs. non-standard, non-internet-community sanctioned "internet performance enhancement" ping probes- debate, I give up. I see that the subjects at hand are a big scramble in your gord. Regardless, have a wonderful weekend. Marc -----Original Message----- From: Patrick W. Gilmore [mailto:patrick@ianai.net] Sent: Friday, October 26, 2001 4:33 PM To: nanog(a)merit.edu; Quibell, Marc Subject: RE: Fwd: Re: Digital Island sponsors DoS attempt At 04:00 PM 10/26/2001 -0500, Quibell, Marc wrote: >Don't be insulting Happy Gilmore. My goodness. You are so original. Lord knows I ain't never heard that one before. Oh, three words - Pot, Kettle, Black. >You said, "Certainly would not want someone to upgrade from a DS3 to an OC3 >to "enhance internet >traffic" from their site to me, or multi-home to make sure if one provider >/ line dies their site is still available. And forget about using load >balancers, Content Distribution Networks, etc." > >Talk about silly! Ever notice why STANDARD (hint) upgrades are warranted, >while not even remotely connected to the subject at hand? >S-T-A-N-D-A-R-D-I-Z-E-D. We all can use our brains and tell the difference >between standard upgrades and standard load-balancing, as defined by >numerous RFCs, and non-standard, uninformed haphazard methodology! First: Who said I had to use a standardized method to deliver my web page? Second: Most "standards" are in use before they are standardized (e.g. IP Anycast). Third: Last time I checked, you did not get to decide what was "warranted" on my network / web server / whatever. Fourth: You have yet to show you can use your brain. Uh, I mean, "use your brain to tell the difference between standard and non-standard methodology". (Yeah, that's what I meant. :) >I made a point that basically said DI's unorthodoxed methodologies are not >your choice (at least not until you discover them). You addressed that point >by saying I misinterpreted that, that "using a gizmo was my choice" and I >said that the difference is that one is a choice, your choice, the other is >not. And I must also add that one affects only you while the other affects >the entire Internet. Big difference, see it? Now take back that 'silly' >comment! :) No, you are still being silly. I specifically take exception to your comment: "Usually, IP and such technologies are the charge of the internet community and we form committees, or use IEEE, IETF, RFCs, ARIN." Those bodies make a framework, and we are allowed to be as creative inside (and sometimes outside) that framework as we please. Period. Furthermore, you stated: "I believe this to be the key as to why this is wrong and why DI, or Akamai, should not be even allowed to 'help' the internet." I did not ask your permission to be "allowed" to help the Internet, or run my business. And after this thread, you can be assured I never shall. If you do not like the fact other people can do things on the Internet which are not sanctioned by the RFCs, or you personally, I am afraid you are in for a life full of disappointment. And I seriously doubt a single network will give a gnat's ass whether it bothers you or not. >Marc -- TTFN, patrick

1 0

RE: Fwd: Re: Digital Island sponsors DoS attempt
by Patrick W. Gilmore 26 Oct '01

26 Oct '01

At 04:00 PM 10/26/2001 -0500, Quibell, Marc wrote: >Don't be insulting Happy Gilmore. My goodness. You are so original. Lord knows I ain't never heard that one before. Oh, three words - Pot, Kettle, Black. >You said, "Certainly would not want someone to upgrade from a DS3 to an OC3 >to "enhance internet >traffic" from their site to me, or multi-home to make sure if one provider >/ line dies their site is still available. And forget about using load >balancers, Content Distribution Networks, etc." > >Talk about silly! Ever notice why STANDARD (hint) upgrades are warranted, >while not even remotely connected to the subject at hand? >S-T-A-N-D-A-R-D-I-Z-E-D. We all can use our brains and tell the difference >between standard upgrades and standard load-balancing, as defined by >numerous RFCs, and non-standard, uninformed haphazard methodology! First: Who said I had to use a standardized method to deliver my web page? Second: Most "standards" are in use before they are standardized (e.g. IP Anycast). Third: Last time I checked, you did not get to decide what was "warranted" on my network / web server / whatever. Fourth: You have yet to show you can use your brain. Uh, I mean, "use your brain to tell the difference between standard and non-standard methodology". (Yeah, that's what I meant. :) >I made a point that basically said DI's unorthodoxed methodologies are not >your choice (at least not until you discover them). You addressed that point >by saying I misinterpreted that, that "using a gizmo was my choice" and I >said that the difference is that one is a choice, your choice, the other is >not. And I must also add that one affects only you while the other affects >the entire Internet. Big difference, see it? Now take back that 'silly' >comment! :) No, you are still being silly. I specifically take exception to your comment: "Usually, IP and such technologies are the charge of the internet community and we form committees, or use IEEE, IETF, RFCs, ARIN." Those bodies make a framework, and we are allowed to be as creative inside (and sometimes outside) that framework as we please. Period. Furthermore, you stated: "I believe this to be the key as to why this is wrong and why DI, or Akamai, should not be even allowed to 'help' the internet." I did not ask your permission to be "allowed" to help the Internet, or run my business. And after this thread, you can be assured I never shall. If you do not like the fact other people can do things on the Internet which are not sanctioned by the RFCs, or you personally, I am afraid you are in for a life full of disappointment. And I seriously doubt a single network will give a gnat's ass whether it bothers you or not. >Marc -- TTFN, patrick

1 0