From branto at branto.com Sun Jun 1 10:39:43 2008 From: branto at branto.com (Brant I. Stevens) Date: Sun, 01 Jun 2008 11:39:43 -0400 Subject: NANOG NYC Event In-Reply-To: <20080601035850.45405.qmail@simone.iecc.com> Message-ID: On 5/31/08 11:58 PM, "John Levine" wrote: > In article <43661d390805312028u130046ddlc804e4615c83ba62 at mail.gmail.com> you > write: >> I second the motion to recognize Dinosaur BBQ. All those in favor? > > Dinosaur is swell, but it's in Syracuse. > > Perhaps you could pick one that's reachable by subway instead. Dinosaur Barbecue www.dinosaurbarbque.com 646 W 131st St New York, NY 10027 It's in Harlem. BOOOOOOO!!!!! > > > > From sil at infiltrated.net Sun Jun 1 10:54:40 2008 From: sil at infiltrated.net (J. Oquendo) Date: Sun, 1 Jun 2008 10:54:40 -0500 Subject: NANOG NYC Event In-Reply-To: References: <20080601035850.45405.qmail@simone.iecc.com> Message-ID: <20080601155440.GA47184@infiltrated.net> On Sun, 01 Jun 2008, Brant I. Stevens wrote: > > It's in Harlem. BOOOOOOO!!!!! > So is Columbia University! Harlem is in the process of going through a renaissance and has been over the past 10 or more so things have changed for the better. Just avoid going there after certain hours ;) As for the prior Brooklyn comment, Park Slope also has some great eats but the area/scene tends to be sort of artsy. If you want to spend some time sightseeing Brooklyn, the Brooklyn Public Library (main one) Grand Army Plaza is near the Brooklyn Botanic Gardens. Don't forget Coney Island which has also changed in the last decade. Again, watch those hours, NY is a Jeckyll and Hyde city. Nice sometimes, beautiful to visit but can be insanely ugly. The downtown Brooklyn area has some nice eats but I've always preferred the city. In the area of downtown Brooklyn, you'll typically find a bunch of people in local government and lawyers eating as the courts are downtown. For those looking for sweets, don't forget the ever famous (overhyped) Junior's Cheesecake. If you've travelled to Coney Island then one cannot forget Nathan's. There are some really good pubs in the Red Hook section, but alas again, going through certain neighborhoods is not for everyone. You can jump on a Water Taxi there for kicks though. Makes for nice pictures at night. Sightseeing: Jump on a boat at night (booze cruise) $25.00 http://www.nywatertaxi.com/tours/happyhour/ Or just hop on an "On and Off" cruise: http://www.nywatertaxi.com/hop/ $20.00 -- =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ J. Oquendo SGFA #579 (FW+VPN v4.1) SGFE #574 (FW+VPN v4.1) CEH/CNDA, CHFI "Experience hath shewn, that even under the best forms (of government) those entrusted with power have, in time, and by slow operations, perverted it into tyranny." Thomas Jefferson wget -qO - www.infiltrated.net/sig|perl http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x3AC173DB From johnl at iecc.com Sun Jun 1 11:09:56 2008 From: johnl at iecc.com (John Levine) Date: 1 Jun 2008 16:09:56 -0000 Subject: NANOG NYC Event In-Reply-To: <20080601035850.45405.qmail@simone.iecc.com> Message-ID: <20080601160956.22514.qmail@simone.iecc.com> >Dinosaur is swell, but it's in Syracuse. > >Perhaps you could pick one that's reachable by subway instead. Oh, all right, as about 47 people have pointed out, they have a branch on 131st St. The barbeque is not bad. I eat it at the NY State Fair every year. On the other hand, I would think that in NYC, home of the most wonderful food on the continent,* you could do better than a branch of a yuppie ex biker joint from Syracuse. How about RUB at 23rd and 7th? Or Johnny Utah's at 51st and 5th? Or Oklahoma Smoke up at 145st St? R's, John * - with the possible exception of Montreal, an argument that can only be resolved by extensive research in both places From SFisher at Bresnan.com Sun Jun 1 11:57:31 2008 From: SFisher at Bresnan.com (Fisher, Shawn) Date: Sun, 1 Jun 2008 12:57:31 -0400 Subject: NANOG NYC Event Message-ID: <21352038E7719F43A6D65B2D90B5256CCBFA34@fossil.bresnan.com> (Drifting further off topic). Another suggestion to add is the DUMBO area of brooklyn, down under mahattanville overpass, easy to reach from manhattan, take a nice stroll across the brooklyn bridge and your there, lots of cool restaurants. Another bit of history, walk to montague street, yes the montague street mr dylan sings about in tangled up in blue. (some controversy over this) best way to walk is on the promenade along the east river, great views of manhattan. Enjoy -------------------------- Sent using BlackBerry -----Original Message----- From: J. Oquendo To: nanog at nanog.org Sent: Sun Jun 01 11:54:40 2008 Subject: Re: NANOG NYC Event On Sun, 01 Jun 2008, Brant I. Stevens wrote: > > It's in Harlem. BOOOOOOO!!!!! > So is Columbia University! Harlem is in the process of going through a renaissance and has been over the past 10 or more so things have changed for the better. Just avoid going there after certain hours ;) As for the prior Brooklyn comment, Park Slope also has some great eats but the area/scene tends to be sort of artsy. If you want to spend some time sightseeing Brooklyn, the Brooklyn Public Library (main one) Grand Army Plaza is near the Brooklyn Botanic Gardens. Don't forget Coney Island which has also changed in the last decade. Again, watch those hours, NY is a Jeckyll and Hyde city. Nice sometimes, beautiful to visit but can be insanely ugly. The downtown Brooklyn area has some nice eats but I've always preferred the city. In the area of downtown Brooklyn, you'll typically find a bunch of people in local government and lawyers eating as the courts are downtown. For those looking for sweets, don't forget the ever famous (overhyped) Junior's Cheesecake. If you've travelled to Coney Island then one cannot forget Nathan's. There are some really good pubs in the Red Hook section, but alas again, going through certain neighborhoods is not for everyone. You can jump on a Water Taxi there for kicks though. Makes for nice pictures at night. Sightseeing: Jump on a boat at night (booze cruise) $25.00 http://www.nywatertaxi.com/tours/happyhour/ Or just hop on an "On and Off" cruise: http://www.nywatertaxi.com/hop/ $20.00 -- =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ J. Oquendo SGFA #579 (FW+VPN v4.1) SGFE #574 (FW+VPN v4.1) CEH/CNDA, CHFI "Experience hath shewn, that even under the best forms (of government) those entrusted with power have, in time, and by slow operations, perverted it into tyranny." Thomas Jefferson wget -qO - www.infiltrated.net/sig|perl http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x3AC173DB From henry at AegisInfoSys.com Sun Jun 1 16:27:10 2008 From: henry at AegisInfoSys.com (Henry Yen) Date: Sun, 1 Jun 2008 17:27:10 -0400 Subject: NANOG NYC Event In-Reply-To: <20080601155440.GA47184@infiltrated.net>; from J. Oquendo on Sun, Jun 01, 2008 at 10:54:40AM -0500 References: <20080601035850.45405.qmail@simone.iecc.com> <20080601155440.GA47184@infiltrated.net> Message-ID: <20080601172710.R2829@AegisInfoSys.com> On Sun, Jun 01, 2008 at 10:54:40AM -0500, J. Oquendo wrote: > As for the prior Brooklyn comment, Park Slope > also has some great eats but the area/scene > tends to be sort of artsy. > > The downtown Brooklyn area has some nice eats > but I've always preferred the city. In the area > of downtown Brooklyn, you'll typically find a > bunch of people in local government and lawyers > eating as the courts are downtown. > > For those looking for sweets, don't forget the > ever famous (overhyped) Junior's Cheesecake. Disclaimer: I've worked in the immediate area of this conference on and off for over 30 years. (In fact, I'm staring longingly down at the Marriott Hotel from the office window right now...) First, you simply must take a walk across the Brooklyn Bridge to Manhattan (and back). Exhilarating views, an unforgettable experience, and you'd be participating in one of the more common things that "all" NYC people do. Just walk out the "front" door of the hotel and turn right. (Watch out for crazy bicyclists!) Second, Junior's Cheesecake, overhyped as it is, is still arguably among the best "domestic" cheesecakes, at least on the east coast. You really ought to try it. But, don't stop there -- the brisket/corned-beef/pastrami on twin rolls is highly recommended. (My personal favorite is their down-home matzoh-ball soup.) Third, the Brooklyn Heights area is admittedly "artsy", but there's lots of interesting and tasty variety. I've had great food at several Italian seafood-style places (although if that's your preference, I'd encourage you to go to Vincent's in Little Italy (lower Manhattan)). Finally, I didn't see a destination that seems like it might be very useful: Radio Shack (go out the "back" door of the hotel, turn right, half a block to Willoughby, turn right, and it's right across the street from the White Castle (which is its own "destination")). P.S. If you're into bicycling, the Hudson River Park bikeway (runs about 10 miles along the western Manhattan shoreline) is a paved, fantasitc, ride. I don't know if the bike rental season has started yet, though. -- Henry Yen Aegis Information Systems, Inc. Senior Systems Programmer Hicksville, New York From eric at spaethco.com Sun Jun 1 23:57:06 2008 From: eric at spaethco.com (Eric Spaeth) Date: Sun, 01 Jun 2008 23:57:06 -0500 Subject: Comcast - Stuck route in Chicago directing MN traffic via Denver Message-ID: <48437DA2.9060100@spaethco.com> For the last couple weeks there has been a route stuck in the Chicago wan/core that is directing some Minnesota-bound traffic through Denver, even though Chicago and the Roseville, MN aggregation remain up and directly connected. This has the dual benefit of unnecessarily increasing the load on Comcast's internal backbone as well as increasing latency for Minnesota subscribers connecting to "east of the Mississippi" destinations by ~20ms. I'm hoping Comcast engineers read this list, or someone in the carrier community can help poke one of their Comcast contacts to help get this resolved. Thanks in advance! "Wedged" route - 76.113.128.0/17 Correct route - 69.180.128.0/18 Example trace from Chicago source to 76.113.128.0/17: ========================================= traceroute to 76.113.128.1 (76.113.128.1), 30 hops max, 40 byte packets 1 69.65.40.62 (69.65.40.62) 0.542 ms 0.511 ms 0.508 ms 2 so2-0-0-0.er1.Chi1.Servernap.net (69.39.239.169) 1.632 ms 1.642 ms 2.121 ms 3 ge-6-20.car1.Chicago1.Level3.net (4.79.65.49) 1.605 ms 1.608 ms 1.619 ms 4 ae-2-54.edge1.Chicago2.Level3.net (4.68.101.115) 1.604 ms 1.602 ms 1.600 ms 5 COMCAST-IP.edge1.Chicago2.Level3.net (4.71.248.26) 2.735 ms 2.741 ms 2.739 ms 6 pos-0-8-0-0-cr01.denver.co.ibone.comcast.net (68.86.85.114) 27.284 ms 27.398 ms 27.387 ms 7 te-9-4-ar02.roseville.mn.minn.comcast.net (68.86.91.154) 44.177 ms * * 8 te-0-2-0-5-ar03.roseville.mn.minn.comcast.net (68.87.174.73) 28.352 ms 28.352 ms 28.349 ms 9 te-2-1-ur01.sims.mn.minn.comcast.net (68.87.174.74) 28.826 ms * * 10 te-8-3-ur02.sims.mn.minn.comcast.net (68.87.174.78) 28.959 ms * * 11 te-2-1-ur01.newport.mn.minn.comcast.net (68.87.174.82) 29.267 ms * te-2-1-ur01.newport.mn.minn.comcast.net (68.87.174.82) 28.700 ms 12 c-76-113-128-1.hsd1.mn.comcast.net (76.113.128.1) 28.638 ms 28.673 ms 28.667 ms ========================================= Example trace from Chicago source to working route 69.180.128.0/18 ========================================= traceroute to 69.180.130.1 (69.180.130.1), 30 hops max, 40 byte packets 1 69.65.40.62 (69.65.40.62) 0.482 ms 0.450 ms 0.446 ms 2 so2-0-0-0.er1.Chi1.Servernap.net (69.39.239.169) 1.595 ms 2.082 ms 2.082 ms 3 ge-6-20.car1.Chicago1.Level3.net (4.79.65.49) 1.568 ms 1.569 ms 1.579 ms 4 ae-2-52.edge1.Chicago2.Level3.net (4.68.101.51) 1.562 ms 1.563 ms 1.560 ms 5 COMCAST-IP.edge1.Chicago2.Level3.net (4.71.248.22) 2.708 ms 2.713 ms 2.711 ms 6 te-0-1-0-7-ar03.roseville.mn.minn.comcast.net (68.87.174.21) 13.144 ms 11.919 ms 11.877 ms 7 68.87.174.22 (68.87.174.22) 11.824 ms * * 8 te-8-3-ur02.brooklynpark.mn.minn.comcast.net (68.87.174.26) 12.333 ms * * 9 te-2-1-ur01.newhope.mn.minn.comcast.net (68.87.174.30) 12.012 ms * * 10 c-3-0-ubr02.newhope.mn.minn.comcast.net (69.180.130.1) 11.963 ms 12.018 ms 11.973 ms ========================================= -Eric From drais at icantclick.org Mon Jun 2 04:04:24 2008 From: drais at icantclick.org (david raistrick) Date: Mon, 2 Jun 2008 09:04:24 +0000 (UTC) Subject: Emerg data recovery recommdnations? Message-ID: guys, wrong place, I know, but network down is network down no matter which side of the cable it falls on... Can anyone give any solid recommendations for a data recovery service who can fly to our site to extract data from a f'ed up RAID array? It's an absolute emergency (for us, of course). offlist please. .d --- david raistrick http://www.netmeister.org/news/learn2quote.html drais at icantclick.org http://www.expita.com/nomime.html From christian at visr.org Mon Jun 2 06:47:56 2008 From: christian at visr.org (Christian) Date: Mon, 2 Jun 2008 07:47:56 -0400 Subject: IOS Rookit: the sky isn't falling (yet) In-Reply-To: <98B7739FB65BF04F9B3233AB842EEC950297AEB6@EXCHANGE.ctiusa.com> References: <483BB25A.4030204@securite.org> <32648.1211920991@turing-police.cc.vt.edu> <20080529001450.10db0337@cs.columbia.edu> <98B7739FB65BF04F9B3233AB842EEC950297ADFB@EXCHANGE.ctiusa.com> <5B115146-15BF-4935-A0D1-583A4E4CCD71@puck.nether.net> <98B7739FB65BF04F9B3233AB842EEC950297AE32@EXCHANGE.ctiusa.com> <98B7739FB65BF04F9B3233AB842EEC950297AEB6@EXCHANGE.ctiusa.com> Message-ID: <9b62cf2f0806020447r10fc3ed0i6be793d6db694fb@mail.gmail.com> here's the slides if anyone hasn't seen http://seclists.org/fulldisclosure/2008/May/att-0668/EuSecWest_presentation_ppt On Thu, May 29, 2008 at 11:27 AM, Fred Reimer wrote: > New keys, to be stored on the crypto chip, would presumably be delivered in > a separately signed package using a master key that would not change > (embedded within the chip). Maybe Cisco even doesn't have this key, and > would need to send a revocation or new public key to be stored on the chip > to the chip manufacturer, who would sign it with the master private key and > which then could be delivered in a software update to the system. There > are > many possibilities, and no crypto scheme is foolproof. That much has been > proven. But no, you would not make the on-chip EEPROM of the crypto chip > "flashable" in the normal meaning of the word. You would send the chip a > pointer to a buffer that contains a signed update key, and the chip itself > would verify that signature and only then program the updated key(s). > > My intention was not to turn nanog into a crypto forum. I'd be much more > interested in any unique methods that people use to harden their systems > that have not already been widely distributed through vendor or industry > best practices. > > Fred Reimer, CISSP, CCNP, CQS-VPN, CQS-ISS > Senior Network Engineer > Coleman Technologies, Inc. > 954-298-1697 > > > > -----Original Message----- > > From: Jim Wise [mailto:jwise at draga.com] > > Sent: Thursday, May 29, 2008 11:10 AM > > To: Fred Reimer > > Cc: Jared Mauch; nanog at nanog.org > > Subject: RE: IOS Rookit: the sky isn't falling (yet) > > > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > On Thu, 29 May 2008, Fred Reimer wrote: > > > > >The code would presumably be run upon boot from a non-flashable > > source, > > >which would run the boot ROM code through a check on the crypto chip > > and > > >only execute it if it passed. You would not put the code that checks > > the > > >boot ROM on the boot ROM. The new crypto chip would presumably have > > the > > >initial boot code, which would only be designed to check the boot ROM > > >signature and nothing else so presumably would never need to be > > replaced and > > >hence would be designed to be non-flashable. > > > > Doesn't this just push the chicken-and-egg problem up the chain one > > step? > > The ROMMON would be flashable (among other reasons) because the key > > used to > > sign IOS releases should change over the years -- gaining length as > > cycles > > get cheaper, being replaced periodically to prevent use of the same key > > for > > too long, and perhaps being revoked if it should ever be compromised. > > > > If the ROMMON is itself to be verified by a prior, non-flashable ROM, > > then > > all the same arguments would call for making its key-list updatable -- > > and > > given the time-in-service seen by many such devices, any weakness in > > that > > key list would be around for quite some time. > > > > - -- > > Jim Wise > > jwise at draga.com > > -----BEGIN PGP SIGNATURE----- > > Version: GnuPG v1.4.9 (NetBSD) > > > > iD8DBQFIPsdRq/KRbT0KwbwRAkcmAJ4xOBtANHOc+C/fzL+7PvgWnjp76ACfSGUw > > 43+1Pq3xWS4MagWzdetZ0ws= > > =62gJ > > -----END PGP SIGNATURE----- > From joelja at bogus.com Mon Jun 2 07:02:29 2008 From: joelja at bogus.com (Joel Jaeggli) Date: Mon, 02 Jun 2008 05:02:29 -0700 Subject: Update: NANOG 43 PGP signing party. Message-ID: <4843E155.1090608@bogus.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The keysigning sessions are going to be during the morning breaks during the general session, and will be located in the Gleason/Roebling rooms. Monday June 2nd 11:00-11:30 Tuesday June 3rd 11:00-11:30 If you plan to participate there is still time up until tomorrow to add your key to the keyring at: http://biglumber.com/x/web?ev=19916 And come to one or both sessions with some form of government issued photo ID. If you have any further questions, feel free to contact me via email or corner one of the people with the pgp signing dots since they mostly know the score. While printouts will probably be available at the sessions, feel free to add your key to the keyring right up to the time of the last keysigning event. thanks joel _______________________________________________ NANOG mailing list NANOG at nanog.org http://mailman.nanog.org/mailman/listinfo/nanog -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFIQ+FV8AA1q7Z/VrIRAuN6AJ4hlfoRX/B2lFC5xlLV+nX1jOnuhgCdE8Me vmxenQEVkrzrcT6waUiN3zk= =Oaxb -----END PGP SIGNATURE----- From darden at armc.org Mon Jun 2 07:21:20 2008 From: darden at armc.org (Darden, Patrick S.) Date: Mon, 2 Jun 2008 08:21:20 -0400 Subject: Types of packet modifications allowed for networks In-Reply-To: <4841CA4C.5020708@vaxination.ca> Message-ID: I'm not aware of any hard rules regarding this. I'll include yours below: --packet fragmentation due to inconsistent MTUs and/or bandwidth (e.g. moving from ATM at 150Mbps to a fractional DS3 at 3.088Mbps) --ttl changes from hop to hop --dest ip changes from hop to hop --PAT/NAT changes in last network borders (e.g. routing traffic to appropriate endpoints (servers) or starting points (workstations)) --PAT/NAT changes in "last" host (e.g. it hits ext ip port 4443, gets changed to newip:443 and forwarded on) --firewall changes in buffer/mother network (e.g. protective network or DMZ)--these could be almost anything, most frequent would be morons who completely block ICMP--you should probably count anti-spam and anti-virus (layer 4 but affects layer 3 dramatically) but these are usually advertised features subscribed to by the customers (as opposed to secret "features" that only come out due to customer outrage) --header checksum changes after contents changes (e.g. dip at a router) Meh, not sure I was helpful. --p From joelja at bogus.com Mon Jun 2 07:34:14 2008 From: joelja at bogus.com (Joel Jaeggli) Date: Mon, 02 Jun 2008 05:34:14 -0700 Subject: NANOG 42 Lightning Talk submission reminder... Message-ID: <4843E8C6.10207@bogus.com> Greetings, Lightning talk submission remains open until Tuesday June 3rd. Submissions can be made on the NANOG PC website by logging in as or creating a speaker account: http://www.nanogpc.org A lightning talk is a very short presentation or speech by any attendee on any topic relevant to the NANOG audience. These are limited to ten minutes; this will be strictly enforced. If you have a topic that's timely, interesting, or even a crackpot idea you want to share, we encourage you to consider presenting it. The Program Committee will decide which submissions are relevant (using criteria based on the NANOG mailing list AUP) and choose the best ones to be presented. Use of slides is optional. All slides must be in PDF or Powerpoint format, and will be loaded in advance onto the speaker laptop on the podium. Thanks Joel From spam at afoyi.com Mon Jun 2 07:54:48 2008 From: spam at afoyi.com (Darryl Ross) Date: Mon, 02 Jun 2008 22:24:48 +0930 Subject: Types of packet modifications allowed for networks In-Reply-To: References: Message-ID: <4843ED98.8030702@afoyi.com> Darden, Patrick S. wrote: > --packet fragmentation due to inconsistent MTUs and/or bandwidth (e.g. moving from ATM at 150Mbps to a fractional DS3 at 3.088Mbps) MTUs yes, bandwidth no. Bandwidth congestion at the boundary to a slower network will cause buffering and dropped packets, not a fragment. Trying to fit a jumbo frame packet into a standard MTU network _will_ (if the DF bit is not set). > --ttl changes from hop to hop Decrements, yes. > --dest ip changes from hop to hop Say what? The L2 address might change at each hop (eg, MAC address of the next gateway in ethernet type networks) but the L3 destination address, which is the "destination IP", certainly doesn't. If it did how would the packet ever get to where it was sent? > --PAT/NAT changes in last network borders (e.g. routing traffic to appropriate endpoints (servers) or starting points (workstations)) NAT/PAT can occur at any point in the network, but is most common at the edges. > --PAT/NAT changes in "last" host (e.g. it hits ext ip port 4443, gets changed to newip:443 and forwarded on) Same. > --firewall changes in buffer/mother network (e.g. protective network or DMZ)--these could be almost anything, most frequent would be morons who completely block ICMP--you should probably count anti-spam and anti-virus (layer 4 but affects layer 3 dramatically) but these are usually advertised features subscribed to by the customers (as opposed to secret "features" that only come out due to customer outrage) This is rather common, especially things like resetting the QOS bits, clearing the DF flag, etc. > --header checksum changes after contents changes (e.g. dip at a router) TTL being decremented is enough. Cheers Darryl -- Darryl Ross, VK5FUNE Director, AFOYI, "Information Technology Solutions" p +61 8 7127 1831 f +61 8 8425 9607 e darryl at afoyi.com From davediaz.tech at gmail.com Mon Jun 2 08:45:41 2008 From: davediaz.tech at gmail.com (David Diaz) Date: Mon, 2 Jun 2008 09:45:41 -0400 Subject: NANOG NYC Event In-Reply-To: <20080601172710.R2829@AegisInfoSys.com> References: <20080601035850.45405.qmail@simone.iecc.com> <20080601155440.GA47184@infiltrated.net> <20080601172710.R2829@AegisInfoSys.com> Message-ID: Something Important to remember (I learned the hard way) Cell phones do not work on the metro so remember A C F JAY STREET STOP Those are the trains that stop on the back corner of the hotel. A&C are BLUE LINE. F is BROWN i believe. the RED 2,3 line stops a block away. If you get lost remember we are across from the Court House. IF ANY questions please email me at davediaz(at)gmail.com or davediaz(at) telx.com ENJOY David Diaz Telx Host Nanog43 From smb at cs.columbia.edu Mon Jun 2 09:12:20 2008 From: smb at cs.columbia.edu (Steven M. Bellovin) Date: Mon, 2 Jun 2008 10:12:20 -0400 Subject: Types of packet modifications allowed for networks In-Reply-To: <4841CA4C.5020708@vaxination.ca> References: <4841CA4C.5020708@vaxination.ca> Message-ID: <20080602101220.0ef77b8a@cs.columbia.edu> On Sat, 31 May 2008 17:59:40 -0400 Jean-Fran?ois Mezei wrote: > I would like any pointers to good documents that outline what sort of > packet modifications are allowed (in terms of Internet > culture/policies) by networks. > > Notably: > > For a transit network (neither sending or destination IPs belong to > the network) > > For the sending network (originating IP belongs to that network) > > For the destination network (destination IP belongs to that network). > > > Obviously, every router will change/decrement the TTL (and recalculate > the header checksum) in the IP header. Are there other fields that are > routinely changed at every hop ? Assorted IP options carry network state: Record Route, Loose and Strict Source Route, Timestamp -- see RFC 791. I wouldn't say "routinely", but it is in the spec. I forget the status of the flow label for IPv6. > > Would it also be correct to state that any network along the way would > have the right to fragment a packet in two or more pieces ? Or would > that only be the destination network needing to fragment a packet to > fit the last mile (PPP dialup or PPPoE ) in cases where MTU > negotiations failed ? Note that in-flight fragmentation is only permitted for certain packets: one without DF set for IPv4; ones with a fragmentation header for IPv6. > > Are there sacred rules documented anywhere about not modifying > anything else in the packets during transit ? Or has there never > been any formal documentation on this because it was so obvious > nobody was allowed to modify packets in transit ? > Only the end-to-end principle... I sometimes see suggestions that routers should be able to add IP options or v6 extension headers. These are known as bad ideas. --Steve Bellovin, http://www.cs.columbia.edu/~smb From eric at spaethco.com Mon Jun 2 09:13:17 2008 From: eric at spaethco.com (Eric Spaeth) Date: Mon, 02 Jun 2008 09:13:17 -0500 Subject: Comcast - Stuck route in Chicago directing MN traffic via Denver In-Reply-To: <48437DA2.9060100@spaethco.com> References: <48437DA2.9060100@spaethco.com> Message-ID: <4843FFFD.4060506@spaethco.com> Thanks for the folks who looked at this -- things are looking better this morning: traceroute to 76.113.128.1 (76.113.128.1), 30 hops max, 40 byte packets 1 69.65.40.62 (69.65.40.62) 0.858 ms 0.840 ms 0.838 ms 2 so2-0-0-0.er1.Chi1.Servernap.net (69.39.239.169) 1.876 ms 1.878 ms 1.875 ms 3 ge-6-20.car1.Chicago1.Level3.net (4.79.65.49) 1.854 ms 1.858 ms 1.855 ms 4 ae-2-54.edge1.Chicago2.Level3.net (4.68.101.115) 60.047 ms 60.068 ms 60.067 ms 5 COMCAST-IP.edge1.Chicago2.Level3.net (4.71.248.26) 3.045 ms 3.051 ms 3.049 ms 6 te-0-2-0-5-ar03.roseville.mn.minn.comcast.net (68.87.174.73) 12.172 ms 12.267 ms 12.250 ms 7 te-2-1-ur01.sims.mn.minn.comcast.net (68.87.174.74) 11.717 ms * * 8 te-8-3-ur02.sims.mn.minn.comcast.net (68.87.174.78) 11.940 ms * * 9 te-2-1-ur01.newport.mn.minn.comcast.net (68.87.174.82) 12.224 ms * * 10 c-76-113-128-1.hsd1.mn.comcast.net (76.113.128.1) 12.203 ms 12.203 ms 12.045 ms -Eric Eric Spaeth wrote: > For the last couple weeks there has been a route stuck in the Chicago > wan/core that is directing some Minnesota-bound traffic through > Denver, even though Chicago and the Roseville, MN aggregation remain > up and directly connected. This has the dual benefit of unnecessarily > increasing the load on Comcast's internal backbone as well as > increasing latency for Minnesota subscribers connecting to "east of > the Mississippi" destinations by ~20ms. > > I'm hoping Comcast engineers read this list, or someone in the carrier > community can help poke one of their Comcast contacts to help get this > resolved. > > Thanks in advance! > "Wedged" route - 76.113.128.0/17 > Correct route - 69.180.128.0/18 > > Example trace from Chicago source to 76.113.128.0/17: > ========================================= > traceroute to 76.113.128.1 (76.113.128.1), 30 hops max, 40 byte packets > 1 69.65.40.62 (69.65.40.62) 0.542 ms 0.511 ms 0.508 ms > 2 so2-0-0-0.er1.Chi1.Servernap.net (69.39.239.169) 1.632 ms 1.642 > ms 2.121 ms > 3 ge-6-20.car1.Chicago1.Level3.net (4.79.65.49) 1.605 ms 1.608 ms > 1.619 ms > 4 ae-2-54.edge1.Chicago2.Level3.net (4.68.101.115) 1.604 ms 1.602 > ms 1.600 ms > 5 COMCAST-IP.edge1.Chicago2.Level3.net (4.71.248.26) 2.735 ms 2.741 > ms 2.739 ms > 6 pos-0-8-0-0-cr01.denver.co.ibone.comcast.net (68.86.85.114) 27.284 > ms 27.398 ms 27.387 ms > 7 te-9-4-ar02.roseville.mn.minn.comcast.net (68.86.91.154) 44.177 ms > * * > 8 te-0-2-0-5-ar03.roseville.mn.minn.comcast.net (68.87.174.73) > 28.352 ms 28.352 ms 28.349 ms > 9 te-2-1-ur01.sims.mn.minn.comcast.net (68.87.174.74) 28.826 ms * * > 10 te-8-3-ur02.sims.mn.minn.comcast.net (68.87.174.78) 28.959 ms * * > 11 te-2-1-ur01.newport.mn.minn.comcast.net (68.87.174.82) 29.267 ms > * te-2-1-ur01.newport.mn.minn.comcast.net (68.87.174.82) 28.700 ms > 12 c-76-113-128-1.hsd1.mn.comcast.net (76.113.128.1) 28.638 ms > 28.673 ms 28.667 ms > ========================================= > > Example trace from Chicago source to working route 69.180.128.0/18 > ========================================= > traceroute to 69.180.130.1 (69.180.130.1), 30 hops max, 40 byte packets > 1 69.65.40.62 (69.65.40.62) 0.482 ms 0.450 ms 0.446 ms > 2 so2-0-0-0.er1.Chi1.Servernap.net (69.39.239.169) 1.595 ms 2.082 > ms 2.082 ms > 3 ge-6-20.car1.Chicago1.Level3.net (4.79.65.49) 1.568 ms 1.569 ms > 1.579 ms > 4 ae-2-52.edge1.Chicago2.Level3.net (4.68.101.51) 1.562 ms 1.563 > ms 1.560 ms > 5 COMCAST-IP.edge1.Chicago2.Level3.net (4.71.248.22) 2.708 ms 2.713 > ms 2.711 ms > 6 te-0-1-0-7-ar03.roseville.mn.minn.comcast.net (68.87.174.21) > 13.144 ms 11.919 ms 11.877 ms > 7 68.87.174.22 (68.87.174.22) 11.824 ms * * > 8 te-8-3-ur02.brooklynpark.mn.minn.comcast.net (68.87.174.26) 12.333 > ms * * > 9 te-2-1-ur01.newhope.mn.minn.comcast.net (68.87.174.30) 12.012 ms * * > 10 c-3-0-ubr02.newhope.mn.minn.comcast.net (69.180.130.1) 11.963 ms > 12.018 ms 11.973 ms > ========================================= > > -Eric > From drc at virtualized.org Mon Jun 2 09:29:43 2008 From: drc at virtualized.org (David Conrad) Date: Mon, 2 Jun 2008 07:29:43 -0700 Subject: Types of packet modifications allowed for networks In-Reply-To: <20080602101220.0ef77b8a@cs.columbia.edu> References: <4841CA4C.5020708@vaxination.ca> <20080602101220.0ef77b8a@cs.columbia.edu> Message-ID: <8657DFD7-A36B-4C2B-B8FA-4FCB15C26163@virtualized.org> > Only the end-to-end principle... Perhaps not relevant, but between any two consenting nodes, there can be severe mangling of headers as long as what comes out the other side looks pretty much the same as what went in. CSLIP is an example of this. Regards, -drc From matthew at eeph.com Mon Jun 2 09:35:20 2008 From: matthew at eeph.com (Matthew Kaufman) Date: Mon, 02 Jun 2008 07:35:20 -0700 Subject: UDP lossage (was: Types of packet modifications allowed for networks) In-Reply-To: References: Message-ID: <48440528.8010909@eeph.com> I was reminded by the "packet modifications" thread that it seems that dropping (rather than fragmenting) large UDP packets has become quite the norm, which is unfortunate. We're working on a (popular software) product that sends UDP datagrams (with DF cleared), and it is amazing how small they have to be to get through. Between the Cisco VPN software and the high-end NAT boxes that have broken hairpin behavior and broken consumer "routers", we're finding that whereas sizes in the mid 1400-byte range used to be safe, going much over 1200 bytes is now routinely a problem. Path MTU discovery (PLPMTUD) shouldn't need to be looking for and finding black holes when the DF flag is cleared, but that's what we're having to implement to work on today's Internet. Operational relevance: 1) This software will be running on your networks, and your customers will be happier if you don't drop UDP datagrams that are of reasonable size, 2) Knowing that this is going on might help you debug problems customers are having with other applications if you didn't know already how bad it has gotten. Matthew Kaufman matthew at eeph.com http://www.matthew.at From scott.berkman at reignmaker.net Mon Jun 2 09:39:45 2008 From: scott.berkman at reignmaker.net (Scott Berkman) Date: Mon, 2 Jun 2008 10:39:45 -0400 (EDT) Subject: NANOG NYC Event In-Reply-To: <20080601160956.22514.qmail@simone.iecc.com> Message-ID: <023101c8c4be$7d3b0770$0201a8c0@Reignmaker.local> For all the food everyone is listing you've missed the #1 NY food (opinion) ... Hot Dogs! Any street vendor will do (get a soft pretzel too) but I'm partial (like many New Yorkers) to Gray's Papaya in the city at least (their real website is "under construction so check out http://maps.google.com/maps?ie=UTF8&q=gray's+papaya&ll=40.75597,-73.968372 &spn=0.07737,0.117416&z=13). Another option is the original Nathan's on Coney Island. If you like steak, I love Peter Lugar's but if you want something a little cheaper and definitely less stuffy, check out Sammy's Romanian Steaks, not too far from the Williamsburg Bridge (157 Chrystie St). I also want to 2nd Little Italy and the NY Museum of Natural History/Hayden Planetarium as must sees if you've never been to NY. Also try to see a Broadway show, you can find last minute tickets for 1/2 off at TKTS (bring cash!!), but stay away from Time's Square to beat the lines and hit the one at the Southstreet Seaport (this is another cool place to check out anyway and very close to Brooklyn). Have Fun! -Scott -----Original Message----- From: John Levine [mailto:johnl at iecc.com] Sent: Sunday, June 01, 2008 12:10 PM To: nanog at nanog.org Subject: Re: NANOG NYC Event >Dinosaur is swell, but it's in Syracuse. > >Perhaps you could pick one that's reachable by subway instead. Oh, all right, as about 47 people have pointed out, they have a branch on 131st St. The barbeque is not bad. I eat it at the NY State Fair every year. On the other hand, I would think that in NYC, home of the most wonderful food on the continent,* you could do better than a branch of a yuppie ex biker joint from Syracuse. How about RUB at 23rd and 7th? Or Johnny Utah's at 51st and 5th? Or Oklahoma Smoke up at 145st St? R's, John * - with the possible exception of Montreal, an argument that can only be resolved by extensive research in both places No virus found in this incoming message. Checked by AVG. Version: 8.0.100 / Virus Database: 269.24.4/1476 - Release Date: 5/31/2008 12:25 PM From michael.dillon at bt.com Mon Jun 2 10:04:59 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Mon, 2 Jun 2008 16:04:59 +0100 Subject: NANOG NYC Event In-Reply-To: <023101c8c4be$7d3b0770$0201a8c0@Reignmaker.local> References: <20080601160956.22514.qmail@simone.iecc.com> <023101c8c4be$7d3b0770$0201a8c0@Reignmaker.local> Message-ID: > I also want to 2nd Little Italy ... And for proof that New York is constantly changing, check one of the newer Jewish neighborhoods in Brighton Beach, a little corner of the Soviet Union right on the edge of the USA. ;-) --Michael Dillon From johnl at iecc.com Mon Jun 2 10:45:37 2008 From: johnl at iecc.com (John Levine) Date: 2 Jun 2008 15:45:37 -0000 Subject: NANOG NYC Event In-Reply-To: <023101c8c4be$7d3b0770$0201a8c0@Reignmaker.local> Message-ID: <20080602154537.65896.qmail@simone.iecc.com> > I also want to 2nd Little Italy and the NY Museum of Natural >History/Hayden Planetarium as must sees if you've never been to NY. ... Considering the nerdy tendencies of this crowd, I can't see how one would omit a trip to the NYC Transit Museum, which chronicles the history of what was in the early 1900s quite the high tech marvel, and still the world's only urban railroad that runs 24/7/365, you know, like the Internet. It's at the corner of Boerum Place and Schermerhorn Street, about a five minute walk from the meeting. R's, John http://www.mta.info/mta/museum/ From hcb at netcases.net Mon Jun 2 11:07:34 2008 From: hcb at netcases.net (Howard C. Berkowitz) Date: Mon, 2 Jun 2008 12:07:34 -0400 Subject: NANOG NYC Event In-Reply-To: <023101c8c4be$7d3b0770$0201a8c0@Reignmaker.local> References: <20080601160956.22514.qmail@simone.iecc.com> <023101c8c4be$7d3b0770$0201a8c0@Reignmaker.local> Message-ID: <007f01c8c4ca$c58d5170$020fa8c0@HDESK1> Of course, there is always the question of what to put on the hot dog, and the mystic's reply: "make me one with everything." -----Original Message----- From: Scott Berkman [mailto:scott.berkman at reignmaker.net] Sent: Monday, June 02, 2008 10:40 AM To: nanog at nanog.org Subject: RE: NANOG NYC Event For all the food everyone is listing you've missed the #1 NY food (opinion) ... Hot Dogs! Any street vendor will do (get a soft pretzel too) but I'm partial (like many New Yorkers) to Gray's Papaya in the city at least (their real website is "under construction so check out http://maps.google.com/maps?ie=UTF8&q=gray's+papaya&ll=40.75597,-73.968372 &spn=0.07737,0.117416&z=13). Another option is the original Nathan's on Coney Island. If you like steak, I love Peter Lugar's but if you want something a little cheaper and definitely less stuffy, check out Sammy's Romanian Steaks, not too far from the Williamsburg Bridge (157 Chrystie St). I also want to 2nd Little Italy and the NY Museum of Natural History/Hayden Planetarium as must sees if you've never been to NY. Also try to see a Broadway show, you can find last minute tickets for 1/2 off at TKTS (bring cash!!), but stay away from Time's Square to beat the lines and hit the one at the Southstreet Seaport (this is another cool place to check out anyway and very close to Brooklyn). Have Fun! -Scott -----Original Message----- From: John Levine [mailto:johnl at iecc.com] Sent: Sunday, June 01, 2008 12:10 PM To: nanog at nanog.org Subject: Re: NANOG NYC Event >Dinosaur is swell, but it's in Syracuse. > >Perhaps you could pick one that's reachable by subway instead. Oh, all right, as about 47 people have pointed out, they have a branch on 131st St. The barbeque is not bad. I eat it at the NY State Fair every year. On the other hand, I would think that in NYC, home of the most wonderful food on the continent,* you could do better than a branch of a yuppie ex biker joint from Syracuse. How about RUB at 23rd and 7th? Or Johnny Utah's at 51st and 5th? Or Oklahoma Smoke up at 145st St? R's, John * - with the possible exception of Montreal, an argument that can only be resolved by extensive research in both places No virus found in this incoming message. Checked by AVG. Version: 8.0.100 / Virus Database: 269.24.4/1476 - Release Date: 5/31/2008 12:25 PM From sneak at datavibe.net Mon Jun 2 11:38:03 2008 From: sneak at datavibe.net (Rev. Jeffrey Paul) Date: Mon, 2 Jun 2008 09:38:03 -0700 Subject: [OFFTOPIC] Re: NANOG NYC Event In-Reply-To: References: <20080601035850.45405.qmail@simone.iecc.com> <20080601155440.GA47184@infiltrated.net> <20080601172710.R2829@AegisInfoSys.com> Message-ID: <20080602163803.GX24243@datavibe.net> On Mon, Jun 02, 2008 at 09:45:41AM -0400, David Diaz wrote: > Something Important to remember (I learned the hard way) > Cell phones do not work on the metro so remember > > A C F > JAY STREET STOP > > Those are the trains that stop on the back corner of the hotel. A&C are BLUE > LINE. F is BROWN i believe. F trains on maps are orange lines. Also, while this seems to have turned into the Newly Acclimated Newyork Olfactory Glee list, I'll chime in: Bereket... ( http://www.yelp.com/biz/bereket-turkish-kebab-house-new-york ) 187 E Houston (pronounced HOW-STON, not like the city in Texas, also aka 0th street) at Orchard street, right across the Williamsburg bridge in Manhattan ...has the best lamb kebabs I've ever had in my life, despite having grown up in the Metro Detroit area (which has a huge middle eastern population and tons of associated restaurants). They're open 24 hours and are easily my favorite restaurant in the tastiest-food category in the entire United States. Other POIs of interest to nanogers: Datavision on 5th avenue near 40th street (Manhattan) has saved me in a pinch when I've needed multimode cables (still dunno where to buy smf at a retail shop in nyc). Have fun in New York, it's my favorite city in America - I'd be there myself to play tour guide with everyone except I'm in ORD at the moment preparing for a transatlantic move for the summer (I'm coming back to NY in the fall). Most importantly, get out and roam around! Touristy things that everyone should see at least once: Herald Square (appx 34th st/6th ave) Times Square (~42s-49s, along 7a) Union Square (14s/4a) New York Harbor from Battery Park (take the 1 train in Manhattan all the way south to South Ferry, the last stop. Make sure you're in the first five front cars of the train. Get out, walk past the coast guard/dhs to the park, and go down to the water.) Good luck, -jp -- -------------------------------------------------------- Rev. Jeffrey Paul -datavibe- sneak at datavibe.net aim:x736e65616b pgp:0xD9B3C17D phone:1-800-403-1126 9440 0C7F C598 01CA 2F17 D098 0A3A 4B8F D9B3 C17D "Virtue is its own punishment." -------------------------------------------------------- From heather.schiller at verizonbusiness.com Mon Jun 2 11:41:43 2008 From: heather.schiller at verizonbusiness.com (Heather Schiller) Date: Mon, 02 Jun 2008 12:41:43 -0400 Subject: IPV6 network feeds In-Reply-To: <0133635B-04CB-4504-BB19-5B87A03B12F5@ca.afilias.info> References: <7BE7DCC779F2314686D61314E6E2215C048CB16D@TUS1XCHCLUPIN12.enterprise.veritas.com> <159448229-1211910382-cardhu_decombobulator_blackberry.rim.net-129631524-@bxe153.bisx.prod.on.blackberry> <0133635B-04CB-4504-BB19-5B87A03B12F5@ca.afilias.info> Message-ID: <484422C7.7060809@verizonbusiness.com> Joe Abley wrote: > > On 27 May 2008, at 17:45, charles at thewybles.com 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.. > > 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. > From ml at t-b-o-h.net Mon Jun 2 11:43:40 2008 From: ml at t-b-o-h.net (Tuc at T-B-O-H.NET) Date: Mon, 2 Jun 2008 12:43:40 -0400 (EDT) Subject: [OFFTOPIC] Re: NANOG NYC Event In-Reply-To: <20080602163803.GX24243@datavibe.net> Message-ID: <200806021643.m52GheEp090387@himinbjorg.tucs-beachin-obx-house.com> > > Datavision on 5th avenue near 40th street (Manhattan) has saved me in a > pinch when I've needed multimode cables (still dunno where to buy smf at > a retail shop in nyc). > Just be careful you pay 100% attention to what you want and what you get. I went for a disk drive, brought it upstairs, paid for it, and when they were checking it they found the item in the box wasn't the same I paid for (Serial numbers didn't match). I didn't even get out the store, so I asked for a refund. Store credit only, and its only good for a year. SIGH........ Tuc From jmaimon at ttec.com Mon Jun 2 12:36:32 2008 From: jmaimon at ttec.com (Joe Maimon) Date: Mon, 02 Jun 2008 13:36:32 -0400 Subject: [OFFTOPIC] Re: NANOG NYC Event In-Reply-To: <20080602163803.GX24243@datavibe.net> References: <20080601035850.45405.qmail@simone.iecc.com> <20080601155440.GA47184@infiltrated.net> <20080601172710.R2829@AegisInfoSys.com> <20080602163803.GX24243@datavibe.net> Message-ID: <48442FA0.9000200@ttec.com> > Other POIs of interest to nanogers: > > Datavision on 5th avenue near 40th street (Manhattan) has saved me in a > pinch when I've needed multimode cables (still dunno where to buy smf at > a retail shop in nyc). Chips and tech is around the corner on 39th between 5th and 6th. Datavision requires you to check your bags. They do have a pretty nice selection. From gds at gds.best.vwh.net Mon Jun 2 13:26:05 2008 From: gds at gds.best.vwh.net (Greg Skinner) Date: Mon, 2 Jun 2008 18:26:05 +0000 Subject: [OFFTOPIC] NANOG NYC Event In-Reply-To: <023101c8c4be$7d3b0770$0201a8c0@Reignmaker.local>; from scott.berkman@reignmaker.net on Mon, Jun 02, 2008 at 10:39:45AM -0400 References: <20080601160956.22514.qmail@simone.iecc.com> <023101c8c4be$7d3b0770$0201a8c0@Reignmaker.local> Message-ID: <20080602182605.B61350@gds.best.vwh.net> On Mon, Jun 02, 2008 at 10:39:45AM -0400, Scott Berkman wrote: > For all the food everyone is listing you've missed the #1 NY food > (opinion) ... Hot Dogs! It's been years since I've lived in NYC, and I haven't visited in a few years. I'd love to get a really good knish or slice of Sicilian pizza. --gregbo From sean at donelan.com Mon Jun 2 13:53:26 2008 From: sean at donelan.com (Sean Donelan) Date: Mon, 2 Jun 2008 14:53:26 -0400 (EDT) Subject: OLD root server IP addresses through history Message-ID: http://www.donelan.com/dnstimeline.html 1 Jun 1990 NIC.DDN.MIL 26.0.0.73 root service ends (last "original" root server) From eyeam at optonline.net Mon Jun 2 14:39:39 2008 From: eyeam at optonline.net (Eye Am) Date: Mon, 2 Jun 2008 14:39:39 -0500 Subject: NANOG NYC Event References: Message-ID: Read http://www.forgotten-ny.com/ before setting any agendas and if you have some time to spare, there is some awesome history to find. I lived there for nearly 20 years and it's endless the amazing things you can find just a short distance from anywhere. One of my stops is *always* the Dakotah and Strawbberry Fields followed by a walk through Central Park. Up on the Northwest side is the lake/castle that's a must see too. Right at 72nd and Columbus (close to the Dakotah) is the greatest pizzeria in NY. C. Genrich ----- Original Message ----- From: To: Sent: Monday, June 02, 2008 7:00 AM Subject: NANOG Digest, Vol 5, Issue 2 > Send NANOG mailing list submissions to > nanog at nanog.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://mailman.nanog.org/mailman/listinfo/nanog > or, via email, send a message with subject or body 'help' to > nanog-request at nanog.org > > You can reach the person managing the list at > nanog-owner at nanog.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of NANOG digest..." > > > Today's Topics: > > 1. Re: NANOG NYC Event (Brant I. Stevens) > 2. Re: NANOG NYC Event (J. Oquendo) > 3. Re: NANOG NYC Event (John Levine) > 4. Re: NANOG NYC Event (Fisher, Shawn) > 5. Re: NANOG NYC Event (Henry Yen) > 6. Comcast - Stuck route in Chicago directing MN traffic via > Denver (Eric Spaeth) > 7. Emerg data recovery recommdnations? (david raistrick) > 8. Re: IOS Rookit: the sky isn't falling (yet) (Christian) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 01 Jun 2008 11:39:43 -0400 > From: "Brant I. Stevens" > Subject: Re: NANOG NYC Event > To: John Levine , > Message-ID: > Content-Type: text/plain; charset="US-ASCII" > > > > > On 5/31/08 11:58 PM, "John Levine" wrote: > >> In article <43661d390805312028u130046ddlc804e4615c83ba62 at mail.gmail.com> >> you >> write: >>> I second the motion to recognize Dinosaur BBQ. All those in favor? >> >> Dinosaur is swell, but it's in Syracuse. >> >> Perhaps you could pick one that's reachable by subway instead. > > Dinosaur Barbecue > www.dinosaurbarbque.com > > 646 W 131st St > New York, NY 10027 > > It's in Harlem. BOOOOOOO!!!!! > >> >> >> >> > > > > > > ------------------------------ > > Message: 2 > Date: Sun, 1 Jun 2008 10:54:40 -0500 > From: "J. Oquendo" > Subject: Re: NANOG NYC Event > To: nanog at nanog.org > Message-ID: <20080601155440.GA47184 at infiltrated.net> > Content-Type: text/plain; charset=us-ascii > > On Sun, 01 Jun 2008, Brant I. Stevens wrote: > >> >> It's in Harlem. BOOOOOOO!!!!! >> > > So is Columbia University! > > Harlem is in the process of going through a > renaissance and has been over the past 10 or > more so things have changed for the better. > Just avoid going there after certain hours ;) > > As for the prior Brooklyn comment, Park Slope > also has some great eats but the area/scene > tends to be sort of artsy. If you want to spend > some time sightseeing Brooklyn, the Brooklyn > Public Library (main one) Grand Army Plaza is > near the Brooklyn Botanic Gardens. Don't forget > Coney Island which has also changed in the last > decade. Again, watch those hours, NY is a Jeckyll > and Hyde city. Nice sometimes, beautiful to visit > but can be insanely ugly. > > The downtown Brooklyn area has some nice eats > but I've always preferred the city. In the area > of downtown Brooklyn, you'll typically find a > bunch of people in local government and lawyers > eating as the courts are downtown. > > For those looking for sweets, don't forget the > ever famous (overhyped) Junior's Cheesecake. > If you've travelled to Coney Island then one > cannot forget Nathan's. There are some really > good pubs in the Red Hook section, but alas > again, going through certain neighborhoods is > not for everyone. You can jump on a Water Taxi > there for kicks though. Makes for nice pictures > at night. > > Sightseeing: Jump on a boat at night (booze > cruise) $25.00 > http://www.nywatertaxi.com/tours/happyhour/ > > Or just hop on an "On and Off" cruise: > http://www.nywatertaxi.com/hop/ > > $20.00 > > -- > =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ > J. Oquendo > SGFA #579 (FW+VPN v4.1) SGFE #574 (FW+VPN v4.1) > CEH/CNDA, CHFI > > "Experience hath shewn, that even under the best > forms (of government) those entrusted with power > have, in time, and by slow operations, perverted > it into tyranny." Thomas Jefferson > > wget -qO - www.infiltrated.net/sig|perl > > http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x3AC173DB > > > > > ------------------------------ > > Message: 3 > Date: 1 Jun 2008 16:09:56 -0000 > From: John Levine > Subject: Re: NANOG NYC Event > To: nanog at nanog.org > Message-ID: <20080601160956.22514.qmail at simone.iecc.com> > Content-Type: text/plain; charset=iso-8859-1 > >>Dinosaur is swell, but it's in Syracuse. >> >>Perhaps you could pick one that's reachable by subway instead. > > Oh, all right, as about 47 people have pointed out, they have a branch > on 131st St. The barbeque is not bad. I eat it at the NY State Fair > every year. > > On the other hand, I would think that in NYC, home of the most > wonderful food on the continent,* you could do better than a branch of > a yuppie ex biker joint from Syracuse. How about RUB at 23rd and 7th? > Or Johnny Utah's at 51st and 5th? Or Oklahoma Smoke up at 145st St? > > R's, > John > > * - with the possible exception of Montreal, an argument that can only > be resolved by extensive research in both places > > > > ------------------------------ > > Message: 4 > Date: Sun, 1 Jun 2008 12:57:31 -0400 > From: "Fisher, Shawn" > Subject: Re: NANOG NYC Event > To: , > Message-ID: > <21352038E7719F43A6D65B2D90B5256CCBFA34 at fossil.bresnan.com> > Content-Type: text/plain; charset="us-ascii" > > (Drifting further off topic). Another suggestion to add is the DUMBO area > of brooklyn, down under mahattanville overpass, easy to reach from > manhattan, take a nice stroll across the brooklyn bridge and your there, > lots of cool restaurants. Another bit of history, walk to montague > street, yes the montague street mr dylan sings about in tangled up in > blue. (some controversy over this) best way to walk is on the promenade > along the east river, great views of manhattan. Enjoy > -------------------------- > Sent using BlackBerry > > > -----Original Message----- > From: J. Oquendo > To: nanog at nanog.org > Sent: Sun Jun 01 11:54:40 2008 > Subject: Re: NANOG NYC Event > > On Sun, 01 Jun 2008, Brant I. Stevens wrote: > >> >> It's in Harlem. BOOOOOOO!!!!! >> > > So is Columbia University! > > Harlem is in the process of going through a > renaissance and has been over the past 10 or > more so things have changed for the better. > Just avoid going there after certain hours ;) > > As for the prior Brooklyn comment, Park Slope > also has some great eats but the area/scene > tends to be sort of artsy. If you want to spend > some time sightseeing Brooklyn, the Brooklyn > Public Library (main one) Grand Army Plaza is > near the Brooklyn Botanic Gardens. Don't forget > Coney Island which has also changed in the last > decade. Again, watch those hours, NY is a Jeckyll > and Hyde city. Nice sometimes, beautiful to visit > but can be insanely ugly. > > The downtown Brooklyn area has some nice eats > but I've always preferred the city. In the area > of downtown Brooklyn, you'll typically find a > bunch of people in local government and lawyers > eating as the courts are downtown. > > For those looking for sweets, don't forget the > ever famous (overhyped) Junior's Cheesecake. > If you've travelled to Coney Island then one > cannot forget Nathan's. There are some really > good pubs in the Red Hook section, but alas > again, going through certain neighborhoods is > not for everyone. You can jump on a Water Taxi > there for kicks though. Makes for nice pictures > at night. > > Sightseeing: Jump on a boat at night (booze > cruise) $25.00 > http://www.nywatertaxi.com/tours/happyhour/ > > Or just hop on an "On and Off" cruise: > http://www.nywatertaxi.com/hop/ > > $20.00 > > -- > =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ > J. Oquendo > SGFA #579 (FW+VPN v4.1) SGFE #574 (FW+VPN v4.1) > CEH/CNDA, CHFI > > "Experience hath shewn, that even under the best > forms (of government) those entrusted with power > have, in time, and by slow operations, perverted > it into tyranny." Thomas Jefferson > > wget -qO - www.infiltrated.net/sig|perl > > http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x3AC173DB > > > > > > ------------------------------ > > Message: 5 > Date: Sun, 1 Jun 2008 17:27:10 -0400 > From: Henry Yen > Subject: Re: NANOG NYC Event > To: nanog at nanog.org >Message-ID: <20080601172710.R2829 at AegisInfoSys.com> > Content-Type: text/plain; charset=us-ascii > > On Sun, Jun 01, 2008 at 10:54:40AM -0500, J. Oquendo wrote: >> As for the prior Brooklyn comment, Park Slope >> also has some great eats but the area/scene >> tends to be sort of artsy. >> >> The downtown Brooklyn area has some nice eats >> but I've always preferred the city. In the area >> of downtown Brooklyn, you'll typically find a >> bunch of people in local government and lawyers >> eating as the courts are downtown. >> >> For those looking for sweets, don't forget the >> ever famous (overhyped) Junior's Cheesecake. > > Disclaimer: I've worked in the immediate area of this conference on > and off for over 30 years. (In fact, I'm staring longingly down at > the Marriott Hotel from the office window right now...) > > First, you simply must take a walk across the Brooklyn Bridge to > Manhattan (and back). Exhilarating views, an unforgettable > experience, and you'd be participating in one of the more common > things that "all" NYC people do. Just walk out the "front" door of > the hotel and turn right. (Watch out for crazy bicyclists!) > > Second, Junior's Cheesecake, overhyped as it is, is still arguably > among the best "domestic" cheesecakes, at least on the east coast. > You really ought to try it. But, don't stop there -- the > brisket/corned-beef/pastrami on twin rolls is highly recommended. > (My personal favorite is their down-home matzoh-ball soup.) > > Third, the Brooklyn Heights area is admittedly "artsy", but there's > lots of interesting and tasty variety. I've had great food at > several Italian seafood-style places (although if that's your > preference, I'd encourage you to go to Vincent's in Little Italy > (lower Manhattan)). > > Finally, I didn't see a destination that seems like it might be very > useful: Radio Shack (go out the "back" door of the hotel, turn right, > half a block to Willoughby, turn right, and it's right across the street > from the White Castle (which is its own "destination")). > > P.S. If you're into bicycling, the Hudson River Park bikeway (runs about > 10 miles along the western Manhattan shoreline) is a paved, fantasitc, > ride. I don't know if the bike rental season has started yet, though. > > -- > Henry Yen Aegis Information Systems, > Inc. > Senior Systems Programmer Hicksville, New York > > > > ------------------------------ > > Message: 6 > Date: Sun, 01 Jun 2008 23:57:06 -0500 > From: Eric Spaeth > Subject: Comcast - Stuck route in Chicago directing MN traffic via > Denver > To: nanog at merit.edu > Message-ID: <48437DA2.9060100 at spaethco.com> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > For the last couple weeks there has been a route stuck in the Chicago > wan/core that is directing some Minnesota-bound traffic through Denver, > even though Chicago and the Roseville, MN aggregation remain up and > directly connected. This has the dual benefit of unnecessarily > increasing the load on Comcast's internal backbone as well as increasing > latency for Minnesota subscribers connecting to "east of the > Mississippi" destinations by ~20ms. > > I'm hoping Comcast engineers read this list, or someone in the carrier > community can help poke one of their Comcast contacts to help get this > resolved. > > Thanks in advance! > > "Wedged" route - 76.113.128.0/17 > Correct route - 69.180.128.0/18 > > Example trace from Chicago source to 76.113.128.0/17: > ========================================= > traceroute to 76.113.128.1 (76.113.128.1), 30 hops max, 40 byte packets > 1 69.65.40.62 (69.65.40.62) 0.542 ms 0.511 ms 0.508 ms > 2 so2-0-0-0.er1.Chi1.Servernap.net (69.39.239.169) 1.632 ms 1.642 > ms 2.121 ms > 3 ge-6-20.car1.Chicago1.Level3.net (4.79.65.49) 1.605 ms 1.608 ms > 1.619 ms > 4 ae-2-54.edge1.Chicago2.Level3.net (4.68.101.115) 1.604 ms 1.602 > ms 1.600 ms > 5 COMCAST-IP.edge1.Chicago2.Level3.net (4.71.248.26) 2.735 ms 2.741 > ms 2.739 ms > 6 pos-0-8-0-0-cr01.denver.co.ibone.comcast.net (68.86.85.114) 27.284 > ms 27.398 ms 27.387 ms > 7 te-9-4-ar02.roseville.mn.minn.comcast.net (68.86.91.154) 44.177 ms * * > 8 te-0-2-0-5-ar03.roseville.mn.minn.comcast.net (68.87.174.73) 28.352 > ms 28.352 ms 28.349 ms > 9 te-2-1-ur01.sims.mn.minn.comcast.net (68.87.174.74) 28.826 ms * * > 10 te-8-3-ur02.sims.mn.minn.comcast.net (68.87.174.78) 28.959 ms * * > 11 te-2-1-ur01.newport.mn.minn.comcast.net (68.87.174.82) 29.267 ms * > te-2-1-ur01.newport.mn.minn.comcast.net (68.87.174.82) 28.700 ms > 12 c-76-113-128-1.hsd1.mn.comcast.net (76.113.128.1) 28.638 ms 28.673 > ms 28.667 ms > ========================================= > > Example trace from Chicago source to working route 69.180.128.0/18 > ========================================= > traceroute to 69.180.130.1 (69.180.130.1), 30 hops max, 40 byte packets > 1 69.65.40.62 (69.65.40.62) 0.482 ms 0.450 ms 0.446 ms > 2 so2-0-0-0.er1.Chi1.Servernap.net (69.39.239.169) 1.595 ms 2.082 > ms 2.082 ms > 3 ge-6-20.car1.Chicago1.Level3.net (4.79.65.49) 1.568 ms 1.569 ms > 1.579 ms > 4 ae-2-52.edge1.Chicago2.Level3.net (4.68.101.51) 1.562 ms 1.563 ms > 1.560 ms > 5 COMCAST-IP.edge1.Chicago2.Level3.net (4.71.248.22) 2.708 ms 2.713 > ms 2.711 ms > 6 te-0-1-0-7-ar03.roseville.mn.minn.comcast.net (68.87.174.21) 13.144 > ms 11.919 ms 11.877 ms > 7 68.87.174.22 (68.87.174.22) 11.824 ms * * > 8 te-8-3-ur02.brooklynpark.mn.minn.comcast.net (68.87.174.26) 12.333 > ms * * > 9 te-2-1-ur01.newhope.mn.minn.comcast.net (68.87.174.30) 12.012 ms * * > 10 c-3-0-ubr02.newhope.mn.minn.comcast.net (69.180.130.1) 11.963 ms > 12.018 ms 11.973 ms > ========================================= > > -Eric > > > > ------------------------------ > > Message: 7 > Date: Mon, 2 Jun 2008 09:04:24 +0000 (UTC) > From: david raistrick > Subject: Emerg data recovery recommdnations? > To: nanog at nanog.org > Message-ID: > Content-Type: TEXT/PLAIN; format=flowed; charset=us-ascii > > > guys, > > wrong place, I know, but network down is network down no matter which side > of the cable it falls on... > > Can anyone give any solid recommendations for a data recovery service who > can fly to our site to extract data from a f'ed up RAID array? > > It's an absolute emergency (for us, of course). > > offlist please. > > .d > > > > --- > david raistrick http://www.netmeister.org/news/learn2quote.html > drais at icantclick.org http://www.expita.com/nomime.html > > > > > ------------------------------ > > Message: 8 > Date: Mon, 2 Jun 2008 07:47:56 -0400 > From: Christian > Subject: Re: IOS Rookit: the sky isn't falling (yet) > To: "Fred Reimer" > Cc: nanog at nanog.org > Message-ID: > <9b62cf2f0806020447r10fc3ed0i6be793d6db694fb at mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > here's the slides if anyone hasn't seen > > http://seclists.org/fulldisclosure/2008/May/att-0668/EuSecWest_presentation_ppt > > On Thu, May 29, 2008 at 11:27 AM, Fred Reimer wrote: > >> New keys, to be stored on the crypto chip, would presumably be delivered >> in >> a separately signed package using a master key that would not change >> (embedded within the chip). Maybe Cisco even doesn't have this key, and >> would need to send a revocation or new public key to be stored on the >> chip >> to the chip manufacturer, who would sign it with the master private key >> and >> which then could be delivered in a software update to the system. There >> are >> many possibilities, and no crypto scheme is foolproof. That much has >> been >> proven. But no, you would not make the on-chip EEPROM of the crypto chip >> "flashable" in the normal meaning of the word. You would send the chip a >> pointer to a buffer that contains a signed update key, and the chip >> itself >> would verify that signature and only then program the updated key(s). >> >> My intention was not to turn nanog into a crypto forum. I'd be much more >> interested in any unique methods that people use to harden their systems >> that have not already been widely distributed through vendor or industry >> best practices. >> >> Fred Reimer, CISSP, CCNP, CQS-VPN, CQS-ISS >> Senior Network Engineer >> Coleman Technologies, Inc. >> 954-298-1697 >> >> >> > -----Original Message----- >> > From: Jim Wise [mailto:jwise at draga.com] >> > Sent: Thursday, May 29, 2008 11:10 AM >> > To: Fred Reimer >> > Cc: Jared Mauch; nanog at nanog.org >> > Subject: RE: IOS Rookit: the sky isn't falling (yet) >> > >> > -----BEGIN PGP SIGNED MESSAGE----- >> > Hash: SHA1 >> > >> > On Thu, 29 May 2008, Fred Reimer wrote: >> > >> > >The code would presumably be run upon boot from a non-flashable >> > source, >> > >which would run the boot ROM code through a check on the crypto chip >> > and >> > >only execute it if it passed. You would not put the code that checks >> > the >> > >boot ROM on the boot ROM. The new crypto chip would presumably have >> > the >> > >initial boot code, which would only be designed to check the boot ROM >> > >signature and nothing else so presumably would never need to be >> > replaced and >> > >hence would be designed to be non-flashable. >> > >> > Doesn't this just push the chicken-and-egg problem up the chain one >> > step? >> > The ROMMON would be flashable (among other reasons) because the key >> > used to >> > sign IOS releases should change over the years -- gaining length as >> > cycles >> > get cheaper, being replaced periodically to prevent use of the same key >> > for >> > too long, and perhaps being revoked if it should ever be compromised. >> > >> > If the ROMMON is itself to be verified by a prior, non-flashable ROM, >> > then >> > all the same arguments would call for making its key-list updatable -- >> > and >> > given the time-in-service seen by many such devices, any weakness in >> > that >> > key list would be around for quite some time. >> > >> > - -- >> > Jim Wise >> > jwise at draga.com >> > -----BEGIN PGP SIGNATURE----- >> > Version: GnuPG v1.4.9 (NetBSD) >> > >> > iD8DBQFIPsdRq/KRbT0KwbwRAkcmAJ4xOBtANHOc+C/fzL+7PvgWnjp76ACfSGUw >> > 43+1Pq3xWS4MagWzdetZ0ws= >> > =62gJ >> > -----END PGP SIGNATURE----- >> > > > ------------------------------ > > _______________________________________________ > NANOG mailing list > NANOG at nanog.org > http://mailman.nanog.org/mailman/listinfo/nanog > > > End of NANOG Digest, Vol 5, Issue 2 > *********************************** > From tony at lava.net Mon Jun 2 14:52:51 2008 From: tony at lava.net (Antonio Querubin) Date: Mon, 2 Jun 2008 09:52:51 -1000 (HST) Subject: IPV6 network feeds In-Reply-To: <484422C7.7060809@verizonbusiness.com> References: <7BE7DCC779F2314686D61314E6E2215C048CB16D@TUS1XCHCLUPIN12.enterprise.veritas.com> <159448229-1211910382-cardhu_decombobulator_blackberry.rim.net-129631524-@bxe153.bisx.prod.on.blackberry> <0133635B-04CB-4504-BB19-5B87A03B12F5@ca.afilias.info> <484422C7.7060809@verizonbusiness.com> Message-ID: 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 From heather.schiller at verizonbusiness.com Mon Jun 2 15:31:42 2008 From: heather.schiller at verizonbusiness.com (Heather Schiller) Date: Mon, 02 Jun 2008 16:31:42 -0400 Subject: IPV6 network feeds In-Reply-To: References: <7BE7DCC779F2314686D61314E6E2215C048CB16D@TUS1XCHCLUPIN12.enterprise.veritas.com> <159448229-1211910382-cardhu_decombobulator_blackberry.rim.net-129631524-@bxe153.bisx.prod.on.blackberry> <0133635B-04CB-4504-BB19-5B87A03B12F5@ca.afilias.info> <484422C7.7060809@verizonbusiness.com> Message-ID: <484458AE.5020607@verizonbusiness.com> 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 ~*~*~*~*~*~*~*~*~*~*~*~ From joly at punkcast.com Mon Jun 2 16:11:45 2008 From: joly at punkcast.com (WWWhatsup) Date: Mon, 02 Jun 2008 17:11:45 -0400 Subject: NANOG NYC Event In-Reply-To: References: <20080601160956.22514.qmail@simone.iecc.com> <023101c8c4be$7d3b0770$0201a8c0@Reignmaker.local> Message-ID: <20080602211143.D8B8221397@spunkymail-a9.g.dreamhost.com> >> I also want to 2nd Little Italy ... It's hard to choose from the plethora of Italian Restaurants on Mulberry St, imcidentally just a $8 cab ride, or even a leisurely stroll, across the Manhattan Bridge from NANOG, but I, as an area resident, swear by Da Nico (close to Broome). --------------------------------------------------------------- WWWhatsup NYC http://pinstand.com - http://punkcast.com --------------------------------------------------------------- From hannigan at verneglobal.com Mon Jun 2 16:24:00 2008 From: hannigan at verneglobal.com (Martin Hannigan) Date: Mon, 2 Jun 2008 21:24:00 -0000 Subject: NANOG NYC Event References: <20080601160956.22514.qmail@simone.iecc.com><023101c8c4be$7d3b0770$0201a8c0@Reignmaker.local> <20080602211143.D8B8221397@spunkymail-a9.g.dreamhost.com> Message-ID: I'll probably be at 83rd and Amsterdam by 11p, This is my all time NYC favorite. http://www.hi-life.com/west.html If you're here on Thurs or beyond: http://www.hi-life.com/west-ipod-lounge.html NYC is so large and interesing that I wouldn't spend much time chasing food. You're in foodie heaven. See the Statute of Liberty, the 9/11 memorial, Empire State Building, ride the subway, go to Hoboken, or catch a glimpse of the UN. All great sites. Personally, I'd like to find a karaoke bar and sing "NY NY" with my Red Sox hat on. :-) Best, -M< -- Martin Hannigan hannigan at verneglobal.com Verne Global http://www.verneglobal.com Keflavik, Iceland ________________________________ From: WWWhatsup [mailto:joly at punkcast.com] Sent: Mon 02-Jun-08 17:11 To: nanog at nanog.org Subject: RE: NANOG NYC Event >> I also want to 2nd Little Italy ... It's hard to choose from the plethora of Italian Restaurants on Mulberry St, imcidentally just a $8 cab ride, or even a leisurely stroll, across the Manhattan Bridge from NANOG, but I, as an area resident, swear by Da Nico (close to Broome). --------------------------------------------------------------- WWWhatsup NYC http://pinstand.com - http://punkcast.com --------------------------------------------------------------- From oberman at es.net Mon Jun 2 16:29:04 2008 From: oberman at es.net (Kevin Oberman) Date: Mon, 02 Jun 2008 14:29:04 -0700 Subject: NANOG NYC Event In-Reply-To: Your message of "Mon, 02 Jun 2008 21:24:00 -0000." Message-ID: <20080602212904.7A5AB4500F@ptavv.es.net> > Date: Mon, 2 Jun 2008 21:24:00 -0000 > From: "Martin Hannigan" > > > > I'll probably be at 83rd and Amsterdam by 11p, This is my all time NYC favorite. > > http://www.hi-life.com/west.html > > If you're here on Thurs or beyond: > > http://www.hi-life.com/west-ipod-lounge.html > > NYC is so large and interesing that I wouldn't spend much time chasing > food. You're in foodie heaven. See the Statute of Liberty, the 9/11 > memorial, Empire State Building, ride the subway, go to Hoboken, or > catch a glimpse of the UN. All great sites. Personally, I'd like to > find a karaoke bar and sing "NY NY" with my Red Sox hat on. :-) Marty, You are probably one of the few who might just get away with that! It would be fun to watch, though I would bring my ear-plugs, just to be safe. :-o -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman at es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 224 bytes Desc: not available URL: From ml at t-b-o-h.net Mon Jun 2 16:33:21 2008 From: ml at t-b-o-h.net (Tuc at T-B-O-H.NET) Date: Mon, 2 Jun 2008 17:33:21 -0400 (EDT) Subject: NANOG NYC Event In-Reply-To: <20080602212904.7A5AB4500F@ptavv.es.net> Message-ID: <200806022133.m52LXLl6095195@himinbjorg.tucs-beachin-obx-house.com> > NYC is so large and interesing that I wouldn't spend much time chasing > food. You're in foodie heaven. See the Statute of Liberty, the 9/11 > memorial, Empire State Building, ride the subway, go to Hoboken, or > catch a glimpse of the UN. All great sites. Personally, I'd like to > find a karaoke bar and sing "NY NY" with my Red Sox hat on. :-) > Why hasn't anyone talking about putting together a trip to the various datacenters in the area.... 25 Broadway... 111 8th... and the grandaddy of them all... 60 Hudson. Tuc From Valdis.Kletnieks at vt.edu Mon Jun 2 16:42:36 2008 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 02 Jun 2008 17:42:36 -0400 Subject: NANOG NYC Event In-Reply-To: Your message of "Mon, 02 Jun 2008 17:33:21 EDT." <200806022133.m52LXLl6095195@himinbjorg.tucs-beachin-obx-house.com> References: <200806022133.m52LXLl6095195@himinbjorg.tucs-beachin-obx-house.com> Message-ID: <121453.1212442956@turing-police.cc.vt.edu> On Mon, 02 Jun 2008 17:33:21 EDT, "Tuc at T-B-O-H.NET" said: > Why hasn't anyone talking about putting together a trip to the various > datacenters in the area.... 25 Broadway... 111 8th... and the grandaddy of > them all... 60 Hudson. http://www.answers.com/topic/busman-s-holiday -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From mikal at stillhq.com Mon Jun 2 17:36:54 2008 From: mikal at stillhq.com (Michael Still) Date: Mon, 02 Jun 2008 15:36:54 -0700 Subject: Large number of DNS probes in last 24 hours In-Reply-To: References: <4840BF61.5000906@stillhq.com> Message-ID: <48447606.2070006@stillhq.com> Jim Wise wrote: > On Fri, 30 May 2008, Michael Still wrote: >> I have seen PlanetLab experiments doing this. What are the originating >> IP addresses? > > Three observed source addresses > > 208.78.169.237 > 204.11.51.62 > 194.199.24.101 > > Source ports are high and non-repeating. Other than the domain root, > A-record queries for "google.com" and for hostnames which appear to be > on the same subnet as the querying host. Hmmm. All the PlanetLab nodes should have valid reverse DNS, which isn't the case here, so I guess it is something more malicious. Mikal From lionair at samsung.com Mon Jun 2 19:15:12 2008 From: lionair at samsung.com (=?euc-kr?B?waTEob+1?=) Date: Tue, 03 Jun 2008 00:15:12 +0000 (GMT) Subject: Network trend and right planning Message-ID: <9949816.159521212452112680.JavaMail.weblogic@epml17> Hi all, I'm going to make a medium term (4~5 years) plan of our IP core/backbone network. Currently our backbone network is providing MPLS L3 VPN service and internet access service. Most of our platform is based on c7500 or 6509 (sup3 base). it is the right time we have to change our platform and service structure. Nowadays, most of people (network admin & vendor) say that current trend is data and voice convergence or Ethernet based MPLS backbone, qos for multimedia service. but I wonder those things would really provide our customers more value and give us more profit. and then It doesn't seem to be in demands yet. every customers don't want to pay more for qos and they don't care which technique is applied on their circuit. I would like to make more realistic plan from the viewpoint of customer needs. Could anyone advice me where I can get useful reference about that ? best regards Chiyoung ============================================= Chi-Young Joung SAMSUNG NETWORKS Inc. Email: lionair at samsung.com Tel +82 70 7015 0623, Mobile +82 17 520 9193 Fax +82 70 7016 0031 ============================================= From christian at visr.org Mon Jun 2 21:09:46 2008 From: christian at visr.org (Christian) Date: Mon, 2 Jun 2008 22:09:46 -0400 Subject: NANOG NYC Event In-Reply-To: References: <20080601160956.22514.qmail@simone.iecc.com> <023101c8c4be$7d3b0770$0201a8c0@Reignmaker.local> <20080602211143.D8B8221397@spunkymail-a9.g.dreamhost.com> Message-ID: <9b62cf2f0806021909r3a284d71mdcb32969c774f2a3@mail.gmail.com> hilife is a great spot!! On Mon, Jun 2, 2008 at 5:24 PM, Martin Hannigan wrote: > > > I'll probably be at 83rd and Amsterdam by 11p, This is my all time NYC > favorite. > > http://www.hi-life.com/west.html > > If you're here on Thurs or beyond: > > http://www.hi-life.com/west-ipod-lounge.html > > NYC is so large and interesing that I wouldn't spend much time chasing > food. You're in foodie heaven. See the Statute of Liberty, the 9/11 > memorial, Empire State Building, ride the subway, go to Hoboken, or catch a > glimpse of the UN. All great sites. Personally, I'd like to find a karaoke > bar and sing "NY NY" with my Red Sox hat on. :-) > > Best, > > > -M< > > > -- > Martin Hannigan hannigan at verneglobal.com hannigan at verneglobal.com> > Verne Global http://www.verneglobal.com < > http://www.verneglobal.com/> > Keflavik, Iceland > > ________________________________ > > From: WWWhatsup [mailto:joly at punkcast.com] > Sent: Mon 02-Jun-08 17:11 > To: nanog at nanog.org > Subject: RE: NANOG NYC Event > > > > > > >> I also want to 2nd Little Italy ... > > It's hard to choose from the plethora of Italian Restaurants on Mulberry > St, > imcidentally just a $8 cab ride, or even a leisurely stroll, across the > Manhattan Bridge from NANOG, > but I, as an area resident, swear by Da Nico (close to Broome). > > > > --------------------------------------------------------------- > WWWhatsup NYC > http://pinstand.com - http://punkcast.com < > http://punkcast.com/> > --------------------------------------------------------------- > > > > > > From sandy at tislabs.com Tue Jun 3 09:09:00 2008 From: sandy at tislabs.com (Sandy Murphy) Date: Tue, 3 Jun 2008 10:09:00 -0400 (EDT) Subject: NANOG 43 attendees: plans to attend organ concert Message-ID: <20080603140900.8B7993F46F@pecan.tislabs.com> I am sending this message on Ole's behalf, because he's not signed up for nanog. I'm cc-ing him, so replies as well might go to him. Those of you who were at the community meeting on Sunday may recall Ole mentioning the organ site near the LA meeting in Oct. (Think I got that right.) Ole is an organ enthusiast. There is an organ in a church on Montague street that is having a concert today at 1:10pm. Ole is planning to attend and suggests that anyone who wants to go with him should assemble at the bottom of the escalator in the lower lobby, to leave promptly at 1:00pm. Promptly. Details: Church of St. Ann & the Holy Trinity 157 Montague Street Brooklyn, New York 11201 718-875-6960 Really detailed organ info: http://www.nycago.org/Organs/Bkln/html/StAnnHolyTrinity.html --Sandy From sandy at tislabs.com Tue Jun 3 09:46:06 2008 From: sandy at tislabs.com (Sandy Murphy) Date: Tue, 3 Jun 2008 10:46:06 -0400 (EDT) Subject: NANOG 43 attendees: plans to attend organ concert Message-ID: <20080603144606.264D43F438@pecan.tislabs.com> Forwarding a correction from Ole: Oops, the time/date for the concert is WEDNESDAY, June 4 @ 1:10pm. (not today). By the way, the "organ site near the LA meeting" is the Walt Disney Concert Hall which houses an amazing instrument, see: http://www.rosales.com/instruments/op24/opus24slide/FrameSet.htm More on that later... Ole http://www.organdemo.info Ole J. Jacobsen Editor and Publisher, The Internet Protocol Journal Cisco Systems Tel: +1 408-527-8972 Mobile: +1 415-370-4628 E-mail: ole at cisco.com URL: http://www.cisco.com/ipj --Sandy From todd at renesys.com Tue Jun 3 10:55:52 2008 From: todd at renesys.com (Todd Underwood) Date: Tue, 3 Jun 2008 15:55:52 +0000 Subject: [NANOG-announce] NANOG43 survey for on-site and remote attendees Message-ID: <20080603155552.GZ6599@renesys.com> They survey for NANOG43 is currently available at: http://www.surveymonkey.com/s.aspx?sm=cv7fRvxyfEFSR2ds8Tvm8w_3d_3d the Program Committee and (speaking for them) Steering Committee of NANOG desperately want to know what you think about this NANOG so that we might use that feedback in the planning for future NANOGs. so whether you are attending on-site or via the webcast, please take a couple of minutes to fill out the survey. thanks! todd NANOG PC chair -- _____________________________________________________________________ todd underwood +1 603 643 9300 x101 renesys corporation general manager babbledog todd at renesys.com http://www.renesys.com/blog _______________________________________________ NANOG-announce mailing list NANOG-announce at nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-announce From tglassey at earthlink.net Tue Jun 3 11:06:33 2008 From: tglassey at earthlink.net (TS Glassey) Date: Tue, 3 Jun 2008 09:06:33 -0700 Subject: Querstions about COGENT and their services... Message-ID: <019201c8c593$cc742fd0$0200a8c0@tsg1> So at one time Cogent was one of the lowest performing bandwidth providers. Anyone have any responses to their current operations? regards, Todd Glassey CISM CIFI Chief Scientist/Founder - Certichron Inc TGlassey at Wireless-Time.COM 650-796-8178 From david at davidcoulson.net Tue Jun 3 11:10:26 2008 From: david at davidcoulson.net (David Coulson) Date: Tue, 03 Jun 2008 12:10:26 -0400 Subject: Querstions about COGENT and their services... In-Reply-To: <019201c8c593$cc742fd0$0200a8c0@tsg1> References: <019201c8c593$cc742fd0$0200a8c0@tsg1> Message-ID: <48456CF2.5070100@davidcoulson.net> There have been a few discussions over the last few months on Cogent - Seems the response is mixed, depending if you're on Cogent or old PSINet facilities. My experience has been that you get what you pay for - They're the cheapest, that's for sure. I've not heard anything about them in the last couple of months, but the last year has been filled with almost monthly service outages or congestion. David TS Glassey wrote: > So at one time Cogent was one of the lowest performing bandwidth > providers. Anyone have any responses to their current operations? From cstone at axint.net Tue Jun 3 11:15:32 2008 From: cstone at axint.net (Chris Stone) Date: Tue, 3 Jun 2008 10:15:32 -0600 Subject: Querstions about COGENT and their services... In-Reply-To: <019201c8c593$cc742fd0$0200a8c0@tsg1> References: <019201c8c593$cc742fd0$0200a8c0@tsg1> Message-ID: <200806031015.37256.cstone@axint.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday 03 June 2008 10:06:33 am TS Glassey wrote: > So at one time Cogent was one of the lowest performing bandwidth providers. > Anyone have any responses to their current operations? > > regards, > Todd Glassey CISM CIFI > Chief Scientist/Founder - Certichron Inc > TGlassey at Wireless-Time.COM > 650-796-8178 We've been using them for 5 years now with no problems other than a crack in the fiber which was not their fault and that they fixed within an hour or so. Used them for 3 years before that, with another company, and had no problems their either. The only real issue was the couple of times the peering between L3 and Cogent was stopped - which was really, IMNTBHO, the fault of both parties. I was able to route around this when it occurred, so was not a significant issue at the time. - -- Chris Stone, MCSE Vice President, CTO AxisInternet, Inc. http://www.axint.net DSL, dialup, hosting, email filtering, co-location, online backup Phone: +1 303 592 2947 x302 (office) +1 303 570 6947 (cell) - ------------------------------------------------------------------------- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkhFbiQACgkQnSVip47FEdOJ1gCfdk/vYUBU4MfC9zi3zgOSjW4H oAIAoIdiJlVmy1KbVm99PZ5J0CjVYRr6 =Pg8h -----END PGP SIGNATURE----- From herrin-nanog at dirtside.com Tue Jun 3 11:25:37 2008 From: herrin-nanog at dirtside.com (William Herrin) Date: Tue, 3 Jun 2008 12:25:37 -0400 Subject: Querstions about COGENT and their services... In-Reply-To: <019201c8c593$cc742fd0$0200a8c0@tsg1> References: <019201c8c593$cc742fd0$0200a8c0@tsg1> Message-ID: <3c3e3fca0806030925p14bc6788kd73083f2922e2d09@mail.gmail.com> On Tue, Jun 3, 2008 at 12:06 PM, TS Glassey wrote: > So at one time Cogent was one of the lowest performing bandwidth providers. > Anyone have any responses to their current operations? They got into a spat with Telia a few months back. Severed those portions of the Internet that they serve from each other for about a week, disrupting all customers who depended on them exclusively. Similar situation with Cogent and Level 3 a couple years ago. I wouldn't count on it not to happen again. They're dirt cheap. If you have an ability to control the routing of your non-interactive traffic (such as email and downloads), Cogent can save you big bucks. If you have three upstreams and one of them isn't Cogent, you may be missing a trick. I don't think I'd pick them as my #1 or #2. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From dhubbard at dino.hostasaurus.com Tue Jun 3 11:35:42 2008 From: dhubbard at dino.hostasaurus.com (David Hubbard) Date: Tue, 3 Jun 2008 12:35:42 -0400 Subject: Querstions about COGENT and their services... Message-ID: From: David Coulson [mailto:david at davidcoulson.net] > > There have been a few discussions over the last few months on > Cogent - Seems the response is mixed, depending if you're on > Cogent or old PSINet facilities. My experience has been that > you get what you pay for - They're the cheapest, that's for > sure. I've not heard anything about them in the last couple > of months, but the last year has been filled with almost > monthly service outages or congestion. > > David > Similar experience here, we had them as one of our five upstreams for web hosting traffic for two years. We'd get regular complaints from customers about slow sites and trace it back to their traffic involving the cogent link so we began prepending three times to cogents peers in an attempt to only see traffic to and from cogent customers use that link under normal circumstances, but there were still enough regular issues that we dropped them a few months ago. Their bgp community support encompasses maybe four things you can set too, it's next to nothing. David From nanog at data102.com Tue Jun 3 12:06:06 2008 From: nanog at data102.com (randal k) Date: Tue, 3 Jun 2008 11:06:06 -0600 Subject: Querstions about COGENT and their services... In-Reply-To: <019201c8c593$cc742fd0$0200a8c0@tsg1> References: <019201c8c593$cc742fd0$0200a8c0@tsg1> Message-ID: We've had Cogent for going on three years now, and they've been nothing but exceptional across the board. Our sales guy is excellent - attentive but not overbearing. We've had one easily-resolved billing issue, and their team got us squared away on one call. Their tech support has been phenomenal for us - we've only had to call a few times (all BGP emergencies on our end, not theirs), but every time it was single-call, single-person response; having an empowered network guy answer the phone is extremely refreshing. Our multiple email tickets have always been immediately responded to and closed within 24 hours. Also, the bang for the buck is out of this world. Our only complaint, and I do mean /only/ complaint is that they are ~25% of our traffic and not more (we peer w/ TWTelecom & Level3 as well). Dear Cogent, please peer more/better and we'll give you more money. As someone else said, if you have three peers, Cogent had better be one of them or you're missing out. Cheers, Randal On Tue, Jun 3, 2008 at 10:06 AM, TS Glassey wrote: > So at one time Cogent was one of the lowest performing bandwidth providers. > Anyone have any responses to their current operations? > > regards, > Todd Glassey CISM CIFI > Chief Scientist/Founder - Certichron Inc > TGlassey at Wireless-Time.COM > 650-796-8178 > > From mike at sentex.net Tue Jun 3 12:32:17 2008 From: mike at sentex.net (Mike Tancsa) Date: Tue, 03 Jun 2008 13:32:17 -0400 Subject: Querstions about COGENT and their services... In-Reply-To: <48456CF2.5070100@davidcoulson.net> References: <019201c8c593$cc742fd0$0200a8c0@tsg1> <48456CF2.5070100@davidcoulson.net> Message-ID: <200806031732.m53HWIVh029511@lava.sentex.ca> At 12:10 PM 6/3/2008, David Coulson wrote: >the cheapest, that's for sure. I've not heard anything about them in >the last couple of months, but the last year has been filled with >almost monthly service outages or congestion. They are also one of the biggest providers... Proportionally speaking, if they had the same percentage of failures as a provider 10% of their size, it would appear Cogent is "worse" as there would be more reports. Also, in my experience, I find Cogent pretty good about admitting to outages, even if we didnt notice it. Some providers on the other hand do everything possible to hide any issues... Cogent's pricing in Canada is not that far off from a number of other providers I could choose from so to say "you get what you pay for" misses a bit of detail. They are not the cheapest, but in that price range, I like the service they offer and have found them a relatively reliable provider. There are other "premiere" / "Tier 1" providers that I found gave worse service, had billing that would drive my AP people crazy and were far more difficult to deal with from a trouble ticket perspective. ---Mike From mjkelly at gmail.com Tue Jun 3 12:41:50 2008 From: mjkelly at gmail.com (Matt Kelly) Date: Tue, 3 Jun 2008 13:41:50 -0400 Subject: Querstions about COGENT and their services... In-Reply-To: <019201c8c593$cc742fd0$0200a8c0@tsg1> References: <019201c8c593$cc742fd0$0200a8c0@tsg1> Message-ID: <9D520409-AF57-48DF-A5E5-4F5C364ADBA7@gmail.com> Try getting a credit from Cogent on a billing error, it's impossible. Every single credit must be approved by the CEO as told to me by the billing director located in DC. Their network is oversold and they can't supply what they promise. It's one thing to offer service cheap, it's a whole other to offer cheap service. Good luck if you choose to use them. --Matt On Jun 3, 2008, at 12:06 PM, TS Glassey wrote: > So at one time Cogent was one of the lowest performing bandwidth > providers. Anyone have any responses to their current operations? > > regards, > Todd Glassey CISM CIFI > Chief Scientist/Founder - Certichron Inc > TGlassey at Wireless-Time.COM > 650-796-8178 > From tme at multicasttech.com Tue Jun 3 12:40:30 2008 From: tme at multicasttech.com (Marshall Eubanks) Date: Tue, 3 Jun 2008 13:40:30 -0400 Subject: Querstions about COGENT and their services... In-Reply-To: References: <019201c8c593$cc742fd0$0200a8c0@tsg1> Message-ID: <20626FF4-02F9-478D-97B4-89AC75CE8FCB@multicasttech.com> I have been very pleased with our service from Cogent. Regards Marshall On Jun 3, 2008, at 1:06 PM, randal k wrote: > We've had Cogent for going on three years now, and they've been > nothing but exceptional across the board. Our sales guy is excellent - > attentive but not overbearing. We've had one easily-resolved billing > issue, and their team got us squared away on one call. Their tech > support has been phenomenal for us - we've only had to call a few > times (all BGP emergencies on our end, not theirs), but every time it > was single-call, single-person response; having an empowered network > guy answer the phone is extremely refreshing. Our multiple email > tickets have always been immediately responded to and closed within 24 > hours. Also, the bang for the buck is out of this world. > > Our only complaint, and I do mean /only/ complaint is that they are > ~25% of our traffic and not more (we peer w/ TWTelecom & Level3 as > well). Dear Cogent, please peer more/better and we'll give you more > money. > > As someone else said, if you have three peers, Cogent had better be > one of them or you're missing out. > > Cheers, > Randal > > On Tue, Jun 3, 2008 at 10:06 AM, TS Glassey > wrote: >> So at one time Cogent was one of the lowest performing bandwidth >> providers. >> Anyone have any responses to their current operations? >> >> regards, >> Todd Glassey CISM CIFI >> Chief Scientist/Founder - Certichron Inc >> TGlassey at Wireless-Time.COM >> 650-796-8178 >> >> > From jmaimon at ttec.com Tue Jun 3 13:08:57 2008 From: jmaimon at ttec.com (Joe Maimon) Date: Tue, 03 Jun 2008 14:08:57 -0400 Subject: Querstions about COGENT and their services... In-Reply-To: <019201c8c593$cc742fd0$0200a8c0@tsg1> References: <019201c8c593$cc742fd0$0200a8c0@tsg1> Message-ID: <484588B9.8040104@ttec.com> Beware their max-prefix limits, they dont appear to reset automatically. If you want to be able to do any TE with de-aggregation, make sure their prefix limit is high enough. I have had complaints about their performance to AOL and others. Joe TS Glassey wrote: > So at one time Cogent was one of the lowest performing bandwidth > providers. Anyone have any responses to their current operations? > > regards, > Todd Glassey CISM CIFI > Chief Scientist/Founder - Certichron Inc > TGlassey at Wireless-Time.COM > 650-796-8178 > > From david at davidcoulson.net Tue Jun 3 13:12:19 2008 From: david at davidcoulson.net (David Coulson) Date: Tue, 03 Jun 2008 14:12:19 -0400 Subject: Querstions about COGENT and their services... In-Reply-To: <200806031732.m53HWIVh029511@lava.sentex.ca> References: <019201c8c593$cc742fd0$0200a8c0@tsg1> <48456CF2.5070100@davidcoulson.net> <200806031732.m53HWIVh029511@lava.sentex.ca> Message-ID: <48458983.5050901@davidcoulson.net> Mike Tancsa wrote: > They are also one of the biggest providers... Proportionally speaking, > if they had the same percentage of failures as a provider 10% of their > size, it would appear Cogent is "worse" as there would be more > reports. Also, in my experience, I find Cogent pretty good about > admitting to outages, even if we didnt notice it. Some providers on > the other hand do everything possible to hide any issues... Sorry - I don't buy the "They're big, so they have more problems". I've never seen the frequency of network issues with any Tier 1 (for want of a better nomenclature) that I have seen with Cogent. Admitting a problem does not help when their facilities do not have enough capacity to route around the failure of one of their POPs. > Cogent's pricing in Canada is not that far off from a number of other > providers I could choose from so to say "you get what you pay for" > misses a bit of detail. They are not the cheapest, but in that price > range, I like the service they offer and have found them a relatively > reliable provider. There are other "premiere" / "Tier 1" providers > that I found gave worse service, had billing that would drive my AP > people crazy and were far more difficult to deal with from a trouble > ticket perspective. Cogent have been 50% cheaper than most other providers I have used, as far as raw IP services go. They have also had exponentially more network issues than other transit providers. Usually it's stuff that makes life difficult, such as a failure at a POP that causes congestion somewhere else - I'd be okay if their local POP died and took out my BGP session, but alas that only happened once when they blew some breakers one day. David From nanog at grrrrreg.net Tue Jun 3 13:55:27 2008 From: nanog at grrrrreg.net (Greg VILLAIN) Date: Tue, 3 Jun 2008 20:55:27 +0200 Subject: Querstions about COGENT and their services... In-Reply-To: <019201c8c593$cc742fd0$0200a8c0@tsg1> References: <019201c8c593$cc742fd0$0200a8c0@tsg1> Message-ID: <0BCE32F6-91CC-4307-AB78-A1C0B911C074@grrrrreg.net> On Jun 3, 2008, at 6:06 PM, TS Glassey wrote: > So at one time Cogent was one of the lowest performing bandwidth > providers. Anyone have any responses to their current operations? > > regards, > Todd Glassey CISM CIFI > Chief Scientist/Founder - Certichron Inc > TGlassey at Wireless-Time.COM > 650-796-8178 > Couple remarks on their reputation in europe, I've never had Cogent transit, so this requires further investigation. They're the cheapest (cost-wise, I wouldn't venture to say technically- wise) in Europe, that's a fact. They often get into peering clashes against major actors, they've recently been in that situation with Telia, in the past with France's incumbent (Orange), Level 3 has also depeered them in the past, this is due to them being brokers and is inherent to their pricing policy - it certainly will keep happening to them in the future. The above point is from my perspective a show-stopper, but a good strategy I've very often heard from some of their customers is to use them to forward traffic towards exotic locations, where QoS is not an issue, or where revenue is not critical. Their IP core is supposedly a patch-work resulting from their numerous past acquisitions (PSINet, Lambdanet to name a few), which can explain the many outages they have. Still, the sales people in Europe are really kind, comprehensive and caring people, which makes it a little better, I suppose :) Hope this helped. Greg VILLAIN Independant internet architect From hardenrm at uiuc.edu Tue Jun 3 14:23:11 2008 From: hardenrm at uiuc.edu (Ryan Harden) Date: Tue, 03 Jun 2008 14:23:11 -0500 Subject: Querstions about COGENT and their services... In-Reply-To: <0BCE32F6-91CC-4307-AB78-A1C0B911C074@grrrrreg.net> References: <019201c8c593$cc742fd0$0200a8c0@tsg1> <0BCE32F6-91CC-4307-AB78-A1C0B911C074@grrrrreg.net> Message-ID: <48459A1F.7080009@uiuc.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Overall Cogent has been okay. We've had a few issues over the last several months. One specifically bothersome as it cropped up several times. They basically kept rewriting their CoPP ACLs and kept dropping my side of the /30 from the allow list. This caused our BGP session to start flapping. Each time this happened it took several hours to escalate to someone that understood the problem and could get it fixed. Not even referencing old tickets would help their first line of Support. On one call an engineer told me BGP was flapping because my config was split into "address-family ipv4/ipv6 unicast/multicast" rather than one big "router bgp" stanza. We have a session with AT&T, so when Cogent does something stupid, we aren't off the net... Other than bidding for a contract in a building they didn't actually have any resources, then trying to get us to pay for the costs of building out there after they won....And the sales rep quitting right after they won the RFP....they've been decent. /Ryan Greg VILLAIN wrote: | | On Jun 3, 2008, at 6:06 PM, TS Glassey wrote: |> So at one time Cogent was one of the lowest performing bandwidth |> providers. Anyone have any responses to their current operations? |> |> regards, |> Todd Glassey CISM CIFI |> Chief Scientist/Founder - Certichron Inc |> TGlassey at Wireless-Time.COM |> 650-796-8178 |> | | | Couple remarks on their reputation in europe, I've never had Cogent | transit, so this requires further investigation. | They're the cheapest (cost-wise, I wouldn't venture to say | technically-wise) in Europe, that's a fact. | They often get into peering clashes against major actors, they've | recently been in that situation with Telia, in the past with France's | incumbent (Orange), Level 3 has also depeered them in the past, this is | due to them being brokers and is inherent to their pricing policy - it | certainly will keep happening to them in the future. | The above point is from my perspective a show-stopper, but a good | strategy I've very often heard from some of their customers is to use | them to forward traffic towards exotic locations, where QoS is not an | issue, or where revenue is not critical. | Their IP core is supposedly a patch-work resulting from their numerous | past acquisitions (PSINet, Lambdanet to name a few), which can explain | the many outages they have. | Still, the sales people in Europe are really kind, comprehensive and | caring people, which makes it a little better, I suppose :) | Hope this helped. | | Greg VILLAIN | Independant internet architect - -- Ryan M. Harden, BS, KC9IHX Office: 217-265-5192 CITES - Network Engineering Cell: 630-363-0365 2130 Digital Computer Lab Fax: 217-244-7089 1304 W. Springfield email: hardenrm at uiuc.edu Urbana, IL 61801 University of Illinois - Urbana/Champaign ~ - All your Base - -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIRZoftuPckBBbXboRAlJ6AJ0aoeBv/xrzr/rPkIqKSIpwGuHwQQCgz0N8 b0q2Lag9Z5a5OpxPoKINzHQ= =ARib -----END PGP SIGNATURE----- From scott.berkman at reignmaker.net Tue Jun 3 14:37:35 2008 From: scott.berkman at reignmaker.net (Scott Berkman) Date: Tue, 3 Jun 2008 15:37:35 -0400 (EDT) Subject: Querstions about COGENT and their services... In-Reply-To: <0BCE32F6-91CC-4307-AB78-A1C0B911C074@grrrrreg.net> Message-ID: <030f01c8c5b1$4315bb00$0201a8c0@Reignmaker.local> Don't forget AOL in the list of companies they have de-peered (or have been de-peered from) in the past, as this was big at the time. I personally think that arguably the Level 3 spat had the biggest impact (at least in the US, I know that was a bad day here). This all comes back to Cogent's views of the size and traffic patterns on their own network. They often think of themselves as a Tier 1 network and are perceived to act that way, even though most of the companies they "peer" with are actually transit providers. As far as I know, all of their "spats" have been billing disputes where they were trying to force other carriers into settlement-free peering arrangements, even though the carriers saw the traffic patterns on the Cogent links as pretty heavily swayed to one side. It seems that there are lots of little T2/T3 ISPs that have Cogent as primary or balanced transit, but very little content takes its primary path over Cogent's network. This is why Cogent gets a bad name with many people in the industry. Some call it aggressive business tactics and some just call it wrong, you choose for yourself. I would not ever want them as my primary (and certainly not my choice for single-homed connections), but not because of performance but instead due to fear of being cut off or "segmented" the next time they try to make a stand. It is a good idea to have them included in a long list not only due to price, but also to ensure you can reach their customers if/when the next spat happens. Just my 2 cents, -Scott -----Original Message----- From: Greg VILLAIN [mailto:nanog at grrrrreg.net] Sent: Tuesday, June 03, 2008 2:55 PM To: nanog list Subject: Re: Querstions about COGENT and their services... On Jun 3, 2008, at 6:06 PM, TS Glassey wrote: > So at one time Cogent was one of the lowest performing bandwidth > providers. Anyone have any responses to their current operations? > > regards, > Todd Glassey CISM CIFI > Chief Scientist/Founder - Certichron Inc TGlassey at Wireless-Time.COM > 650-796-8178 > Couple remarks on their reputation in europe, I've never had Cogent transit, so this requires further investigation. They're the cheapest (cost-wise, I wouldn't venture to say technically- wise) in Europe, that's a fact. They often get into peering clashes against major actors, they've recently been in that situation with Telia, in the past with France's incumbent (Orange), Level 3 has also depeered them in the past, this is due to them being brokers and is inherent to their pricing policy - it certainly will keep happening to them in the future. The above point is from my perspective a show-stopper, but a good strategy I've very often heard from some of their customers is to use them to forward traffic towards exotic locations, where QoS is not an issue, or where revenue is not critical. Their IP core is supposedly a patch-work resulting from their numerous past acquisitions (PSINet, Lambdanet to name a few), which can explain the many outages they have. Still, the sales people in Europe are really kind, comprehensive and caring people, which makes it a little better, I suppose :) Hope this helped. Greg VILLAIN Independant internet architect No virus found in this incoming message. Checked by AVG. Version: 8.0.100 / Virus Database: 269.24.6/1480 - Release Date: 6/3/2008 7:00 AM From rs at seastrom.com Tue Jun 3 15:18:06 2008 From: rs at seastrom.com (Robert E. Seastrom) Date: Tue, 03 Jun 2008 16:18:06 -0400 Subject: Querstions about COGENT and their services... In-Reply-To: (randal k.'s message of "Tue, 3 Jun 2008 11:06:06 -0600") References: <019201c8c593$cc742fd0$0200a8c0@tsg1> Message-ID: <863anu5l35.fsf@seastrom.com> "randal k" writes: > We've had Cogent for going on three years now, and they've been > nothing but exceptional across the board. Our sales guy is excellent - > attentive but not overbearing. Must not be Joe Kusa then. He managed to get Cogent onto my "do not buy from these spamming SOBs" list by adding me to their "send out marketing updates" list without my permission. Also never misses a chance to ring me up to "touch base" and "stay in touch". Last time we talked I told him in no uncertain terms that I didn't want to hear from him again. He seemed unclear on why what he did was wrong. Oh well, ---Rob From mike at m5computersecurity.com Tue Jun 3 17:52:39 2008 From: mike at m5computersecurity.com (Michael J McCafferty) Date: Tue, 03 Jun 2008 15:52:39 -0700 Subject: Querstions about COGENT and their services... In-Reply-To: <019201c8c593$cc742fd0$0200a8c0@tsg1> References: <019201c8c593$cc742fd0$0200a8c0@tsg1> Message-ID: <1212533559.18798.317.camel@mike-desktop> Todd, I once had that same question. I bought FastE from Cogent almost a year ago for out of band management of our production gear. But, I put up a couple of old Celerons running Smokeping up, pinging the same 37 remote networks. One server on Cogent, and one on our colo providers super-wicked-premium-route-science network. Before I started this experiment, I had a very low opinion of Cogent. Since then I have been absolutely happy with them. You will note that if you look at the same graphs between on the two, the super-jam-route-science network is only a very slight bit faster and in some cases it is not. Cogent support is surprisingly good. A person who can resolve you issue is the person who answers the phone. You are not transferred 9 times to get the the right person. There is no eternal hold. I can't answer any questions regarding BGP with them as we are not doing BGP with them yet. This is scheduled, however. Ask me again in a few months. If you question is regarding ping times, then here is the evidence: Smoke1 is on the Colo's "blended" network: http://smoke1.m5hosting.com/cgi-bin/smokeping.cgi?target=World.USA.FaceBook Smoke2 is single FastE to Cogent only. No redundancy: http://smoke2.m5hosting.com/cgi-bin/smokeping.cgi?target=World.USA.FaceBook Can't use them as a single provider though. They have those peering fights and periodic maintenance. If you need 99.999% then you need to have more than one carrier anyway. Cheers, Mike On Tue, 2008-06-03 at 09:06 -0700, TS Glassey wrote: > So at one time Cogent was one of the lowest performing bandwidth providers. > Anyone have any responses to their current operations? > > regards, > Todd Glassey CISM CIFI > Chief Scientist/Founder - Certichron Inc > TGlassey at Wireless-Time.COM > 650-796-8178 > > -- ************************************************************ Michael J. McCafferty Principal, Security Engineer M5 Hosting http://www.m5hosting.com You can have your own custom Dedicated Server up and running today ! RedHat Enterprise, CentOS, Ubuntu, Debian, OpenBSD, FreeBSD, and more ************************************************************ From Keith_Mitchell at isc.org Tue Jun 3 18:10:15 2008 From: Keith_Mitchell at isc.org (Keith Mitchell) Date: Tue, 03 Jun 2008 19:10:15 -0400 Subject: REMINDER: DNS Operations Meeting, Brooklyn NY 4/5th June In-Reply-To: <483C78B0.6010903@isc.org> References: <47FD0BF9.7020306@isc.org> <482B0166.6050604@isc.org> <483C78B0.6010903@isc.org> Message-ID: <4845CF57.3070408@isc.org> A final reminder that this meeting will be taking place tomorrow, and we still have some space for anyone who wishes to attend. The meeting will be held in Brooklyn College, NY, about 30 mins by subway from the NANOG venue. Meeting information and an agenda are at: http://public.oarci.net/dns-operations/workshop-2008/ Keith Mitchell OARC Programme Manager From andrewy at webair.com Tue Jun 3 18:43:27 2008 From: andrewy at webair.com (andrew young) Date: Tue, 03 Jun 2008 19:43:27 -0400 Subject: NANOG NYC Event In-Reply-To: <21352038E7719F43A6D65B2D90B5256CCBFA34@fossil.bresnan.com> References: <21352038E7719F43A6D65B2D90B5256CCBFA34@fossil.bresnan.com> Message-ID: <1212536608.16920.14.camel@andrewy-desktop> i really hope everyone takes the time to walk over the brooklyn bridge into manhattan. its a pretty awesome view and experience. - ------------------------------------ Andrew Young Webair Internet Development, Inc Phone: 1 866 WEBAIR 1 FAX: 516.938.5100 http://www.webair.com andrewy at webair.com ------------------------------------- We are interested in any feedback you might have about the service you received. Please contact our technical support consumer care manager directly at 1.866.WEBAIR1 or e-mail customercare at webair.com ------------------------------------- On Sun, 2008-06-01 at 12:57 -0400, Fisher, Shawn wrote: > (Drifting further off topic). Another suggestion to add is the DUMBO area of brooklyn, down under mahattanville overpass, easy to reach from manhattan, take a nice stroll across the brooklyn bridge and your there, lots of cool restaurants. Another bit of history, walk to montague street, yes the montague street mr dylan sings about in tangled up in blue. (some controversy over this) best way to walk is on the promenade along the east river, great views of manhattan. Enjoy > -------------------------- > Sent using BlackBerry > > > -----Original Message----- > From: J. Oquendo > To: nanog at nanog.org > Sent: Sun Jun 01 11:54:40 2008 > Subject: Re: NANOG NYC Event > > On Sun, 01 Jun 2008, Brant I. Stevens wrote: > > > > > It's in Harlem. BOOOOOOO!!!!! > > > > So is Columbia University! > > Harlem is in the process of going through a > renaissance and has been over the past 10 or > more so things have changed for the better. > Just avoid going there after certain hours ;) > > As for the prior Brooklyn comment, Park Slope > also has some great eats but the area/scene > tends to be sort of artsy. If you want to spend > some time sightseeing Brooklyn, the Brooklyn > Public Library (main one) Grand Army Plaza is > near the Brooklyn Botanic Gardens. Don't forget > Coney Island which has also changed in the last > decade. Again, watch those hours, NY is a Jeckyll > and Hyde city. Nice sometimes, beautiful to visit > but can be insanely ugly. > > The downtown Brooklyn area has some nice eats > but I've always preferred the city. In the area > of downtown Brooklyn, you'll typically find a > bunch of people in local government and lawyers > eating as the courts are downtown. > > For those looking for sweets, don't forget the > ever famous (overhyped) Junior's Cheesecake. > If you've travelled to Coney Island then one > cannot forget Nathan's. There are some really > good pubs in the Red Hook section, but alas > again, going through certain neighborhoods is > not for everyone. You can jump on a Water Taxi > there for kicks though. Makes for nice pictures > at night. > > Sightseeing: Jump on a boat at night (booze > cruise) $25.00 > http://www.nywatertaxi.com/tours/happyhour/ > > Or just hop on an "On and Off" cruise: > http://www.nywatertaxi.com/hop/ > > $20.00 > From Valdis.Kletnieks at vt.edu Tue Jun 3 19:38:30 2008 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 03 Jun 2008 20:38:30 -0400 Subject: NANOG NYC Event In-Reply-To: Your message of "Tue, 03 Jun 2008 19:43:27 EDT." <1212536608.16920.14.camel@andrewy-desktop> References: <21352038E7719F43A6D65B2D90B5256CCBFA34@fossil.bresnan.com> <1212536608.16920.14.camel@andrewy-desktop> Message-ID: <36079.1212539910@turing-police.cc.vt.edu> On Tue, 03 Jun 2008 19:43:27 EDT, andrew young said: > i really hope everyone takes the time to walk over the brooklyn bridge > into manhattan. its a pretty awesome view and experience. Are you allowed to bring a camera along to record the experience, or is NYC worried about terrorist geeks? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From feldman at twincreeks.net Tue Jun 3 21:13:53 2008 From: feldman at twincreeks.net (Steve Feldman) Date: Tue, 3 Jun 2008 22:13:53 -0400 Subject: NANOG NYC Event In-Reply-To: <36079.1212539910@turing-police.cc.vt.edu> References: <21352038E7719F43A6D65B2D90B5256CCBFA34@fossil.bresnan.com> <1212536608.16920.14.camel@andrewy-desktop> <36079.1212539910@turing-police.cc.vt.edu> Message-ID: <94C5C536-D66F-43C3-8EF8-FECCC71B8A18@twincreeks.net> On Jun 3, 2008, at 8:38 PM, Valdis.Kletnieks at vt.edu wrote: > On Tue, 03 Jun 2008 19:43:27 EDT, andrew young said: >> i really hope everyone takes the time to walk over the brooklyn >> bridge >> into manhattan. its a pretty awesome view and experience. > > Are you allowed to bring a camera along to record the experience, or > is NYC > worried about terrorist geeks? No need to worry. I kept having to dodge tourists taking photos and videos as I walked across this evening. Steve From christian at visr.org Tue Jun 3 21:51:32 2008 From: christian at visr.org (Christian) Date: Tue, 3 Jun 2008 22:51:32 -0400 Subject: NANOG NYC - Lost Macbook Charger Message-ID: <9b62cf2f0806031951i138eec3cp561cf94e4d97f395@mail.gmail.com> Hi All - I seem to have left my macbook charger behind tonight - most likely in the main conference room 2nd or 3rd row in the back to the right If anyone happened to see it or pick it up, please let me know, thanks! Christian Koch Quality Technology Services From tomb at byrneit.net Tue Jun 3 22:38:19 2008 From: tomb at byrneit.net (Tomas L. Byrnes) Date: Tue, 3 Jun 2008 20:38:19 -0700 Subject: NANOG NYC Event In-Reply-To: <94C5C536-D66F-43C3-8EF8-FECCC71B8A18@twincreeks.net> References: <21352038E7719F43A6D65B2D90B5256CCBFA34@fossil.bresnan.com><1212536608.16920.14.camel@andrewy-desktop><36079.1212539910@turing-police.cc.vt.edu> <94C5C536-D66F-43C3-8EF8-FECCC71B8A18@twincreeks.net> Message-ID: <70D072392E56884193E3D2DE09C097A9F1BB@pascal.zaphodb.org> Perhaps the NYPD are not worried about Geeks bearing Gifs? > -----Original Message----- > From: Steve Feldman [mailto:feldman at twincreeks.net] > Sent: Tuesday, June 03, 2008 7:14 PM > To: Valdis.Kletnieks at vt.edu > Cc: nanog at nanog.org; Fisher, Shawn > Subject: Re: NANOG NYC Event > > > On Jun 3, 2008, at 8:38 PM, Valdis.Kletnieks at vt.edu wrote: > > > On Tue, 03 Jun 2008 19:43:27 EDT, andrew young said: > >> i really hope everyone takes the time to walk over the brooklyn > >> bridge into manhattan. its a pretty awesome view and experience. > > > > Are you allowed to bring a camera along to record the > experience, or > > is NYC worried about terrorist geeks? > > No need to worry. I kept having to dodge tourists taking > photos and videos as I walked across this evening. > Steve > > > From briand at ca.afilias.info Wed Jun 4 00:21:30 2008 From: briand at ca.afilias.info (briand at ca.afilias.info) Date: Wed, 4 Jun 2008 01:21:30 -0400 (EDT) Subject: www.nanog.org agenda link broken Message-ID: <49808.72.255.3.101.1212556890.squirrel@webmail.afilias.info> I'm getting agenda.html -> agenda.html/ (which does not exist) -> 404 on the nanog.org website. (Yes, I reported it to nanog-support). In case anyone who can fix it is reading: It'd be nice if the agenda page were to start working again while the meeting is still going on. :-) (I'd comment on when that is, but I can't seem to see the agenda online. ;-)) Brian From bmanning at vacation.karoshi.com Wed Jun 4 01:11:54 2008 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Wed, 4 Jun 2008 06:11:54 +0000 Subject: OLD root server IP addresses through history In-Reply-To: References: Message-ID: <20080604061154.GA22474@vacation.karoshi.com.> On Mon, Jun 02, 2008 at 02:53:26PM -0400, Sean Donelan wrote: > > > http://www.donelan.com/dnstimeline.html > > 1 Jun 1990 > NIC.DDN.MIL 26.0.0.73 root service ends (last "original" root server) it would much more helpful to have citations for your dates. --bill From sean at donelan.com Wed Jun 4 09:20:33 2008 From: sean at donelan.com (Sean Donelan) Date: Wed, 4 Jun 2008 10:20:33 -0400 (EDT) Subject: OLD root server IP addresses through history In-Reply-To: <20080604061154.GA22474@vacation.karoshi.com.> References: <20080604061154.GA22474@vacation.karoshi.com.> Message-ID: On Wed, 4 Jun 2008, bmanning at vacation.karoshi.com wrote: > On Mon, Jun 02, 2008 at 02:53:26PM -0400, Sean Donelan wrote: >> >> >> http://www.donelan.com/dnstimeline.html >> >> 1 Jun 1990 >> NIC.DDN.MIL 26.0.0.73 root service ends (last "original" root server) > > > it would much more helpful to have citations for your > dates. Most of the dates came from the Namedroppers mailing list archives. A few came from other mailing lists or newspaper articles at the time. But my actual question, which I neglected to include, Is Net-26 still seeing queries to the 26.0.0.73 root after 18 years? From joelja at bogus.com Wed Jun 4 09:27:40 2008 From: joelja at bogus.com (Joel Jaeggli) Date: Wed, 04 Jun 2008 07:27:40 -0700 Subject: OLD root server IP addresses through history In-Reply-To: References: <20080604061154.GA22474@vacation.karoshi.com.> Message-ID: <4846A65C.4070002@bogus.com> Sean Donelan wrote: > But my actual question, which I neglected to include, Is Net-26 still > seeing queries to the 26.0.0.73 root after 18 years? 26/8 doesn't appear in the routing table. so unless it's getting queries from inside the dod all those packets should fall on the floor the first time they hit a router without default. From bmanning at vacation.karoshi.com Wed Jun 4 10:55:40 2008 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Wed, 4 Jun 2008 15:55:40 +0000 Subject: OLD root server IP addresses through history In-Reply-To: References: <20080604061154.GA22474@vacation.karoshi.com.> Message-ID: <20080604155540.GA27779@vacation.karoshi.com.> On Wed, Jun 04, 2008 at 10:20:33AM -0400, Sean Donelan wrote: > On Wed, 4 Jun 2008, bmanning at vacation.karoshi.com wrote: > >On Mon, Jun 02, 2008 at 02:53:26PM -0400, Sean Donelan wrote: > >> > >> > >>http://www.donelan.com/dnstimeline.html > >> > >>1 Jun 1990 > >>NIC.DDN.MIL 26.0.0.73 root service ends (last "original" root server) > > > > > > it would much more helpful to have citations for your > > dates. > > Most of the dates came from the Namedroppers mailing list archives. A few > came from other mailing lists or newspaper articles at the time. > > But my actual question, which I neglected to include, Is Net-26 still > seeing queries to the 26.0.0.73 root after 18 years? i can see net 26, but will have to get an answer from someone else. --bill From PhillipSLoveless at DRS-PCT.COM Wed Jun 4 11:21:04 2008 From: PhillipSLoveless at DRS-PCT.COM (Loveless, Phillip S.) Date: Wed, 4 Jun 2008 11:21:04 -0500 Subject: AT&T Outage? Message-ID: I'm getting 100% packet loss out of NYC heading to Comcast.. anyone else seeing anything? _______________________________________________ Phillip S. Loveless DRS Power & Control Technologies 21 South Street Danbury, CT 06810 -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 3286 bytes Desc: image001.jpg URL: From PhillipSLoveless at DRS-PCT.COM Wed Jun 4 11:27:36 2008 From: PhillipSLoveless at DRS-PCT.COM (Loveless, Phillip S.) Date: Wed, 4 Jun 2008 11:27:36 -0500 Subject: AT&T Outage? Message-ID: Update: 4 785 ms 245 ms 781 ms gbr5.n54ny.ip.att.net [12.123.202.130] 5 756 ms 759 ms 787 ms tbr1.n54ny.ip.att.net [12.122.11.9] 6 * * * Request timed out. 7 729 ms 737 ms 699 ms 64.212.107.97 8 * * * Request timed out. 9 682 ms 688 ms 331 ms COMCAST-IP-SERVICES-LLC-New-York.TenGigabitEther et9-2.ar4.NYC1.gblx.net [64.213.77.218] 10 667 ms 673 ms 674 ms te-0-1-0-0-crs01.plainfield.nj.panjde.comcast.ne [68.85.192.37] 11 * * * Request timed out. 12 710 ms 696 ms 709 ms te-1-1-ur02.mtlaurel.nj.panjde.comcast.net [68.8 .192.42] 13 * * * Request timed out. 14 * * * Request timed out. 15 * * * Request timed out. _______________________________________________ Phillip S. Loveless From PhillipSLoveless at DRS-PCT.COM Wed Jun 4 11:30:06 2008 From: PhillipSLoveless at DRS-PCT.COM (Loveless, Phillip S.) Date: Wed, 4 Jun 2008 11:30:06 -0500 Subject: AT&T Outage? References: Message-ID: Same coming out of the mid-west also. 4 12.122.96.5 584 msec 788 msec 784 msec 5 192.205.34.62 816 msec 632 msec 616 msec 6 ae-15-51.car1.Atlanta2.Level3.net (4.68.103.10) 712 msec 808 msec 860 msec 7 COMCAST-IP.car1.Atlanta2.Level3.net (4.71.252.6) 784 msec 840 msec 784 msec 8 pos-0-8-0-0-cr01.mclean.va.ibone.comcast.net (68.86.85.70) 736 msec 820 msec 784 msec 9 pos-0-0-0-0-cr01.philadelphia.pa.ibone.comcast.net (68.86.85.6) 796 msec 844 msec 852 msec 10 be-40-crs01.401nbroadst.pa.panjde.comcast.net (68.86.208.33) 872 msec 804 ms ec 696 msec 11 pos-0-7-0-0-crs01.ivyland.pa.panjde.comcast.net (68.85.192.202) 748 msec 824 msec * 12 te-0-1-0-0-crs01.plainfield.nj.panjde.comcast.net (68.85.192.37) 700 msec 74 0 msec 784 msec 13 te-1-1-ur01.mtlaurel.nj.panjde.comcast.net (68.85.192.38) 824 msec 848 msec 864 msec 14 te-1-1-ur02.mtlaurel.nj.panjde.comcast.net (68.85.192.42) 800 msec 768 msec 716 msec 15 te-1-1-ur01.arneysmount.nj.panjde.comcast.net (68.85.192.46) 680 msec 692 ms ec 828 msec 16 GE-0-1-ubr01.arneysmount.nj.panjde.comcast.net (68.86.223.118) 824 msec 800 msec 816 msec 17 * * * 18 * * * 19 * * * 20 * * * 21 * * * 22 * * * 23 * * * 24 * * * 25 * * * 26 * * * 27 * * * 28 * * * 29 * * * 30 * * * -----Original Message----- From: Loveless, Phillip S. [mailto:PhillipSLoveless at DRS-PCT.COM] Sent: Wednesday, June 04, 2008 12:28 PM To: nanog at merit.edu Subject: AT&T Outage? Update: 4 785 ms 245 ms 781 ms gbr5.n54ny.ip.att.net [12.123.202.130] 5 756 ms 759 ms 787 ms tbr1.n54ny.ip.att.net [12.122.11.9] 6 * * * Request timed out. 7 729 ms 737 ms 699 ms 64.212.107.97 8 * * * Request timed out. 9 682 ms 688 ms 331 ms COMCAST-IP-SERVICES-LLC-New-York.TenGigabitEther et9-2.ar4.NYC1.gblx.net [64.213.77.218] 10 667 ms 673 ms 674 ms te-0-1-0-0-crs01.plainfield.nj.panjde.comcast.ne [68.85.192.37] 11 * * * Request timed out. 12 710 ms 696 ms 709 ms te-1-1-ur02.mtlaurel.nj.panjde.comcast.net [68.8 .192.42] 13 * * * Request timed out. 14 * * * Request timed out. 15 * * * Request timed out. _______________________________________________ Phillip S. Loveless From jra at baylink.com Wed Jun 4 12:21:40 2008 From: jra at baylink.com (Jay R. Ashworth) Date: Wed, 4 Jun 2008 13:21:40 -0400 Subject: amazonaws.com? In-Reply-To: <483EAADF.5040905@bogus.com> References: <483D8240.2080602@decarta.com> <483D8990.50609@decarta.com> <982D8D05B6407A49AD506E6C3AC8E7D626E4FBE470@caralain.haven.nynaeve.net> <2ee691ff0805281013x45d13650p2edf19568091798a@mail.gmail.com> <18494.7752.530297.196323@world.std.com> <2ee691ff0805290556q4c86f507udca8bd401c126744@mail.gmail.com> <483EAADF.5040905@bogus.com> Message-ID: <20080604172140.GO31805@cgi.jachomes.com> On Thu, May 29, 2008 at 06:08:47AM -0700, Joel Jaeggli wrote: > Dorn Hetzel wrote: > >There is a really huge difference in the ease with which payment from a > >credit card can be reversed if fraudulent, and the amount of effort > >necessary to reverse a wire transfer. I won't go so far as to say that > >reversing a wire transfer is impossible, but I would claim it's many orders > >of magnitude harder than the credit card reversal. > > To paraphrase one of my colleagues from the user interaction world: > > "The key to offering a compelling service is minimising > transaction hassles." > > I encourage all my competitors to implement inconvenient hard to use > payment methods.... I do too. If all of your competitors uniformly make it just enough harder for Bad Actors to rent servers from which to Act Bad, then we'll *know* where it's coming from, and what to do about it -- and why (you wanted to make more money). See also "Tragedy Of The Commons". Cheers, -- jra -- Jay R. Ashworth jra at baylink.com Designer +-Internetworking------+---------+ RFC 2100 Ashworth & Associates | Best Practices Wiki | | '87 e24 St Petersburg FL USA +-http://bestpractices.wikia.com-+ +1 727 647 1274 If you can read this... thank a system administrator. Or two. --me From jra at baylink.com Wed Jun 4 12:25:28 2008 From: jra at baylink.com (Jay R. Ashworth) Date: Wed, 4 Jun 2008 13:25:28 -0400 Subject: amazonaws.com? In-Reply-To: <483EF1A0.9080103@bogus.com> References: <18494.7752.530297.196323@world.std.com> <2ee691ff0805290556q4c86f507udca8bd401c126744@mail.gmail.com> <483EAADF.5040905@bogus.com> <5218D1934E787843B5235E139DE0E0300650F565@PUR-EXCH03VS1.ox.com> <2ee691ff0805290622k19a15e20m2e2488698986ade0@mail.gmail.com> <483EB3C8.30301@bogus.com> <18494.56703.315361.140476@world.std.com> <483EF1A0.9080103@bogus.com> Message-ID: <20080604172528.GP31805@cgi.jachomes.com> On Thu, May 29, 2008 at 11:10:40AM -0700, Joel Jaeggli wrote: > Barry Shein wrote: > > > Equating port 25 use with domestic terrorism is specious. > > > > > > Ammonium nitrate requires requires some care in handling regardless of > > > your intentions,see for exmple the oppau or texas city disasters. > > > >And how different is that from the million+ strong zombie botnets? Who > >owns (not pwns) those zombie'd systems and what were their intentions? > > Well let's see. The texas city disaster is/was considered the worst > industrial accident in american history. 581 people killed by an > explosive yield of about 2 kilotons. The secondary effects includes > fires in many of the chemical facilities in Galveston and a swath of > destruction that reached up to 40 miles inland... > > http://www.local1259iaff.org/disaster.html > > So no, I don't think internet attached hosts can casually equated with > the destructive potential of a pile of fertilizer at least not in the > context described. One word: SCADA. Yes, in point of fact, I think it *is* reasonable to evaluate potential threats to "just some PCs getting pwned" in terms of physical damage on grander scales. It's not just about spam, or fraudulent credit charges. Cheers, -- jra -- Jay R. Ashworth jra at baylink.com Designer +-Internetworking------+---------+ RFC 2100 Ashworth & Associates | Best Practices Wiki | | '87 e24 St Petersburg FL USA +-http://bestpractices.wikia.com-+ +1 727 647 1274 If you can read this... thank a system administrator. Or two. --me From jasongurtz at npumail.com Wed Jun 4 13:29:08 2008 From: jasongurtz at npumail.com (Jason Gurtz) Date: Wed, 4 Jun 2008 14:29:08 -0400 Subject: AT&T Outage? In-Reply-To: References: Message-ID: > Same coming out of the mid-west also. Not seeing anything unusual here in S.E CT (att adsl going to Comcast business cable acct.). 1 2 ms 10 ms 2 ms 172.16.34.250 2 1 ms <1 ms <1 ms 69.183.133.206 3 8 ms 8 ms 8 ms se1-l0.mrdnct.sbcglobal.net [204.60.4.38] 4 8 ms 9 ms 8 ms dist1-vlan60.mrdnct.sbcglobal.net [66.159.184.226] 5 45 ms 24 ms 15 ms bb1-10g2-0.mrdnct.sbcglobal.net [151.164.92.147] 6 88 ms 98 ms 147 ms 151.164.94.255 7 100 ms 52 ms 13 ms asn3356-level3.eqnwnj.sbcglobal.net [151.164.89.250] 8 16 ms 18 ms 17 ms ae-31-53.ebr1.newark1.level3.net [4.68.99.94] 9 14 ms 17 ms 17 ms ae-2.ebr1.newyork1.level3.net [4.69.132.97] 10 24 ms 19 ms 16 ms ae-71-71.csw2.newyork1.level3.net [4.69.134.70] 11 13 ms 13 ms 13 ms ae-2-79.edge1.newyork2.level3.net [4.68.16.75] 12 14 ms 28 ms 13 ms comcast-ip.edge1.newyork2.level3.net [4.71.184.2] 13 16 ms 17 ms 17 ms te-3-3-ar01.chartford.ct.hartford.comcast.net [68.86.90.66] 14 17 ms 17 ms 17 ms po-10-ar01.berlin.ct.hartford.comcast.net [68.87.146.30] 15 17 ms 17 ms 17 ms te-9-1-ur01.middletown.ct.hartford.comcast.net [68.87.182.50] 16 18 ms 17 ms 18 ms te-9-1-ur01.killingworth.ct.hartford.comcast.net [68.87.182.46] 17 18 ms 18 ms 28 ms te-9-1-ur01.clinton.ct.hartford.comcast.net [68.87.182.42] 18 19 ms 20 ms 20 ms te-8-1-ur01.groton.ct.hartford.comcast.net [68.87.182.21] 19 19 ms 19 ms 26 ms te-9-1-ur01.nstonington.ct.hartford.comcast.net [68.87.182.25] 20 19 ms 19 ms 20 ms te-9-1-ur01.norwich.ct.hartford.comcast.net [68.86.231.166] 21 * 1533 ms 2871 ms 75-144-196-61-connecticut.hfc.comcastbusiness.net [75.144.196.61] ya, our end point is a tad saturated but not my problem yet. ;) ~JasonG -- From jfiske at clarkson.edu Wed Jun 4 21:19:03 2008 From: jfiske at clarkson.edu (Josh Fiske) Date: Wed, 4 Jun 2008 22:19:03 -0400 Subject: Power/temperature monitoring References: Message-ID: <6708B7A5C8087B4AA393C1CDD1D5620029D8@mbox1.ad.clarkson.edu> Frank, We have had good luck with a device called TemPager (http://tempager.com/). Our specific device is used for SNMP temperature monitoring, but they also make a device that includes the ability to humidity, power, flood, room entry, etc. etc. Hope that is helpful, Josh - - - - Joshua Fiske '03, '04 Network and Security Engineer Clarkson University, Office of Information Technology (315) 268-6722 -- Fax: (315) 268-6570 GPG Key: http://clarkson.edu/~jfiske/jfiske_pub.asc jfiske at clarkson.edu CONFIDENTIALITY: This e-mail (including any attachments) may contain confidential, proprietary and privileged information, and unauthorized disclosure or use is prohibited. If you received this e-mail in error, please notify the sender and delete this e-mail from your system. -----Original Message----- From: Frank Bulk [mailto:frnkblk at iname.com] Sent: Fri 5/30/2008 10:58 AM To: nanog at nanog.org Subject: Power/temperature monitoring Hopefully monitoring the status of a network is on-topic. I'm looking for temperature and power monitoring unit to install in some remote BWA cabinets. We had two incidents where we lost power in a town and we weren't aware of it until the backup batter drained to empty, and another situation where the cabinet became too cold. Because these cabinets are less than 19" wide and just 3-5" deep, I need something quite small. I did find one product but it requires four components (unit with built-in temperature sensor, adapter, and AC power sensor, plus power supply) Perhaps there's someone on this list who has gone down this road and can point me to a good product. Required: - temperature sensor - 110 VAC power monitoring (on/off, not necessarily current) - Ethernet interface (at least SNMP, Web GUI and Optional: - fed via 12 VDC power - 12 VDC power monitoring (current) - humidity sensor Frank From kyle at davantistudios.com Thu Jun 5 09:31:03 2008 From: kyle at davantistudios.com (Kyle Duren) Date: Thu, 05 Jun 2008 07:31:03 -0700 Subject: Power/temperature monitoring Message-ID: <4847F8A7.2080408@davantistudios.com> We have had great luck, with Ravica Bitsight: http://ravica.com/products/index.php We use the smallest model, the Bitsight2, we have it at a solar site, monitoring the voltage of a 12v battery bank (which also powers the unit), along with 2 microwave radios and a 12v switch. It works great for this, and they many other sensor types, but it is a bit pricey. It has a nice web gui and users snmp and other forms of notification, and has built in graphing. We used email messages with alerts when certain voltage levels were reached. -Kyle -----Original Message----- From: Frank Bulk [mailto:frnkblk at iname.com] Sent: Fri 5/30/2008 10:58 AM To: nanog at nanog.org Subject: Power/temperature monitoring Hopefully monitoring the status of a network is on-topic. I'm looking for temperature and power monitoring unit to install in some remote BWA cabinets. We had two incidents where we lost power in a town and we weren't aware of it until the backup batter drained to empty, and another situation where the cabinet became too cold. Because these cabinets are less than 19" wide and just 3-5" deep, I need something quite small. I did find one product but it requires four components (unit with built-in temperature sensor, adapter, and AC power sensor, plus power supply) Perhaps there's someone on this list who has gone down this road and can point me to a good product. Required: - temperature sensor - 110 VAC power monitoring (on/off, not necessarily current) - Ethernet interface (at least SNMP, Web GUI and Optional: - fed via 12 VDC power - 12 VDC power monitoring (current) - humidity sensor Frank From frnkblk at iname.com Thu Jun 5 21:46:17 2008 From: frnkblk at iname.com (Frank Bulk - iNAME) Date: Thu, 5 Jun 2008 21:46:17 -0500 Subject: Power/temperature monitoring In-Reply-To: <6708B7A5C8087B4AA393C1CDD1D5620029D8@mbox1.ad.clarkson.edu> References: <6708B7A5C8087B4AA393C1CDD1D5620029D8@mbox1.ad.clarkson.edu> Message-ID: Thanks. The TemPager doesn't appear to support identifying AC power failure, but that's in the Room Alert 7. The price point and features do seem reasonable. Frank From: Josh Fiske [mailto:jfiske at clarkson.edu] Sent: Wednesday, June 04, 2008 9:19 PM To: frnkblk at iname.com; nanog at nanog.org Subject: RE: Power/temperature monitoring Frank, We have had good luck with a device called TemPager (http://tempager.com/). Our specific device is used for SNMP temperature monitoring, but they also make a device that includes the ability to humidity, power, flood, room entry, etc. etc. Hope that is helpful, Josh - - - - Joshua Fiske '03, '04 Network and Security Engineer Clarkson University, Office of Information Technology (315) 268-6722 -- Fax: (315) 268-6570 GPG Key: http://clarkson.edu/~jfiske/jfiske_pub.asc jfiske at clarkson.edu CONFIDENTIALITY: This e-mail (including any attachments) may contain confidential, proprietary and privileged information, and unauthorized disclosure or use is prohibited. If you received this e-mail in error, please notify the sender and delete this e-mail from your system. -----Original Message----- From: Frank Bulk [mailto:frnkblk at iname.com] Sent: Fri 5/30/2008 10:58 AM To: nanog at nanog.org Subject: Power/temperature monitoring Hopefully monitoring the status of a network is on-topic. I'm looking for temperature and power monitoring unit to install in some remote BWA cabinets. We had two incidents where we lost power in a town and we weren't aware of it until the backup batter drained to empty, and another situation where the cabinet became too cold. Because these cabinets are less than 19" wide and just 3-5" deep, I need something quite small. I did find one product but it requires four components (unit with built-in temperature sensor, adapter, and AC power sensor, plus power supply) Perhaps there's someone on this list who has gone down this road and can point me to a good product. Required: - temperature sensor - 110 VAC power monitoring (on/off, not necessarily current) - Ethernet interface (at least SNMP, Web GUI and Optional: - fed via 12 VDC power - 12 VDC power monitoring (current) - humidity sensor Frank From frnkblk at iname.com Thu Jun 5 21:48:39 2008 From: frnkblk at iname.com (Frank Bulk - iNAME) Date: Thu, 5 Jun 2008 21:48:39 -0500 Subject: Power/temperature monitoring In-Reply-To: <4847F8A7.2080408@davantistudios.com> References: <4847F8A7.2080408@davantistudios.com> Message-ID: This is basically the AKCP product, repackaged. =) Frank -----Original Message----- From: Kyle Duren [mailto:kyle at davantistudios.com] Sent: Thursday, June 05, 2008 9:31 AM To: nanog at nanog.org Subject: RE: Power/temperature monitoring We have had great luck, with Ravica Bitsight: http://ravica.com/products/index.php We use the smallest model, the Bitsight2, we have it at a solar site, monitoring the voltage of a 12v battery bank (which also powers the unit), along with 2 microwave radios and a 12v switch. It works great for this, and they many other sensor types, but it is a bit pricey. It has a nice web gui and users snmp and other forms of notification, and has built in graphing. We used email messages with alerts when certain voltage levels were reached. -Kyle -----Original Message----- From: Frank Bulk [mailto:frnkblk at iname.com] Sent: Fri 5/30/2008 10:58 AM To: nanog at nanog.org Subject: Power/temperature monitoring Hopefully monitoring the status of a network is on-topic. I'm looking for temperature and power monitoring unit to install in some remote BWA cabinets. We had two incidents where we lost power in a town and we weren't aware of it until the backup batter drained to empty, and another situation where the cabinet became too cold. Because these cabinets are less than 19" wide and just 3-5" deep, I need something quite small. I did find one product but it requires four components (unit with built-in temperature sensor, adapter, and AC power sensor, plus power supply) Perhaps there's someone on this list who has gone down this road and can point me to a good product. Required: - temperature sensor - 110 VAC power monitoring (on/off, not necessarily current) - Ethernet interface (at least SNMP, Web GUI and Optional: - fed via 12 VDC power - 12 VDC power monitoring (current) - humidity sensor Frank From cidr-report at potaroo.net Fri Jun 6 07:00:02 2008 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 6 Jun 2008 22:00:02 +1000 (EST) Subject: BGP Update Report Message-ID: <200806061200.m56C02qM023600@wattle.apnic.net> BGP Update Report Interval: 05-May-08 -to- 05-Jun-08 (32 days) Observation Point: BGP Peering with AS2.0 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS15169 317656 4.3% 2388.4 -- GOOGLE - Google Inc. 2 - AS4538 128643 1.8% 26.0 -- ERX-CERNET-BKB China Education and Research Network Center 3 - AS6140 89744 1.2% 97.8 -- IMPSAT-USA - ImpSat USA, Inc. 4 - AS17974 55192 0.8% 105.1 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia 5 - AS9498 47659 0.7% 38.0 -- BBIL-AP BHARTI BT INTERNET LTD. 6 - AS9583 47077 0.6% 38.7 -- SIFY-AS-IN Sify Limited 7 - AS9198 46789 0.6% 102.8 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 8 - AS5691 45587 0.6% 3506.7 -- MITRE-AS-5 - The MITRE Corporation 9 - AS42787 42086 0.6% 14028.7 -- MMIP-AS MultiMedia IP Ltd. 10 - AS8151 35055 0.5% 28.0 -- Uninet S.A. de C.V. 11 - AS18231 29786 0.4% 137.9 -- EXATT-AS-AP IOL NETCOM LTD 12 - AS8866 29754 0.4% 96.9 -- BTC-AS Bulgarian Telecommunication Company Plc. 13 - AS2386 28522 0.4% 19.5 -- INS-AS - AT&T Data Communications Services 14 - AS14522 28361 0.4% 148.5 -- Satnet 15 - AS23966 27885 0.4% 82.3 -- DANCOM-AS-AP LINKdotNET Pakistan 16 - AS5803 26784 0.4% 157.6 -- DDN-ASNBLK - DoD Network Information Center 17 - AS24731 26314 0.4% 328.9 -- ASN-NESMA National Engineering Services and Marketing Company Ltd. (NESMA) 18 - AS1239 26167 0.4% 7.9 -- SPRINTLINK - Sprint 19 - AS702 25453 0.3% 46.8 -- AS702 Verizon Business EMEA - Commercial IP service provider in Europe 20 - AS31003 25344 0.3% 3620.6 -- IRON-MOUNTAIN-UK-AS Iron Mountain UK Ltd TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS26829 23906 0.3% 23906.0 -- YKK-USA - YKK USA,INC 2 - AS17834 19965 0.3% 19965.0 -- KYOBOAUTO-AS-KR Kyobo Auto Insurance CO.,LTD 3 - AS42787 42086 0.6% 14028.7 -- MMIP-AS MultiMedia IP Ltd. 4 - AS36384 18844 0.3% 6281.3 -- GOOGLE-IT - Google Incorporated 5 - AS28646 4976 0.1% 4976.0 -- Confederacao Interestadual das Cooperativas Ligadas ao Sicredi 6 - AS30929 4715 0.1% 4715.0 -- HUTCB Hidrotechnical Faculty - Technical University 7 - AS35324 3724 0.1% 3724.0 -- ECH-WILL-AS E.C.H. Will 8 - AS31003 25344 0.3% 3620.6 -- IRON-MOUNTAIN-UK-AS Iron Mountain UK Ltd 9 - AS16466 17856 0.2% 3571.2 -- AVAYA AVAYA 10 - AS5691 45587 0.6% 3506.7 -- MITRE-AS-5 - The MITRE Corporation 11 - AS39105 3499 0.1% 3499.0 -- CLASS-AS SC Class Computers And Service SRL 12 - AS29910 3491 0.1% 3491.0 -- IACP - INTL. ASSN OF CHIEF OF POLICEI 13 - AS23082 17357 0.2% 3471.4 -- MPHI - Michigan Public Health Institute 14 - AS32996 2942 0.0% 2942.0 -- AGRIBANK-STPAUL - AgriBank, FCB 15 - AS38513 2932 0.0% 2932.0 -- LINTASARTA-AS-ID PT Aplikanusa Lintasarta 16 - AS40359 2653 0.0% 2653.0 -- SOUTHEASTERNMILLS-ROME - Southeastern Mills, Inc. 17 - AS10551 5045 0.1% 2522.5 -- RAPID-CITY-REGIONAL - Rapid City Regional Hospital 18 - AS30287 2393 0.0% 2393.0 -- ALON-USA - ALON USA, LP 19 - AS15169 317656 4.3% 2388.4 -- GOOGLE - Google Inc. 20 - AS44730 2288 0.0% 2288.0 -- ALFAGOMMA Alfa Gomma s.p.a. TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 192.12.120.0/24 45231 0.6% AS5691 -- MITRE-AS-5 - The MITRE Corporation 2 - 193.33.184.0/23 42064 0.5% AS42787 -- MMIP-AS MultiMedia IP Ltd. 3 - 125.23.208.0/20 27881 0.4% AS9498 -- BBIL-AP BHARTI BT INTERNET LTD. 4 - 221.128.192.0/18 27623 0.3% AS18231 -- EXATT-AS-AP IOL NETCOM LTD 5 - 12.108.254.0/24 23906 0.3% AS26829 -- YKK-USA - YKK USA,INC 6 - 213.91.175.0/24 21353 0.3% AS8866 -- BTC-AS Bulgarian Telecommunication Company Plc. 7 - 193.239.114.0/24 20999 0.3% AS31003 -- IRON-MOUNTAIN-UK-AS Iron Mountain UK Ltd 8 - 210.92.148.0/24 19965 0.3% AS17834 -- KYOBOAUTO-AS-KR Kyobo Auto Insurance CO.,LTD 9 - 221.135.230.0/23 12760 0.2% AS9583 -- SIFY-AS-IN Sify Limited 10 - 84.23.102.0/24 11937 0.1% AS24731 -- ASN-NESMA National Engineering Services and Marketing Company Ltd. (NESMA) AS34400 -- ASN-ETTIHADETISALAT Etihad Etisalat 11 - 203.63.26.0/24 11510 0.1% AS9747 -- EZINTERNET-AS-AP EZInternet Pty Ltd 12 - 72.14.230.0/24 7810 0.1% AS36384 -- GOOGLE-IT - Google Incorporated 13 - 64.201.128.0/20 7697 0.1% AS11915 -- TELWEST-NETWORK-SVCS-STATIC - TEL WEST COMMUNICATIONS LLC 14 - 193.142.125.0/24 6897 0.1% AS15169 -- GOOGLE - Google Inc. AS41264 -- GOOGLE-CORPNET Google Ireland Limited 15 - 135.10.4.0/24 6839 0.1% AS16466 -- AVAYA AVAYA AS701 -- UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 16 - 135.10.5.0/24 6837 0.1% AS16466 -- AVAYA AVAYA AS701 -- UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 17 - 149.117.166.0/24 6277 0.1% AS701 -- UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 18 - 203.101.87.0/24 6253 0.1% AS9498 -- BBIL-AP BHARTI BT INTERNET LTD. 19 - 203.188.220.0/24 6154 0.1% AS9519 -- VERTELNET Vertical Telecoms Pty Ltd 20 - 210.18.110.0/24 5941 0.1% AS9583 -- SIFY-AS-IN Sify Limited Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at merit.edu eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From cidr-report at potaroo.net Fri Jun 6 07:00:00 2008 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 6 Jun 2008 22:00:00 +1000 (EST) Subject: The Cidr Report Message-ID: <200806061200.m56C00fS023587@wattle.apnic.net> This report has been generated at Fri Jun 6 21:10:54 2008 AEST. The report analyses the BGP Routing Table of AS2.0 router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org for a current version of this report. Recent Table History Date Prefixes CIDR Agg 30-05-08 267397 167784 31-05-08 266912 165098 01-06-08 267050 165207 02-06-08 266986 165771 03-06-08 267193 163293 04-06-08 266832 164231 05-06-08 267269 165040 06-06-08 267006 165864 AS Summary 0 Number of ASes in routing system 0 Number of ASes announcing only one prefix 4935 Largest number of prefixes announced by an AS AS4538 : ERX-CERNET-BKB China Education and Research Network Center 0 Largest address span announced by an AS (/32s)  : MIT-GATEWAYS - Massachusetts Institute of Technology Aggregation Summary The algorithm used in this report proposes aggregation only when there is a precise match using the AS path, so as to preserve traffic transit policies. Aggregation is also proposed across non-advertised address space ('holes'). --- 06Jun08 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 267375 165864 101511 38.0% All ASes AS4538 4935 878 4057 82.2% ERX-CERNET-BKB China Education and Research Network Center AS6389 2202 419 1783 81.0% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS4755 1642 236 1406 85.6% VSNL-AS Videsh Sanchar Nigam Ltd. Autonomous System AS9498 1174 69 1105 94.1% BBIL-AP BHARTI BT INTERNET LTD. AS4323 1466 491 975 66.5% TWTC - Time Warner Telecom, Inc. AS18566 1044 148 896 85.8% COVAD - Covad Communications Co. AS22773 946 71 875 92.5% CCINET-2 - Cox Communications Inc. AS11492 1227 480 747 60.9% CABLEONE - CABLE ONE AS8151 1239 500 739 59.6% Uninet S.A. de C.V. AS17488 1093 372 721 66.0% HATHWAY-NET-AP Hathway IP Over Cable Internet AS1785 1028 327 701 68.2% AS-PAETEC-NET - PaeTec Communications, Inc. AS19262 911 237 674 74.0% VZGNI-TRANSIT - Verizon Internet Services Inc. AS18101 691 111 580 83.9% RIL-IDC Reliance Infocom Ltd Internet Data Centre, AS2386 1440 885 555 38.5% INS-AS - AT&T Data Communications Services AS6478 951 411 540 56.8% ATT-INTERNET3 - AT&T WorldNet Services AS855 597 109 488 81.7% CANET-ASN-4 - Bell Aliant AS3356 944 457 487 51.6% LEVEL3 Level 3 Communications AS4766 878 400 478 54.4% KIXS-AS-KR Korea Telecom AS17676 525 80 445 84.8% GIGAINFRA BB TECHNOLOGY Corp. AS4134 826 399 427 51.7% CHINANET-BACKBONE No.31,Jin-rong Street AS19916 639 213 426 66.7% ASTRUM-0001 - OLM LLC AS6197 949 524 425 44.8% BATI-ATL - BellSouth Network Solutions, Inc AS7011 1053 647 406 38.6% FRONTIER-AND-CITIZENS - Frontier Communications of America, Inc. AS22047 565 159 406 71.9% VTR BANDA ANCHA S.A. AS4668 675 272 403 59.7% LGNET-AS-KR LG CNS AS7029 566 170 396 70.0% WINDSTREAM - Windstream Communications Inc AS7018 1392 997 395 28.4% ATT-INTERNET4 - AT&T WorldNet Services AS9443 467 85 382 81.8% INTERNETPRIMUS-AS-AP Primus Telecommunications AS3602 455 79 376 82.6% AS3602-RTI - Rogers Telecom Inc. AS4808 524 149 375 71.6% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network Total 33044 10375 22669 68.6% Top 30 total Possible Bogus Routes 24.38.0.0/17 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 24.48.0.0/13 AS19548 ADELPHIA-AS2 - Road Runner HoldCo LLC 24.51.159.0/24 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 24.54.224.0/19 AS20001 ROADRUNNER-WEST - Road Runner HoldCo LLC 24.75.160.0/19 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 24.75.192.0/18 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 24.142.40.0/21 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 24.142.160.0/19 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 24.246.0.0/17 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 24.246.128.0/18 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV - Wireless Broadband via Satellite 63.140.213.0/24 AS22555 UTC - Universal Talkware Corporation 63.143.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 63.143.115.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 63.143.251.0/24 AS22555 UTC - Universal Talkware Corporation 63.248.0.0/16 AS3356 LEVEL3 Level 3 Communications 64.7.112.0/21 AS6453 GLOBEINTERNET TATA Communications 64.7.120.0/21 AS6453 GLOBEINTERNET TATA Communications 64.50.128.0/18 AS4565 MEGAPATH2-US - MegaPath Networks Inc. 64.64.159.0/24 AS32004 BIG-ASN - Business Information Group, Inc. 64.144.0.0/15 AS4565 MEGAPATH2-US - MegaPath Networks Inc. 64.188.0.0/16 AS3356 LEVEL3 Level 3 Communications 65.36.8.0/24 AS5696 65.36.9.0/24 AS5696 65.36.33.0/24 AS5696 66.11.32.0/20 AS6261 VISINET - Visionary Systems, Inc. 66.11.40.0/21 AS6261 VISINET - Visionary Systems, Inc. 66.54.91.0/24 AS30506 BLACKSUN-1 - Blacksun Technologies LLC 66.55.160.0/19 AS29994 66.64.96.0/20 AS3790 RADIGRAFICA COSTARRICENSE 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.199.32.0/20 AS10397 WISP-AS - Wispnet, LLC 66.206.32.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.33.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.34.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.35.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.40.0/22 AS174 COGENT Cogent/PSI 66.206.44.0/23 AS174 COGENT Cogent/PSI 66.206.47.0/24 AS17557 PKTELECOM-AS-AP Pakistan Telecom 66.207.32.0/20 AS23011 66.219.192.0/18 AS5048 FIBER - FIBERNET Corp. 67.20.0.0/14 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 68.64.0.0/13 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 68.168.0.0/14 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 68.232.0.0/14 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 69.71.192.0/20 AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport 69.80.0.0/17 AS3043 AMPHIB-AS - Amphibian Media Corporation 69.164.0.0/17 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 70.34.0.0/16 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 80.88.0.0/21 AS33774 DJAWEB 80.88.8.0/22 AS33774 DJAWEB 80.88.10.0/24 AS33774 DJAWEB 80.88.11.0/24 AS33774 DJAWEB 80.88.12.0/24 AS33779 wataniya-telecom-as 91.200.192.128/25 AS44045 DIGIEF-AS Didjief internation kulinari koncept LLC 91.200.193.128/25 AS44045 DIGIEF-AS Didjief internation kulinari koncept LLC 91.200.194.128/25 AS44045 DIGIEF-AS Didjief internation kulinari koncept LLC 91.200.195.128/25 AS44045 DIGIEF-AS Didjief internation kulinari koncept LLC 91.206.8.0/23 AS3248 SIL-AT SILVER SERVER GmbH 91.206.10.0/24 AS47143 TODAYHOST-AS Todayhost Ltd. 91.206.11.0/24 AS47143 TODAYHOST-AS Todayhost Ltd. 93.185.32.0/20 AS8226 AM-NIC-AS AM NIC 94.80.0.0/15 AS3269 ASN-IBSNAZ TELECOM ITALIA 94.82.0.0/15 AS3269 ASN-IBSNAZ TELECOM ITALIA 95.192.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 95.255.248.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 111.111.111.0/24 AS19228 ENTEL CHILE S.A. 137.0.0.0/13 AS721 DISA-ASNBLK - DoD Network Information Center 151.135.0.0/16 AS4768 CLIX-NZ TelstraClear Ltd 159.3.211.0/24 AS2687 ASATTCA AT&T Global Network Services - AP 163.142.0.0/16 AS2500 WIDE-BB WIDE Project 166.63.0.0/16 AS33775 NITEL-AS 172.7.0.0/24 AS28175 172.10.1.0/30 AS18305 POSNET POSDATA Co.,Ltd 192.9.200.0/24 AS3602 AS3602-RTI - Rogers Telecom Inc. 192.30.93.0/24 AS17757 HPAUS-AP HP Australia 192.30.94.0/24 AS17757 HPAUS-AP HP Australia 192.40.105.0/24 AS12582 TSF-DATANET-NGD-AS TSF MPLS VPN Services 192.64.85.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.107.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.108.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.177.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.70.164.0/24 AS25689 NRCNET-AS - National Research Council of Canada 192.96.36.0/24 AS5713 SAIX-NET 192.96.37.0/24 AS10474 NETACTIVE 192.96.135.0/24 AS2018 TENET-1 192.96.136.0/23 AS2018 TENET-1 192.96.141.0/24 AS5713 SAIX-NET 192.96.143.0/24 AS2018 TENET-1 192.96.145.0/24 AS2018 TENET-1 192.96.177.0/24 AS6083 POSIX-AFRICA 192.101.45.0/24 AS2905 TICSA-ASN 192.101.46.0/24 AS6503 Avantel, S.A. 192.101.47.0/24 AS6503 Avantel, S.A. 192.101.64.0/21 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.67.0/24 AS21775 192.101.70.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.72.0/24 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.73.0/24 AS4765 WORLDNET-AS World Net & Services Co., Ltd. 192.101.74.0/24 AS1239 SPRINTLINK - Sprint 192.122.212.0/24 AS209 ASN-QWEST - Qwest 192.124.252.0/22 AS680 DFN-IP service G-WiN 192.131.233.0/24 AS7891 BELLSOUTH-NET-BLK2 - Bellsouth.Net 192.133.6.0/24 AS10282 EQUANT-CEEUR EQUANT AS for Central and Eastern Europe region 192.153.144.0/21 AS721 DISA-ASNBLK - DoD Network Information Center 192.154.32.0/19 AS81 NCREN - MCNC 192.188.208.0/20 AS721 DISA-ASNBLK - DoD Network Information Center 193.200.114.0/23 AS31530 SERVERCREW-AS Servercrew LTD Autonomes System 194.11.26.0/24 AS33857 ASN-METABOLI Metaboli 194.11.27.0/24 AS3248 SIL-AT SILVER SERVER GmbH 194.31.227.0/24 AS21461 TRANSFAIRNET Transfair-net GmbH Krefeld 194.246.72.0/23 AS8893 ARTFILES-AS Artfiles New Media GmbH 196.6.108.0/24 AS5713 SAIX-NET 196.10.119.0/24 AS2018 TENET-1 196.10.122.0/23 AS2018 TENET-1 196.10.251.0/24 AS2018 TENET-1 196.10.252.0/23 AS2018 TENET-1 196.10.254.0/24 AS2018 TENET-1 196.13.101.0/24 AS2018 TENET-1 196.13.102.0/23 AS2018 TENET-1 196.13.104.0/24 AS2018 TENET-1 196.13.121.0/24 AS2018 TENET-1 196.13.125.0/24 AS2018 TENET-1 196.13.126.0/24 AS2018 TENET-1 196.13.169.0/24 AS2018 TENET-1 196.13.174.0/23 AS2018 TENET-1 196.13.176.0/21 AS2018 TENET-1 196.13.192.0/22 AS2018 TENET-1 196.13.196.0/24 AS2018 TENET-1 196.201.98.0/24 AS29571 CITelecom-AS 196.216.132.0/24 AS9207 TAIDE-KE-NAIROBI Taide - Kenya POP 196.216.134.0/24 AS9207 TAIDE-KE-NAIROBI Taide - Kenya POP 198.23.26.0/24 AS4390 BELLATLANTIC-COM - Bell Atlantic, Inc. 198.54.82.0/24 AS2018 TENET-1 198.54.92.0/24 AS2018 TENET-1 198.54.222.0/24 AS2018 TENET-1 198.97.72.0/21 AS721 DISA-ASNBLK - DoD Network Information Center 198.97.80.0/20 AS721 DISA-ASNBLK - DoD Network Information Center 198.97.96.0/19 AS721 DISA-ASNBLK - DoD Network Information Center 198.97.240.0/20 AS721 DISA-ASNBLK - DoD Network Information Center 198.144.96.0/20 AS12185 198.161.87.0/24 AS6539 GT-BELL - Bell Canada 198.167.0.0/16 AS7456 INTERHOP - Interhop Network SERVICES Inc. 198.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 198.169.0.0/16 AS803 SASKTEL - Saskatchewan Telecommunications 198.180.198.0/24 AS23715 SEOUL-INTGW-GXS-AP Global Exchange Services 199.9.128.0/17 AS668 ASN-ASNET-NET-AS - Defense Research and Engineering Network 199.10.0.0/16 AS721 DISA-ASNBLK - DoD Network Information Center 199.114.0.0/21 AS721 DISA-ASNBLK - DoD Network Information Center 199.114.128.0/18 AS721 DISA-ASNBLK - DoD Network Information Center 199.114.130.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.131.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.132.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.134.0/24 AS3541 ITSDN-U4 - DoD Network Information Center 199.114.136.0/24 AS27044 DDN-ASNBLK1 - DoD Network Information Center 199.114.138.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.140.0/24 AS3544 ITSDN-U7 - DoD Network Information Center 199.114.142.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.144.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.148.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.150.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.152.0/24 AS27033 DDN-ASNBLK1 - DoD Network Information Center 199.114.153.0/24 AS27034 DDN-ASNBLK1 - DoD Network Information Center 199.114.154.0/24 AS1733 CENTAF-SWA - AF DDN PMO 199.114.156.0/24 AS1733 CENTAF-SWA - AF DDN PMO 199.114.160.0/24 AS1733 CENTAF-SWA - AF DDN PMO 199.121.0.0/16 AS721 DISA-ASNBLK - DoD Network Information Center 199.123.0.0/18 AS721 DISA-ASNBLK - DoD Network Information Center 199.123.16.0/20 AS721 DISA-ASNBLK - DoD Network Information Center 199.123.80.0/21 AS721 DISA-ASNBLK - DoD Network Information Center 199.189.32.0/19 AS7332 IQUEST-AS - IQuest Internet 199.202.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 199.246.116.0/24 AS813 UUNET-CANADA - MCI Communications Services, Inc. d/b/a Verizon Business 202.58.113.0/24 AS19161 INNOCOM-TELECOM - INNOCOM TELECOM 202.73.144.0/20 AS4788 TMNET-AS-AP TM Net, Internet Service Provider 202.80.192.0/20 AS2706 HKSUPER-HK-AP Pacific Internet (Hong Kong) Limited 202.86.252.0/22 AS4748 RESOLINK-AS-AP Resources Link Network Limited 202.86.252.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.253.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.254.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.255.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.90.33.0/24 AS9830 SWIFTONLINE-AS-AP SWIFT ONLINE BORDER AS 202.90.40.0/24 AS9830 SWIFTONLINE-AS-AP SWIFT ONLINE BORDER AS 202.90.41.0/24 AS9830 SWIFTONLINE-AS-AP SWIFT ONLINE BORDER AS 202.90.42.0/24 AS9830 SWIFTONLINE-AS-AP SWIFT ONLINE BORDER AS 202.90.43.0/24 AS9830 SWIFTONLINE-AS-AP SWIFT ONLINE BORDER AS 202.90.44.0/24 AS9830 SWIFTONLINE-AS-AP SWIFT ONLINE BORDER AS 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.94.70.0/24 AS9837 POWERTEL-AP Powertel Ltd 202.124.195.0/24 AS17557 PKTELECOM-AS-AP Pakistan Telecom 202.124.207.0/24 AS17911 BRAINPK-AS-AP Brain Telecommunication Ltd. 202.136.254.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.136.255.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.164.100.0/24 AS18101 RIL-IDC Reliance Infocom Ltd Internet Data Centre, 202.176.228.0/24 AS17988 SINOSAT-AS-AP SINOSAT (HONG KONG) LIMITED 202.176.232.0/24 AS17988 SINOSAT-AS-AP SINOSAT (HONG KONG) LIMITED 202.181.32.0/24 AS4645 ASN-HKNET-AP HKNet Co. Ltd 203.12.45.0/24 AS4854 NETSPACE-AS-AP Netspace Online Systems 203.62.0.0/17 AS7575 AARNET-AS-AP Australian Academic and Reasearch Network (AARNet) 203.78.48.0/20 AS9299 IPG-AS-AP Philippine Long Distance Telephone Company 203.89.139.0/24 AS17911 BRAINPK-AS-AP Brain Telecommunication Ltd. 203.111.192.0/20 AS7473 SINGTEL-AS-AP Singapore Telecom 203.112.97.0/24 AS9942 COMINDICO-AP SOUL Converged Communications Australia 203.112.111.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.113.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.114.0/24 AS4802 ASN-IINET iiNet Limited 203.112.116.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.117.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.118.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.119.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.120.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.121.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.127.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.128.128.0/19 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 203.128.128.0/24 AS23849 CNNIC-NET263-AP Beijing Capital-online science development Co.,Ltd. 203.152.136.0/23 AS23649 NEWSKIES-AS-AP New Skies Satellites, Hong Kong Teleport 203.152.138.0/23 AS23649 NEWSKIES-AS-AP New Skies Satellites, Hong Kong Teleport 203.152.142.0/24 AS23649 NEWSKIES-AS-AP New Skies Satellites, Hong Kong Teleport 203.152.143.0/24 AS23649 NEWSKIES-AS-AP New Skies Satellites, Hong Kong Teleport 203.160.110.0/23 AS7643 VNN-AS-AP Vietnam Posts and Telecommunications (VNPT) 204.9.216.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.9.217.0/24 AS4323 TWTC - Time Warner Telecom, Inc. 204.9.218.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.13.140.0/22 AS7270 NET2PHONE - Net2Phone Corp. 204.16.120.0/23 AS12077 204.16.122.0/23 AS12077 204.19.14.0/23 AS577 BACOM - Bell Canada 204.29.196.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 204.29.197.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 204.48.58.0/24 AS4323 TWTC - Time Warner Telecom, Inc. 204.48.60.0/24 AS4323 TWTC - Time Warner Telecom, Inc. 204.154.125.0/24 AS3952 TELLABS-ASN - TELLABS Operations, Inc. 204.154.126.0/24 AS3952 TELLABS-ASN - TELLABS Operations, Inc. 204.154.127.0/24 AS3952 TELLABS-ASN - TELLABS Operations, Inc. 205.150.0.0/15 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 206.162.224.0/19 AS23464 ILCSNET - Interlink Computer Services 206.180.240.0/20 AS12083 KNOLOGY-NET - Knology Holdings 206.220.240.0/24 AS10764 STARTAP - National Center for Supercomputing Applications 206.220.240.64/26 AS22335 MREN - Metropolitan Research and Education Network 206.220.240.128/25 AS10764 STARTAP - National Center for Supercomputing Applications 206.220.240.160/30 AS10764 STARTAP - National Center for Supercomputing Applications 206.220.240.220/32 AS10764 STARTAP - National Center for Supercomputing Applications 206.220.241.0/24 AS10764 STARTAP - National Center for Supercomputing Applications 207.98.209.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 207.98.223.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 207.191.128.0/19 AS10887 BPSI-AS - BPSI Internet Services 207.204.168.0/24 AS15150 BELLTECH-AS - BELLWETHER TECHNOLOGY CORPORATION 207.204.222.0/24 AS22773 CCINET-2 - Cox Communications Inc. 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc. 208.38.192.0/18 AS3043 AMPHIB-AS - Amphibian Media Corporation 208.38.192.0/21 AS14237 BEAMSPEED1 - Beamspeed 208.38.202.0/24 AS14237 BEAMSPEED1 - Beamspeed 208.38.203.0/24 AS14237 BEAMSPEED1 - Beamspeed 208.38.204.0/22 AS14237 BEAMSPEED1 - Beamspeed 209.54.93.0/24 AS22773 CCINET-2 - Cox Communications Inc. 209.54.111.0/24 AS22773 CCINET-2 - Cox Communications Inc. 209.54.123.0/24 AS6062 NETPLEX - NETPLEX 209.54.240.0/21 AS10887 BPSI-AS - BPSI Internet Services 209.105.224.0/19 AS20074 209.140.90.0/24 AS14461 NTSL - NET SOLUTIONS 209.140.224.0/21 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.234.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.235.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.236.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.237.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.238.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.239.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.141.16.0/21 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.141.48.0/22 AS14461 NTSL - NET SOLUTIONS 209.145.192.0/18 AS3043 AMPHIB-AS - Amphibian Media Corporation 209.145.204.0/22 AS14237 BEAMSPEED1 - Beamspeed 210.5.128.0/20 AS4837 CHINA169-BACKBONE CNCGROUP China169 Backbone 213.150.192.0/21 AS29571 CITelecom-AS 213.150.200.0/22 AS29571 CITelecom-AS 213.150.201.0/24 AS29338 AFOL-AS Used by Africaonline Operations 213.150.202.0/24 AS41042 SKYVISION SkyVision Network Services 216.37.114.0/23 AS3549 GBLX Global Crossing Ltd. 216.37.120.0/23 AS13377 216.59.0.0/17 AS3356 LEVEL3 Level 3 Communications 216.99.16.0/24 AS6395 LVLT-6395 - Level 3 Communications, Inc. 216.99.20.0/24 AS6395 LVLT-6395 - Level 3 Communications, Inc. 216.162.96.0/19 AS7393 CYBERCON - CYBERCON, INC. 216.172.198.0/24 AS22773 CCINET-2 - Cox Communications Inc. 216.172.199.0/24 AS22773 CCINET-2 - Cox Communications Inc. 216.210.86.0/24 AS577 BACOM - Bell Canada 216.235.96.0/19 AS13645 BROADBANDONE - BroadbandONE, Inc. 216.240.240.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 216.240.241.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 216.240.242.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 216.251.207.0/24 AS1239 SPRINTLINK - Sprint 217.78.71.0/24 AS12491 IPPLANET-AS IPPlanet 217.78.72.0/24 AS12491 IPPLANET-AS IPPlanet 217.78.73.0/24 AS12491 IPPLANET-AS IPPlanet Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at merit.edu eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From frnkblk at iname.com Fri Jun 6 07:29:28 2008 From: frnkblk at iname.com (Frank Bulk - iNAME) Date: Fri, 6 Jun 2008 07:29:28 -0500 Subject: TINet stretches out in North America Message-ID: IIRC, they also provide IPv6, too. Good to see more players. ============== http://www.telegeography.com/cu/article.php?article_id=23487&email=html TINet stretches out in North America The wholesale IP/MPLS global carrier Tiscali International Network (TINet) has added new points of presence (PoP) in Toronto, Seattle, Atlanta and Dallas to its North American network. The PoP in Toronto is available for network traffic from today, Dallas will be available later this month, and then in July, Seattle and Atlanta will be ready for service. These PoPs are part of a wider network expansion plan that includes twelve more cities, in the US, Canada, Eastern Europe and the Asia-Pacific region, by the end of 2009. TINet's IP/MPLS backbone currently counts over 100 PoPs and covers 17 European countries, the US, Canada and Asia. From cscora at apnic.net Fri Jun 6 13:07:32 2008 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 7 Jun 2008 04:07:32 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <200806061807.m56I7WDZ030259@thyme.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 07 Jun, 2008 Report Website: http://thyme.apnic.net Detailed Analysis: http://thyme.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 257029 Prefixes after maximum aggregation: 127846 Deaggregation factor: 2.01 Unique aggregates announced to Internet: 126093 Total ASes present in the Internet Routing Table: 28361 Prefixes per ASN: 9.06 Origin-only ASes present in the Internet Routing Table: 24725 Origin ASes announcing only one prefix: 11924 Transit ASes present in the Internet Routing Table: 3636 Transit-only ASes present in the Internet Routing Table: 77 Average AS path length visible in the Internet Routing Table: 3.6 Max AS path length visible: 18 Max AS path prepend of ASN (43380) 13 Prefixes from unregistered ASNs in the Routing Table: 623 Unregistered ASNs in the Routing Table: 231 Number of 32-bit ASNs allocated by the RIRs: 49 Prefixes from 32-bit ASNs in the Routing Table: 8 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 783 Number of addresses announced to Internet: 1875474272 Equivalent to 111 /8s, 201 /16s and 119 /24s Percentage of available address space announced: 50.6 Percentage of allocated address space announced: 61.4 Percentage of available address space allocated: 82.3 Percentage of address space in use by end-sites: 72.1 Total number of prefixes smaller than registry allocations: 124322 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 58989 Total APNIC prefixes after maximum aggregation: 22099 APNIC Deaggregation factor: 2.67 Prefixes being announced from the APNIC address blocks: 55995 Unique aggregates announced from the APNIC address blocks: 24955 APNIC Region origin ASes present in the Internet Routing Table: 3265 APNIC Prefixes per ASN: 17.15 APNIC Region origin ASes announcing only one prefix: 858 APNIC Region transit ASes present in the Internet Routing Table: 505 Average APNIC Region AS path length visible: 3.5 Max APNIC Region AS path length visible: 17 Number of APNIC addresses announced to Internet: 351681440 Equivalent to 20 /8s, 246 /16s and 59 /24s Percentage of available APNIC address space announced: 74.9 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079 APNIC Address Blocks 58/8, 59/8, 60/8, 61/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 117708 Total ARIN prefixes after maximum aggregation: 64961 ARIN Deaggregation factor: 1.81 Prefixes being announced from the ARIN address blocks: 87645 Unique aggregates announced from the ARIN address blocks: 34442 ARIN Region origin ASes present in the Internet Routing Table: 12183 ARIN Prefixes per ASN: 7.19 ARIN Region origin ASes announcing only one prefix: 4716 ARIN Region transit ASes present in the Internet Routing Table: 1133 Average ARIN Region AS path length visible: 3.4 Max ARIN Region AS path length visible: 15 Number of ARIN addresses announced to Internet: 356844800 Equivalent to 21 /8s, 69 /16s and 5 /24s Percentage of available ARIN address space announced: 73.3 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 ARIN Address Blocks 24/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 173/8, 174/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 55629 Total RIPE prefixes after maximum aggregation: 33945 RIPE Deaggregation factor: 1.64 Prefixes being announced from the RIPE address blocks: 50825 Unique aggregates announced from the RIPE address blocks: 34021 RIPE Region origin ASes present in the Internet Routing Table: 11418 RIPE Prefixes per ASN: 4.45 RIPE Region origin ASes announcing only one prefix: 5965 RIPE Region transit ASes present in the Internet Routing Table: 1730 Average RIPE Region AS path length visible: 4.0 Max RIPE Region AS path length visible: 18 Number of RIPE addresses announced to Internet: 360492160 Equivalent to 21 /8s, 124 /16s and 172 /24s Percentage of available RIPE address space announced: 82.6 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-48127 RIPE Address Blocks 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 20191 Total LACNIC prefixes after maximum aggregation: 5129 LACNIC Deaggregation factor: 3.94 Prefixes being announced from the LACNIC address blocks: 18426 Unique aggregates announced from the LACNIC address blocks: 10351 LACNIC Region origin ASes present in the Internet Routing Table: 953 LACNIC Prefixes per ASN: 19.33 LACNIC Region origin ASes announcing only one prefix: 306 LACNIC Region transit ASes present in the Internet Routing Table: 160 Average LACNIC Region AS path length visible: 4.1 Max LACNIC Region AS path length visible: 15 Number of LACNIC addresses announced to Internet: 52306304 Equivalent to 3 /8s, 30 /16s and 33 /24s Percentage of available LACNIC address space announced: 52.0 LACNIC AS Blocks 26592-26623, 27648-28671, plus ERX transfers LACNIC Address Blocks 186/8, 187/8, 189/8, 190/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 3890 Total AfriNIC prefixes after maximum aggregation: 1194 AfriNIC Deaggregation factor: 3.26 Prefixes being announced from the AfriNIC address blocks: 4136 Unique aggregates announced from the AfriNIC address blocks: 1862 AfriNIC Region origin ASes present in the Internet Routing Table: 241 AfriNIC Prefixes per ASN: 17.16 AfriNIC Region origin ASes announcing only one prefix: 79 AfriNIC Region transit ASes present in the Internet Routing Table: 48 Average AfriNIC Region AS path length visible: 3.8 Max AfriNIC Region AS path length visible: 14 Number of AfriNIC addresses announced to Internet: 12314112 Equivalent to 0 /8s, 187 /16s and 230 /24s Percentage of available AfriNIC address space announced: 36.7 AfriNIC AS Blocks 36864-37887 & ERX transfers AfriNIC Address Blocks 41/8, 196/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4755 1642 387 89 Videsh Sanchar Nigam Ltd. Aut 9498 1174 550 61 BHARTI BT INTERNET LTD. 9583 1112 111 412 Sify Limited 17488 1078 71 94 Hathway IP Over Cable Interne 4766 849 6006 343 Korea Telecom (KIX) 4134 826 12917 324 CHINANET-BACKBONE 23577 817 34 700 Korea Telecom (ATM-MPLS) 18101 691 167 36 Reliance Infocom Ltd Internet 9829 598 450 12 BSNL National Internet Backbo 1221 549 1919 422 Telstra Pty Ltd Complete listing at http://thyme.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 2208 3103 182 bellsouth.net, inc. 4323 1471 1045 377 Time Warner Telecom 2386 1439 658 872 AT&T Data Communications Serv 7018 1372 5815 981 AT&T WorldNet Services 11492 1228 148 12 Cable One 7011 1051 291 584 Citizens Utilities 18566 1044 296 10 Covad Communications 20115 1039 1062 563 Charter Communications 1785 1028 510 105 AppliedTheory Corporation 174 979 6837 805 Cogent Communications Complete listing at http://thyme.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 3292 410 1772 369 TDC Tele Danmark 3301 338 1460 308 TeliaNet Sweden 8452 327 188 7 TEDATA 3320 316 7043 265 Deutsche Telekom AG 8866 311 77 21 Bulgarian Telecommunication C 5462 291 666 26 Telewest Broadband 3215 287 2742 91 France Telecom Transpac 8551 283 269 38 Bezeq International 680 274 2047 264 DFN-IP service G-WiN 9155 271 46 11 QualityNet AS number Complete listing at http://thyme.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8151 1238 2464 227 UniNet S.A. de C.V. 11830 603 299 9 Instituto Costarricense de El 22047 565 270 14 VTR PUNTO NET S.A. 7303 466 229 66 Telecom Argentina Stet-France 16814 426 27 10 NSS, S.A. 6471 413 85 46 ENTEL CHILE S.A. 11172 412 118 69 Servicios Alestra S.A de C.V 10620 383 98 79 TVCABLE BOGOTA 14117 375 23 9 Telefonica del Sur S.A. 20299 338 23 89 NEWCOM AMERICAS Complete listing at http://thyme.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 24863 472 61 28 LINKdotNET AS number 3741 282 853 223 The Internet Solution 20858 224 34 3 EgyNet 2018 191 189 82 Tertiary Education Network 5713 163 558 99 Telkom SA Ltd 6713 145 136 12 Itissalat Al-MAGHRIB 33783 134 10 12 EEPAD TISP TELECOM & INTERNET 5536 121 8 16 Internet Egypt Network 29571 103 13 8 Ci Telecom Autonomous system 33776 100 6 3 Starcomms Nigeria Limited Complete listing at http://thyme.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 2208 3103 182 bellsouth.net, inc. 4755 1642 387 89 Videsh Sanchar Nigam Ltd. Aut 4323 1471 1045 377 Time Warner Telecom 2386 1439 658 872 AT&T Data Communications Serv 7018 1372 5815 981 AT&T WorldNet Services 8151 1238 2464 227 UniNet S.A. de C.V. 11492 1228 148 12 Cable One 9498 1174 550 61 BHARTI BT INTERNET LTD. 9583 1112 111 412 Sify Limited 17488 1078 71 94 Hathway IP Over Cable Interne Complete listing at http://thyme.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 4755 1642 1553 Videsh Sanchar Nigam Ltd. Aut 11492 1228 1216 Cable One 9498 1174 1113 BHARTI BT INTERNET LTD. 4323 1471 1094 Time Warner Telecom 18566 1044 1034 Covad Communications 8151 1238 1011 UniNet S.A. de C.V. 17488 1078 984 Hathway IP Over Cable Interne 1785 1028 923 AppliedTheory Corporation 22773 946 884 Cox Communications, Inc. 6478 951 799 AT&T Worldnet Services Complete listing at http://thyme.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 16927 UNALLOCATED 12.0.252.0/23 701 UUNET Technologies, 22492 UNALLOCATED 12.2.46.0/24 7018 AT&T WorldNet Servic 15132 UNALLOCATED 12.9.150.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.14.170.0/24 7018 AT&T WorldNet Servic 13632 UNALLOCATED 12.20.55.0/24 6517 Yipes Communications 13746 UNALLOCATED 12.24.56.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.25.107.0/24 7018 AT&T WorldNet Servic 13632 UNALLOCATED 12.31.25.0/24 6517 Yipes Communications 27220 UNALLOCATED 12.35.204.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.152.0/24 7018 AT&T WorldNet Servic Complete listing at http://thyme.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 24.51.159.0/24 7843 Adelphia Corp. 24.54.224.0/19 20001 HoldCo LLC - Road Runner 24.75.160.0/19 7843 Adelphia Corp. 24.75.192.0/18 7843 Adelphia Corp. 24.142.40.0/21 7018 AT&T WorldNet Services 24.142.160.0/19 7018 AT&T WorldNet Services 24.246.0.0/17 7018 AT&T WorldNet Services 24.246.128.0/18 7018 AT&T WorldNet Services 62.61.220.0/24 24974 Tachyon Europe BV - Wireless 63.140.213.0/24 22555 Universal Talkware Corporatio Complete listing at http://thyme.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:19 /9:9 /10:16 /11:42 /12:142 /13:279 /14:514 /15:1027 /16:9940 /17:4313 /18:7286 /19:15460 /20:17926 /21:17392 /22:21972 /23:22960 /24:135388 /25:805 /26:951 /27:488 /28:81 /29:9 /30:1 /31:0 /32:9 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6389 1356 2208 bellsouth.net, inc. 11492 1210 1228 Cable One 2386 1137 1439 AT&T Data Communications Serv 18566 1025 1044 Covad Communications 4755 989 1642 Videsh Sanchar Nigam Ltd. Aut 9583 966 1112 Sify Limited 6478 950 951 AT&T Worldnet Services 7011 943 1051 Citizens Utilities 6298 941 956 Cox Communicatons 17488 904 1078 Hathway IP Over Cable Interne Complete listing at http://thyme.apnic.net/current/data/sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 4:9 8:109 12:2058 13:1 15:22 16:3 17:5 18:13 20:35 24:1077 25:1 32:62 33:3 38:436 40:93 41:642 43:1 44:2 47:12 52:3 55:4 56:3 57:23 58:514 59:478 60:442 61:996 62:1116 63:1946 64:3324 65:2424 66:3692 67:1209 68:695 69:2245 70:676 71:126 72:1815 73:5 74:994 75:220 76:297 77:704 78:696 79:187 80:909 81:843 82:569 83:390 84:568 85:1019 86:421 87:677 88:314 89:1251 90:11 91:1283 92:180 93:517 96:32 97:23 98:191 99:3 111:1 114:20 116:661 117:327 118:141 119:445 120:57 121:532 122:780 123:340 124:847 125:1139 128:324 129:202 130:131 131:402 132:66 133:9 134:177 135:33 136:219 137:91 138:152 139:71 140:497 141:99 142:401 143:324 144:351 145:51 146:364 147:153 148:506 149:191 150:130 151:193 152:141 153:135 154:10 155:249 156:174 157:272 158:168 159:221 160:256 161:114 162:231 163:187 164:525 165:446 166:317 167:328 168:612 169:131 170:428 171:29 172:10 189:189 190:2068 192:5804 193:4100 194:3209 195:2464 196:1071 198:3748 199:3259 200:5577 201:1420 202:7617 203:7893 204:3973 205:2087 206:2397 207:2749 208:3353 209:3441 210:2520 211:1023 212:1393 213:1623 214:164 215:49 216:4372 217:1188 218:346 219:414 220:1077 221:464 222:306 End of report From DLasher at newedgenetworks.com Fri Jun 6 13:24:18 2008 From: DLasher at newedgenetworks.com (Lasher, Donn) Date: Fri, 6 Jun 2008 11:24:18 -0700 Subject: OT: www.Amazon.com down? In-Reply-To: References: Message-ID: Checked, and doublechecked, not just me www.amazon.com returns: Http/1.1 Service Unavailable Anyone have a URL for a network/etc status page, or info on the outage? Been that way for a while this morning. -donn From jra at baylink.com Fri Jun 6 13:27:23 2008 From: jra at baylink.com (Jay R. Ashworth) Date: Fri, 6 Jun 2008 14:27:23 -0400 Subject: OT: www.Amazon.com down? In-Reply-To: References: Message-ID: <20080606182723.GE10911@cgi.jachomes.com> On Fri, Jun 06, 2008 at 11:24:18AM -0700, Lasher, Donn wrote: > Checked, and doublechecked, not just me > > www.amazon.com returns: > > Http/1.1 Service Unavailable > > Anyone have a URL for a network/etc status page, or info on the outage? > Been that way for a while this morning. Confirmed from L3/Tampa, 64.31.159.157 My mtr trace deadends at ae-11-79.car1.Washington3.Level3... [outages], perhaps? Cheers, -- jra -- Jay R. Ashworth jra at baylink.com Designer +-Internetworking------+---------+ RFC 2100 Ashworth & Associates | Best Practices Wiki | | '87 e24 St Petersburg FL USA +-http://bestpractices.wikia.com-+ +1 727 647 1274 If you can read this... thank a system administrator. Or two. --me From surfer at mauigateway.com Fri Jun 6 13:28:32 2008 From: surfer at mauigateway.com (Scott Weeks) Date: Fri, 6 Jun 2008 11:28:32 -0700 Subject: OT: www.Amazon.com down? Message-ID: <20080606112832.35B8828C@resin11.mta.everyone.net> --- DLasher at newedgenetworks.com wrote: From: "Lasher, Donn" Checked, and doublechecked, not just me www.amazon.com returns: Http/1.1 Service Unavailable Anyone have a URL for a network/etc status page, or info on the outage? Been that way for a while this morning. ------------------------------------------------------- It's not just you. I was not able to make a purchases yesterday, but the site was still functional for the most part. Something big is happening there... scott From cstone at axint.net Fri Jun 6 13:29:16 2008 From: cstone at axint.net (Chris Stone) Date: Fri, 6 Jun 2008 12:29:16 -0600 Subject: OT: www.Amazon.com down? In-Reply-To: References: Message-ID: <200806061229.21215.cstone@axint.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday 06 June 2008 12:24:18 pm Lasher, Donn wrote: > Checked, and doublechecked, not just me > > www.amazon.com returns: > > Http/1.1 Service Unavailable > > Anyone have a URL for a network/etc status page, or info on the outage? > Been that way for a while this morning. I get that also with http://www.amazon.com, but do get the site using http://www.amazon.com/tag/unavailable and then all links on the page though click to the error - although the images on the page are all fine. Chris - -- Chris Stone, MCSE Vice President, CTO AxisInternet, Inc. http://www.axint.net DSL, dialup, hosting, email filtering, co-location, online backup Phone: +1 303 592 2947 x302 (office) +1 303 570 6947 (cell) - ------------------------------------------------------------------------- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkhJgfwACgkQnSVip47FEdOY9wCgjCUjwLQ12enmUtQ+pDJB1n7r oKsAoI9e1d2i9yhf6cCG3uX0En7GF2pR =EDU4 -----END PGP SIGNATURE----- From patrick at ianai.net Fri Jun 6 13:31:28 2008 From: patrick at ianai.net (Patrick W. Gilmore) Date: Fri, 6 Jun 2008 14:31:28 -0400 Subject: OT: www.Amazon.com down? In-Reply-To: <20080606112832.35B8828C@resin11.mta.everyone.net> References: <20080606112832.35B8828C@resin11.mta.everyone.net> Message-ID: --- DLasher at newedgenetworks.com wrote: > From: "Lasher, Donn" > > Checked, and doublechecked, not just me > > www.amazon.com returns: > > Http/1.1 Service Unavailable > > Anyone have a URL for a network/etc status page, or info on the > outage? > Been that way for a while this morning. HTTPS works. -- TTFN, patrick From gds at gds.best.vwh.net Fri Jun 6 13:32:06 2008 From: gds at gds.best.vwh.net (Greg Skinner) Date: Fri, 6 Jun 2008 18:32:06 +0000 Subject: OT: www.Amazon.com down? In-Reply-To: ; from DLasher@newedgenetworks.com on Fri, Jun 06, 2008 at 11:24:18AM -0700 References: Message-ID: <20080606183206.A29752@gds.best.vwh.net> On Fri, Jun 06, 2008 at 11:24:18AM -0700, Lasher, Donn wrote: > Checked, and doublechecked, not just me > > www.amazon.com returns: > > Http/1.1 Service Unavailable > > Anyone have a URL for a network/etc status page, or info on the outage? > Been that way for a while this morning. c|net article says: http://news.cnet.com/8301-10784_3-9962010-7.html?tag=nefd.top https works for some pages From michele at blacknight.ie Fri Jun 6 13:32:15 2008 From: michele at blacknight.ie (Michele Neylon) Date: Fri, 06 Jun 2008 19:32:15 +0100 Subject: OT: www.Amazon.com down? In-Reply-To: References: Message-ID: <484982AF.2090400@blacknight.ie> Lasher, Donn wrote: > Checked, and doublechecked, not just me > > www.amazon.com returns: > > Http/1.1 Service Unavailable > > Anyone have a URL for a network/etc status page, or info on the outage? > Been that way for a while this morning. > > -donn > > The web services still seem to be running and the co.uk site is up -- Mr Michele Neylon Blacknight Solutions Hosting & Colocation, Brand Protection http://www.blacknight.com/ http://blog.blacknight.com/ Tel. 1850 929 929 Intl. +353 (0) 59 9183072 Direct Dial: +353 (0)59 9183090 Fax. +353 (0) 1 4811 763 ------------------------------- Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty Road,Graiguecullen,Carlow,Ireland Company No.: 370845 From morrowc.lists at gmail.com Fri Jun 6 13:33:43 2008 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 6 Jun 2008 14:33:43 -0400 Subject: OT: www.Amazon.com down? In-Reply-To: <200806061229.21215.cstone@axint.net> References: <200806061229.21215.cstone@axint.net> Message-ID: <75cb24520806061133p3a3f9f8bk1b56e5d4f1bcd448@mail.gmail.com> On Fri, Jun 6, 2008 at 2:29 PM, Chris Stone wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Friday 06 June 2008 12:24:18 pm Lasher, Donn wrote: >> Checked, and doublechecked, not just me >> >> www.amazon.com returns: >> and to pile on... http://www.downforeveryoneorjustme.com/www.amazon.com down as of - 2008-06-06 14:33:38 - now. From gtb at slac.stanford.edu Fri Jun 6 13:34:07 2008 From: gtb at slac.stanford.edu (Buhrmaster, Gary) Date: Fri, 6 Jun 2008 11:34:07 -0700 Subject: www.Amazon.com down? In-Reply-To: References: Message-ID: > www.amazon.com returns: > > Http/1.1 Service Unavailable > > Anyone have a URL for a network/etc status page, or info on > the outage? Been that way for a while this morning. Apparently, Amazon has fallen over, and cannot get up. http://news.cnet.com/8301-10784_3-9962010-7.html From freimer at ctiusa.com Fri Jun 6 13:38:16 2008 From: freimer at ctiusa.com (Fred Reimer) Date: Fri, 6 Jun 2008 14:38:16 -0400 Subject: OT: www.Amazon.com down? In-Reply-To: <20080606112832.35B8828C@resin11.mta.everyone.net> References: <20080606112832.35B8828C@resin11.mta.everyone.net> Message-ID: <98B7739FB65BF04F9B3233AB842EEC9502A33489@EXCHANGE.ctiusa.com> Yea, an hour and a half ago the PS3 80G bundle with Metal Gear Solid 4 was opened up for pre-purchase. ;-) Fred Reimer, CISSP, CCNP, CQS-VPN, CQS-ISS Senior Network Engineer Coleman Technologies, Inc. 954-298-1697 -----Original Message----- From: Scott Weeks [mailto:surfer at mauigateway.com] Sent: Friday, June 06, 2008 2:29 PM To: nanog at nanog.org Subject: Re: OT: www.Amazon.com down? --- DLasher at newedgenetworks.com wrote: From: "Lasher, Donn" Checked, and doublechecked, not just me www.amazon.com returns: Http/1.1 Service Unavailable Anyone have a URL for a network/etc status page, or info on the outage? Been that way for a while this morning. ------------------------------------------------------- It's not just you. I was not able to make a purchases yesterday, but the site was still functional for the most part. Something big is happening there... scott From toasty at dragondata.com Fri Jun 6 13:40:18 2008 From: toasty at dragondata.com (Kevin Day) Date: Fri, 6 Jun 2008 13:40:18 -0500 Subject: How not to make an error page (was: OT: www.Amazon.com down?) In-Reply-To: References: Message-ID: On Jun 6, 2008, at 1:24 PM, Lasher, Donn wrote: > Checked, and doublechecked, not just me > > www.amazon.com returns: > > Http/1.1 Service Unavailable > > Anyone have a URL for a network/etc status page, or info on the > outage? > Been that way for a while this morning. > > -donn > > Even worse, the page they're displaying is actually a HTTP 200 response code(OK/no error), with no "Don't cache this" header - which means their error page is considered cacheable by some browsers/ proxies. So, you may find users who tried to visit Amazon while they were down are still seeing it down long after they fix it. Lesson to high profile websites: add these to your error pages so you don't have people complaining you're still down long after you're fixed. * Don't return a 200 response code. Use 500 or 503. Nothing from 2xx or 4xx. * Add a "Cache-control: no-cache, must-revalidate, max-age=0" header, as well as an "Expires: 0" header for good measure. * If your server is really borked and you can't add headers at all, add '' to the section. That's not as good, but helps at least on the browser end. * If possible, add a timestamp to the page somewhere (even if it's in an HTML comment) so you can troubleshoot with users still seeing the error. -- Kevin From tj at kniveton.com Fri Jun 6 13:41:46 2008 From: tj at kniveton.com (T.J. Kniveton) Date: Fri, 06 Jun 2008 11:41:46 -0700 Subject: OT: www.Amazon.com down? In-Reply-To: <20080606183206.A29752@gds.best.vwh.net> References: <20080606183206.A29752@gds.best.vwh.net> Message-ID: <1212777706.2632.4.camel@tj-desktop.nokia.net> 500 bucks per second.. that hurts. On Fri, 2008-06-06 at 18:32 +0000, Greg Skinner wrote: > c|net article says: http://news.cnet.com/8301-10784_3-9962010-7.html?tag=nefd.top > Based on last quarter's revenue of $4.13 billion, a full-scale global > outage would cost Amazon more than $31,000 per minute on average. From wschultz at bsdboy.com Fri Jun 6 13:46:23 2008 From: wschultz at bsdboy.com (Wil Schultz) Date: Fri, 6 Jun 2008 11:46:23 -0700 Subject: www.Amazon.com down? In-Reply-To: References: Message-ID: <780C8CBA-1E5E-44D5-8E5F-4DAA7703299E@bsdboy.com> https seems to work. -wil On Jun 6, 2008, at 11:34 AM, Buhrmaster, Gary wrote: >> www.amazon.com returns: >> >> Http/1.1 Service Unavailable >> >> Anyone have a URL for a network/etc status page, or info on >> the outage? Been that way for a while this morning. > > Apparently, Amazon has fallen over, and cannot get up. > > http://news.cnet.com/8301-10784_3-9962010-7.html > > > From Andy.Litzinger at theplatform.com Fri Jun 6 13:49:42 2008 From: Andy.Litzinger at theplatform.com (Andy Litzinger) Date: Fri, 6 Jun 2008 11:49:42 -0700 Subject: How not to make an error page (was: OT: www.Amazon.com down?) In-Reply-To: References: Message-ID: <1A9866F953006D45AEE0166066114E09104BC66D@TPMAIL02.corp.theplatform.com> I've no idea what Amazon uses for Load Balancers, but I'm pretty sure that error message is the default error message served up by a Netscaler LB if no web services are available in the pool... -andy > -----Original Message----- > From: Kevin Day [mailto:toasty at dragondata.com] > Sent: Friday, June 06, 2008 11:40 AM > To: Lasher, Donn > Cc: nanog at nanog.org > Subject: How not to make an error page (was: OT: www.Amazon.com down?) > > > On Jun 6, 2008, at 1:24 PM, Lasher, Donn wrote: > > > Checked, and doublechecked, not just me > > > > www.amazon.com returns: > > > > Http/1.1 Service Unavailable > > > > Anyone have a URL for a network/etc status page, or info on the > > outage? > > Been that way for a while this morning. > > > > -donn > > > > > > Even worse, the page they're displaying is actually a HTTP 200 > response code(OK/no error), with no "Don't cache this" header - which > means their error page is considered cacheable by some browsers/ > proxies. So, you may find users who tried to visit Amazon while they > were down are still seeing it down long after they fix it. > > Lesson to high profile websites: add these to your error pages so you > don't have people complaining you're still down long after you're > fixed. > > * Don't return a 200 response code. Use 500 or 503. Nothing from 2xx > or 4xx. > * Add a "Cache-control: no-cache, must-revalidate, max-age=0" header, > as well as an "Expires: 0" header for good measure. > * If your server is really borked and you can't add headers at all, > add '' to the > section. That's not as good, but helps at least on the browser end. > * If possible, add a timestamp to the page somewhere (even if it's in > an HTML comment) so you can troubleshoot with users still seeing the > error. > > -- Kevin > From eriktown at gmail.com Fri Jun 6 13:58:19 2008 From: eriktown at gmail.com (Bjorn Townsend) Date: Fri, 6 Jun 2008 11:58:19 -0700 Subject: How not to make an error page (was: OT: www.Amazon.com down?) In-Reply-To: <1A9866F953006D45AEE0166066114E09104BC66D@TPMAIL02.corp.theplatform.com> References: <1A9866F953006D45AEE0166066114E09104BC66D@TPMAIL02.corp.theplatform.com> Message-ID: <971b06520806061158s1b8efb44o58c17ee518a64fd6@mail.gmail.com> Good guess. AFAIK Amazon uses mostly Netscaler, with some homegrown stuff and a few F5 boxes. On Fri, Jun 6, 2008 at 11:49 AM, Andy Litzinger wrote: > I've no idea what Amazon uses for Load Balancers, but I'm pretty sure > that error message is the default error message served up by a Netscaler > LB if no web services are available in the pool... > > -andy > >> -----Original Message----- >> From: Kevin Day [mailto:toasty at dragondata.com] >> Sent: Friday, June 06, 2008 11:40 AM >> To: Lasher, Donn >> Cc: nanog at nanog.org >> Subject: How not to make an error page (was: OT: www.Amazon.com down?) >> >> >> On Jun 6, 2008, at 1:24 PM, Lasher, Donn wrote: >> >> > Checked, and doublechecked, not just me >> > >> > www.amazon.com returns: >> > >> > Http/1.1 Service Unavailable >> > >> > Anyone have a URL for a network/etc status page, or info on the >> > outage? >> > Been that way for a while this morning. >> > >> > -donn >> > >> > >> >> Even worse, the page they're displaying is actually a HTTP 200 >> response code(OK/no error), with no "Don't cache this" header - which >> means their error page is considered cacheable by some browsers/ >> proxies. So, you may find users who tried to visit Amazon while they >> were down are still seeing it down long after they fix it. >> >> Lesson to high profile websites: add these to your error pages so you >> don't have people complaining you're still down long after you're >> fixed. >> >> * Don't return a 200 response code. Use 500 or 503. Nothing from 2xx >> or 4xx. >> * Add a "Cache-control: no-cache, must-revalidate, max-age=0" header, >> as well as an "Expires: 0" header for good measure. >> * If your server is really borked and you can't add headers at all, >> add '' to the >> section. That's not as good, but helps at least on the browser end. >> * If possible, add a timestamp to the page somewhere (even if it's in >> an HTML comment) so you can troubleshoot with users still seeing the >> error. >> >> -- Kevin >> > > > -- Bjorn Townsend | eriktown at gmail.com From ml at t-b-o-h.net Fri Jun 6 13:58:52 2008 From: ml at t-b-o-h.net (Tuc at T-B-O-H.NET) Date: Fri, 6 Jun 2008 14:58:52 -0400 (EDT) Subject: How not to make an error page (was: OT: www.Amazon.com down?) In-Reply-To: <1A9866F953006D45AEE0166066114E09104BC66D@TPMAIL02.corp.theplatform.com> Message-ID: <200806061858.m56IwqME075697@himinbjorg.tucs-beachin-obx-house.com> Maybe they should buy time on their own EC2 if they are short of webservers. :) The staus page http://status.aws.amazon.com/ shows them "Green and Clean" Tuc > > I've no idea what Amazon uses for Load Balancers, but I'm pretty sure > that error message is the default error message served up by a Netscaler > LB if no web services are available in the pool... > > -andy > > > -----Original Message----- > > From: Kevin Day [mailto:toasty at dragondata.com] > > Sent: Friday, June 06, 2008 11:40 AM > > To: Lasher, Donn > > Cc: nanog at nanog.org > > Subject: How not to make an error page (was: OT: www.Amazon.com down?) > > > > > > On Jun 6, 2008, at 1:24 PM, Lasher, Donn wrote: > > > > > Checked, and doublechecked, not just me > > > > > > www.amazon.com returns: > > > > > > Http/1.1 Service Unavailable > > > > > > Anyone have a URL for a network/etc status page, or info on the > > > outage? > > > Been that way for a while this morning. > > > > > > -donn > > > > > > > > > > Even worse, the page they're displaying is actually a HTTP 200 > > response code(OK/no error), with no "Don't cache this" header - which > > means their error page is considered cacheable by some browsers/ > > proxies. So, you may find users who tried to visit Amazon while they > > were down are still seeing it down long after they fix it. > > > > Lesson to high profile websites: add these to your error pages so you > > don't have people complaining you're still down long after you're > > fixed. > > > > * Don't return a 200 response code. Use 500 or 503. Nothing from 2xx > > or 4xx. > > * Add a "Cache-control: no-cache, must-revalidate, max-age=0" header, > > as well as an "Expires: 0" header for good measure. > > * If your server is really borked and you can't add headers at all, > > add '' to the > > section. That's not as good, but helps at least on the browser end. > > * If possible, add a timestamp to the page somewhere (even if it's in > > an HTML comment) so you can troubleshoot with users still seeing the > > error. > > > > -- Kevin > > > > > From itmailinglist at connection2.com Fri Jun 6 14:02:44 2008 From: itmailinglist at connection2.com (IT Mailing List) Date: Fri, 06 Jun 2008 20:02:44 +0100 Subject: www.Amazon.com down? In-Reply-To: <780C8CBA-1E5E-44D5-8E5F-4DAA7703299E@bsdboy.com> References: <780C8CBA-1E5E-44D5-8E5F-4DAA7703299E@bsdboy.com> Message-ID: <484989D4.8000609@connection2.com> Amazon.com seems to be back up. Alexander Wil Schultz wrote: > https seems to work. > > -wil > > On Jun 6, 2008, at 11:34 AM, Buhrmaster, Gary wrote: > >>> www.amazon.com returns: >>> >>> Http/1.1 Service Unavailable >>> >>> Anyone have a URL for a network/etc status page, or info on >>> the outage? Been that way for a while this morning. >> >> Apparently, Amazon has fallen over, and cannot get up. >> >> http://news.cnet.com/8301-10784_3-9962010-7.html >> >> >> > > From jra at baylink.com Fri Jun 6 14:18:00 2008 From: jra at baylink.com (Jay R. Ashworth) Date: Fri, 6 Jun 2008 15:18:00 -0400 Subject: www.Amazon.com down? In-Reply-To: <484989D4.8000609@connection2.com> References: <780C8CBA-1E5E-44D5-8E5F-4DAA7703299E@bsdboy.com> <484989D4.8000609@connection2.com> Message-ID: <20080606191800.GG10911@cgi.jachomes.com> On Fri, Jun 06, 2008 at 08:02:44PM +0100, IT Mailing List wrote: > Amazon.com seems to be back up. >From here, it's only the homepage; clickthroughs and searches are still down. -- j -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com '87 e24 St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 Those who cast the vote decide nothing. Those who count the vote decide everything. -- (Joseph Stalin) From jra at baylink.com Fri Jun 6 14:18:00 2008 From: jra at baylink.com (Jay R. Ashworth) Date: Fri, 6 Jun 2008 15:18:00 -0400 Subject: www.Amazon.com down? In-Reply-To: <484989D4.8000609@connection2.com> References: <780C8CBA-1E5E-44D5-8E5F-4DAA7703299E@bsdboy.com> <484989D4.8000609@connection2.com> Message-ID: <20080606191800.GG10911@cgi.jachomes.com> On Fri, Jun 06, 2008 at 08:02:44PM +0100, IT Mailing List wrote: > Amazon.com seems to be back up. >From here, it's only the homepage; clickthroughs and searches are still down. -- j -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com '87 e24 St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 Those who cast the vote decide nothing. Those who count the vote decide everything. -- (Joseph Stalin) From freimer at ctiusa.com Fri Jun 6 14:17:53 2008 From: freimer at ctiusa.com (Fred Reimer) Date: Fri, 6 Jun 2008 15:17:53 -0400 Subject: How not to make an error page (was: OT: www.Amazon.com down?) In-Reply-To: <971b06520806061158s1b8efb44o58c17ee518a64fd6@mail.gmail.com> References: <1A9866F953006D45AEE0166066114E09104BC66D@TPMAIL02.corp.theplatform.com> <971b06520806061158s1b8efb44o58c17ee518a64fd6@mail.gmail.com> Message-ID: <98B7739FB65BF04F9B3233AB842EEC9502A334BD@EXCHANGE.ctiusa.com> The actual headers returned are: Server: NS_6.1 Content-Length: 62 Connection: close 503 Service Unavailable Fred Reimer, CISSP, CCNP, CQS-VPN, CQS-ISS Senior Network Engineer Coleman Technologies, Inc. 954-298-1697 -----Original Message----- From: Bjorn Townsend [mailto:eriktown at gmail.com] Sent: Friday, June 06, 2008 2:58 PM To: Andy Litzinger Cc: nanog at nanog.org Subject: Re: How not to make an error page (was: OT: www.Amazon.com down?) Good guess. AFAIK Amazon uses mostly Netscaler, with some homegrown stuff and a few F5 boxes. On Fri, Jun 6, 2008 at 11:49 AM, Andy Litzinger wrote: > I've no idea what Amazon uses for Load Balancers, but I'm pretty sure > that error message is the default error message served up by a Netscaler > LB if no web services are available in the pool... > > -andy > >> -----Original Message----- >> From: Kevin Day [mailto:toasty at dragondata.com] >> Sent: Friday, June 06, 2008 11:40 AM >> To: Lasher, Donn >> Cc: nanog at nanog.org >> Subject: How not to make an error page (was: OT: www.Amazon.com down?) >> >> >> On Jun 6, 2008, at 1:24 PM, Lasher, Donn wrote: >> >> > Checked, and doublechecked, not just me >> > >> > www.amazon.com returns: >> > >> > Http/1.1 Service Unavailable >> > >> > Anyone have a URL for a network/etc status page, or info on the >> > outage? >> > Been that way for a while this morning. >> > >> > -donn >> > >> > >> >> Even worse, the page they're displaying is actually a HTTP 200 >> response code(OK/no error), with no "Don't cache this" header - which >> means their error page is considered cacheable by some browsers/ >> proxies. So, you may find users who tried to visit Amazon while they >> were down are still seeing it down long after they fix it. >> >> Lesson to high profile websites: add these to your error pages so you >> don't have people complaining you're still down long after you're >> fixed. >> >> * Don't return a 200 response code. Use 500 or 503. Nothing from 2xx >> or 4xx. >> * Add a "Cache-control: no-cache, must-revalidate, max-age=0" header, >> as well as an "Expires: 0" header for good measure. >> * If your server is really borked and you can't add headers at all, >> add '' to the >> section. That's not as good, but helps at least on the browser end. >> * If possible, add a timestamp to the page somewhere (even if it's in >> an HTML comment) so you can troubleshoot with users still seeing the >> error. >> >> -- Kevin >> > > > -- Bjorn Townsend | eriktown at gmail.com From nanog304985 at aquick.org Fri Jun 6 14:19:23 2008 From: nanog304985 at aquick.org (Adam Fields) Date: Fri, 6 Jun 2008 15:19:23 -0400 Subject: OT: www.Amazon.com down? In-Reply-To: References: Message-ID: <20080606191923.GF22025@lola.aquick.org> On Fri, Jun 06, 2008 at 11:24:18AM -0700, Lasher, Donn wrote: > Checked, and doublechecked, not just me > > www.amazon.com returns: > > Http/1.1 Service Unavailable > > Anyone have a URL for a network/etc status page, or info on the outage? > Been that way for a while this morning. This is rather suspicious (and confirmed by three other people): ------------------------------------------------ $ whois amazon.com Whois Server Version 2.0 Domain names in the .com and .net domains can now be registered with many different competing registrars. Go to http://www.internic.net for detailed information. AMAZON.COM.ZZZZZ.GET.LAID.AT.WWW.SWINGINGCOMMUNITY.COM AMAZON.COM.MORE.INFO.AT.WWW.BEYONDWHOIS.COM AMAZON.COM.IS.N0T.AS.1337.AS.WWW.GULLI.COM AMAZON.COM ------------------------------------------------ whois for yahoo.com and google.com yield similar results. I expect this means that DNS has been compromised somewhere. -- - Adam ** Expert Technical Project and Business Management **** System Performance Analysis and Architecture ****** [ http://www.adamfields.com ] [ http://www.morningside-analytics.com ] .. Latest Venture [ http://www.confabb.com ] ................ Founder [ http://www.aquick.org/blog ] ............ Blog [ http://www.adamfields.com/resume.html ].. Experience [ http://www.flickr.com/photos/fields ] ... Photos [ http://www.aquicki.com/wiki ].............Wiki From wschultz at bsdboy.com Fri Jun 6 14:22:25 2008 From: wschultz at bsdboy.com (Wil Schultz) Date: Fri, 6 Jun 2008 12:22:25 -0700 Subject: How not to make an error page (was: OT: www.Amazon.com down?) In-Reply-To: References: Message-ID: <87E93E0D-A758-4B88-A3A4-AC502E887F96@bsdboy.com> I see a 503 actually. When down: iWil:~ wschultz$ curl www.amazon.com HTTP/1.1 503 Service Unavailable Server: NS_6.1 Content-Length:62 Connection: close iWil:~ wschultz$ wget -S www.amazon.com --12:21:26-- http://www.amazon.com/ => `index.html' Resolving www.amazon.com... 72.21.206.5 Connecting to www.amazon.com|72.21.206.5|:80... connected. HTTP request sent, awaiting response... HTTP/1.1 503 Service Unavailable Server: NS_6.1 Content-Length:62 Connection: close 12:21:26 ERROR 503: Service Unavailable. -wil On Jun 6, 2008, at 11:40 AM, Kevin Day wrote: > On Jun 6, 2008, at 1:24 PM, Lasher, Donn wrote: > >> Checked, and doublechecked, not just me >> >> www.amazon.com returns: >> >> Http/1.1 Service Unavailable >> >> Anyone have a URL for a network/etc status page, or info on the >> outage? >> Been that way for a while this morning. >> >> -donn >> >> > > Even worse, the page they're displaying is actually a HTTP 200 > response code(OK/no error), with no "Don't cache this" header - > which means their error page is considered cacheable by some > browsers/proxies. So, you may find users who tried to visit Amazon > while they were down are still seeing it down long after they fix it. > > Lesson to high profile websites: add these to your error pages so > you don't have people complaining you're still down long after > you're fixed. > > * Don't return a 200 response code. Use 500 or 503. Nothing from 2xx > or 4xx. > * Add a "Cache-control: no-cache, must-revalidate, max-age=0" > header, as well as an "Expires: 0" header for good measure. > * If your server is really borked and you can't add headers at all, > add '' to the > section. That's not as good, but helps at least on the browser end. > * If possible, add a timestamp to the page somewhere (even if it's > in an HTML comment) so you can troubleshoot with users still seeing > the error. > > -- Kevin > > From david at davidcoulson.net Fri Jun 6 14:22:55 2008 From: david at davidcoulson.net (David Coulson) Date: Fri, 06 Jun 2008 15:22:55 -0400 Subject: www.Amazon.com down? In-Reply-To: <20080606191800.GG10911@cgi.jachomes.com> References: <780C8CBA-1E5E-44D5-8E5F-4DAA7703299E@bsdboy.com> <484989D4.8000609@connection2.com> <20080606191800.GG10911@cgi.jachomes.com> Message-ID: <48498E8F.10207@davidcoulson.net> They took someone's advice, because it 503s now :) David From jay at west.net Fri Jun 6 14:27:09 2008 From: jay at west.net (Jay Hennigan) Date: Fri, 06 Jun 2008 12:27:09 -0700 Subject: www.Amazon.com down? In-Reply-To: <20080606191800.GG10911@cgi.jachomes.com> References: <780C8CBA-1E5E-44D5-8E5F-4DAA7703299E@bsdboy.com> <484989D4.8000609@connection2.com> <20080606191800.GG10911@cgi.jachomes.com> Message-ID: <48498F8D.1080306@west.net> Jay R. Ashworth wrote: > On Fri, Jun 06, 2008 at 08:02:44PM +0100, IT Mailing List wrote: >> Amazon.com seems to be back up. > >>From here, it's only the homepage; clickthroughs and searches are still down. Same here. Amusingly, the first item recommended on my home page is "IT Disaster Recovery Planning For Dummies." -- Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net Impulse Internet Service - http://www.impulse.net/ Your local telephone and internet company - 805 884-6323 - WB6RDV From jay at west.net Fri Jun 6 14:30:04 2008 From: jay at west.net (Jay Hennigan) Date: Fri, 06 Jun 2008 12:30:04 -0700 Subject: OT: www.Amazon.com down? In-Reply-To: <20080606191923.GF22025@lola.aquick.org> References: <20080606191923.GF22025@lola.aquick.org> Message-ID: <4849903C.9050909@west.net> Adam Fields wrote: > This is rather suspicious (and confirmed by three other people): > > ------------------------------------------------ > $ whois amazon.com > > AMAZON.COM.ZZZZZ.GET.LAID.AT.WWW.SWINGINGCOMMUNITY.COM > AMAZON.COM.MORE.INFO.AT.WWW.BEYONDWHOIS.COM > AMAZON.COM.IS.N0T.AS.1337.AS.WWW.GULLI.COM > AMAZON.COM > ------------------------------------------------ > > whois for yahoo.com and google.com yield similar results. > > I expect this means that DNS has been compromised somewhere. No compromise, just people getting cute by registering host records. Microsoft.com is a mild example... -- Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net Impulse Internet Service - http://www.impulse.net/ Your local telephone and internet company - 805 884-6323 - WB6RDV From regnauld at catpipe.net Fri Jun 6 14:28:35 2008 From: regnauld at catpipe.net (Phil Regnauld) Date: Fri, 6 Jun 2008 21:28:35 +0200 Subject: OT: www.Amazon.com down? In-Reply-To: <20080606191923.GF22025@lola.aquick.org> References: <20080606191923.GF22025@lola.aquick.org> Message-ID: <20080606192834.GA82098@catpipe.net> Adam Fields (nanog304985) writes: > whois for yahoo.com and google.com yield similar results. And microsoft as well maybe ? MICROSOFT.COM.ARE.GODDAMN.PIGFUCKERS.NET.NS-NOT-IN-SERVICE.COM MICROSOFT.COM.AND.MINDSUCK.BOTH.SUCK.HUGE.ONES.AT.EXEGETE.NET MICROSOFT.COM > I expect this means that DNS has been compromised somewhere. No, you should just learn to read WHOIS output :) From david at davidcoulson.net Fri Jun 6 14:30:03 2008 From: david at davidcoulson.net (David Coulson) Date: Fri, 06 Jun 2008 15:30:03 -0400 Subject: OT: www.Amazon.com down? In-Reply-To: <20080606191923.GF22025@lola.aquick.org> References: <20080606191923.GF22025@lola.aquick.org> Message-ID: <4849903B.302@davidcoulson.net> > I expect this means that DNS has been compromised somewhere. > I see that whois is wonky, but DNS looks right. cr1:~# dig amazon.com @j.gtld-servers.net | grep NS ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 2 amazon.com. 172800 IN NS udns1.ultradns.net. amazon.com. 172800 IN NS udns2.ultradns.net. There is weird whois data for facebook.com, youtube.com, myspace.com and some others From swinog at blinkenlights.ch Fri Jun 6 14:29:53 2008 From: swinog at blinkenlights.ch (Adrian Ulrich) Date: Fri, 6 Jun 2008 21:29:53 +0200 Subject: OT: www.Amazon.com down? In-Reply-To: <20080606191923.GF22025@lola.aquick.org> References: <20080606191923.GF22025@lola.aquick.org> Message-ID: <20080606192954.104E9214066@blinkenlights.ch> > I expect this means that DNS has been compromised somewhere. Ehr.. no: http://www.google.ch/search?q=AMAZON.COM.IS.N0T.AS.1337.AS.WWW.GULLI.COM -- RFC 1925: (11) Every old idea will be proposed again with a different name and a different presentation, regardless of whether it works. From nanog304985 at aquick.org Fri Jun 6 14:31:06 2008 From: nanog304985 at aquick.org (Adam Fields) Date: Fri, 6 Jun 2008 15:31:06 -0400 Subject: OT: www.Amazon.com down? In-Reply-To: <20080606191923.GF22025@lola.aquick.org> References: <20080606191923.GF22025@lola.aquick.org> Message-ID: <20080606193106.GG22025@lola.aquick.org> On Fri, Jun 06, 2008 at 03:19:23PM -0400, Adam Fields wrote: [...]> I expect this means that DNS has been compromised somewhere. Nevermind - I've been informed that this is just overly aggressive string matching. From michele at blacknight.ie Fri Jun 6 14:36:09 2008 From: michele at blacknight.ie (Michele Neylon) Date: Fri, 06 Jun 2008 20:36:09 +0100 Subject: www.Amazon.com down? In-Reply-To: <48498F8D.1080306@west.net> References: <780C8CBA-1E5E-44D5-8E5F-4DAA7703299E@bsdboy.com> <484989D4.8000609@connection2.com> <20080606191800.GG10911@cgi.jachomes.com> <48498F8D.1080306@west.net> Message-ID: <484991A9.9060409@blacknight.ie> Twitter's down again now as well, so at least there's some normality :) -- Mr Michele Neylon Blacknight Solutions Hosting & Colocation, Brand Protection http://www.blacknight.com/ http://blog.blacknight.com/ Tel. 1850 929 929 Intl. +353 (0) 59 9183072 Direct Dial: +353 (0)59 9183090 Fax. +353 (0) 1 4811 763 ------------------------------- Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty Road,Graiguecullen,Carlow,Ireland Company No.: 370845 From darden at armc.org Fri Jun 6 14:40:55 2008 From: darden at armc.org (Darden, Patrick S.) Date: Fri, 6 Jun 2008 15:40:55 -0400 Subject: OT: www.Amazon.com down? In-Reply-To: <20080606191923.GF22025@lola.aquick.org> Message-ID: I cannot reproduce this. --Patrick Darden -----Original Message----- From: Adam Fields [mailto:nanog304985 at aquick.org] Sent: Friday, June 06, 2008 3:19 PM To: Lasher, Donn Cc: nanog at nanog.org Subject: Re: OT: www.Amazon.com down? On Fri, Jun 06, 2008 at 11:24:18AM -0700, Lasher, Donn wrote: > Checked, and doublechecked, not just me > > www.amazon.com returns: > > Http/1.1 Service Unavailable > > Anyone have a URL for a network/etc status page, or info on the outage? > Been that way for a while this morning. This is rather suspicious (and confirmed by three other people): ------------------------------------------------ $ whois amazon.com Whois Server Version 2.0 Domain names in the .com and .net domains can now be registered with many different competing registrars. Go to http://www.internic.net for detailed information. AMAZON.COM.ZZZZZ.GET.LAID.AT.WWW.SWINGINGCOMMUNITY.COM AMAZON.COM.MORE.INFO.AT.WWW.BEYONDWHOIS.COM AMAZON.COM.IS.N0T.AS.1337.AS.WWW.GULLI.COM AMAZON.COM ------------------------------------------------ whois for yahoo.com and google.com yield similar results. I expect this means that DNS has been compromised somewhere. -- - Adam ** Expert Technical Project and Business Management **** System Performance Analysis and Architecture ****** [ http://www.adamfields.com ] [ http://www.morningside-analytics.com ] .. Latest Venture [ http://www.confabb.com ] ................ Founder [ http://www.aquick.org/blog ] ............ Blog [ http://www.adamfields.com/resume.html ].. Experience [ http://www.flickr.com/photos/fields ] ... Photos [ http://www.aquicki.com/wiki ].............Wiki From johnl at iecc.com Fri Jun 6 14:43:01 2008 From: johnl at iecc.com (John Levine) Date: 6 Jun 2008 19:43:01 -0000 Subject: OT: www.Amazon.com down? In-Reply-To: <20080606191923.GF22025@lola.aquick.org> Message-ID: <20080606194301.15839.qmail@simone.iecc.com> >------------------------------------------------ >$ whois amazon.com > >Whois Server Version 2.0 > >Domain names in the .com and .net domains can now be registered >with many different competing registrars. Go to >http://www.internic.net >for detailed information. > >AMAZON.COM.ZZZZZ.GET.LAID.AT.WWW.SWINGINGCOMMUNITY.COM >AMAZON.COM.MORE.INFO.AT.WWW.BEYONDWHOIS.COM >AMAZON.COM.IS.N0T.AS.1337.AS.WWW.GULLI.COM >AMAZON.COM >------------------------------------------------ This result means that you urgently need to get a better WHOIS client. Yours is probably querying com.whois-servers.net which is an alias of whois.verisign-grs.com which, for some reason, by default returns the names of all the entities in their database that matches your search string. If you prefix the string with an = sign, it dumps the full entries, which you can see are three name servers with silly names and one perfectly normal registration for amazon.com. R's, John Server Name: AMAZON.COM.ZZZZZ.GET.LAID.AT.WWW.SWINGINGCOMMUNITY.COM IP Address: 69.41.185.219 Registrar: INNERWISE, INC. D/B/A ITSYOURDOMAIN.COM Whois Server: whois.itsyourdomain.com Referral URL: http://www.itsyourdomain.com Server Name: AMAZON.COM.MORE.INFO.AT.WWW.BEYONDWHOIS.COM IP Address: 203.36.226.2 Registrar: TUCOWS INC. Whois Server: whois.tucows.com Referral URL: http://domainhelp.opensrs.net Server Name: AMAZON.COM.IS.N0T.AS.1337.AS.WWW.GULLI.COM IP Address: 80.190.192.24 Registrar: EPAG DOMAINSERVICES GMBH Whois Server: whois.enterprice.net Referral URL: http://www.enterprice.net Domain Name: AMAZON.COM Registrar: NETWORK SOLUTIONS, LLC. Whois Server: whois.networksolutions.com Referral URL: http://www.networksolutions.com Name Server: UDNS1.ULTRADNS.NET Name Server: UDNS2.ULTRADNS.NET Status: clientDeleteProhibited Status: clientTransferProhibited Status: clientUpdateProhibited Updated Date: 28-mar-2008 Creation Date: 01-nov-1994 Expiration Date: 31-oct-2017 From swm at emanon.com Fri Jun 6 14:45:34 2008 From: swm at emanon.com (Scott Morris) Date: Fri, 6 Jun 2008 15:45:34 -0400 Subject: OT: www.Amazon.com down? In-Reply-To: <4849903B.302@davidcoulson.net> References: <20080606191923.GF22025@lola.aquick.org> <4849903B.302@davidcoulson.net> Message-ID: <007001c8c80d$e2f73140$800610ac@scott66ed7b03d> Hehehe... I think the whois program searches for any instance of what you type in. The TLD records appear intact and seem to reference the correct name servers. NSLookups to different hosts return properly. I suspect you're just getting caught up in the wonderful world of bad DNS servers! :) While entertaining, I don't think the world is ending quite yet. scott-morriss-macbook-pro:~ swmorris$ whois microsoft.com Whois Server Version 2.0 Domain names in the .com and .net domains can now be registered with many different competing registrars. Go to http://www.internic.net for detailed information. MICROSOFT.COM.ZZZZZZ.MORE.DETAILS.AT.WWW.BEYONDWHOIS.COM MICROSOFT.COM.ZZZZZ.GET.LAID.AT.WWW.SWINGINGCOMMUNITY.COM MICROSOFT.COM.ZZZOMBIED.AND.HACKED.BY.WWW.WEB-HACK.COM MICROSOFT.COM.ZZZ.IS.0WNED.AND.HAX0RED.BY.SUB7.NET MICROSOFT.COM.WILL.LIVE.FOREVER.BECOUSE.UNIXSUCKS.COM MICROSOFT.COM.WILL.BE.SLAPPED.IN.THE.FACE.BY.MY.BLUE.VEINED.SPANNER.NET MICROSOFT.COM.WILL.BE.BEATEN.WITH.MY.SPANNER.NET MICROSOFT.COM.WAREZ.AT.TOPLIST.GULLI.COM MICROSOFT.COM.USERS.SHOULD.HOST.WITH.UNIX.AT.ITSHOSTED.COM MICROSOFT.COM.TOTALLY.SUCKS.S3U.NET MICROSOFT.COM.SOFTWARE.IS.NOT.USED.AT.REG.RU MICROSOFT.COM.SHOULD.GIVE.UP.BECAUSE.LINUXISGOD.COM MICROSOFT.COM.RAWKZ.MUH.WERLD.MENTALFLOSS.CA MICROSOFT.COM.OHMYGODITBURNS.COM MICROSOFT.COM.MORE.INFO.AT.WWW.BEYONDWHOIS.COM MICROSOFT.COM.LOVES.ME.KOSMAL.NET MICROSOFT.COM.LIVES.AT.SHAUNEWING.COM MICROSOFT.COM.IS.NOT.YEPPA.ORG MICROSOFT.COM.IS.NOT.HOSTED.BY.ACTIVEDOMAINDNS.NET MICROSOFT.COM.IS.IN.BED.WITH.CURTYV.COM MICROSOFT.COM.IS.HOSTED.ON.PROFITHOSTING.NET MICROSOFT.COM.IS.GOD.BECOUSE.UNIXSUCKS.COM MICROSOFT.COM.IS.A.STEAMING.HEAP.OF.FUCKING-BULLSHIT.NET MICROSOFT.COM.IS.A.MESS.TIMPORTER.CO.UK MICROSOFT.COM.HAS.ITS.OWN.CRACKLAB.COM MICROSOFT.COM.HAS.A.PRESENT.COMING.FROM.HUGHESMISSILES.COM MICROSOFT.COM.FILLS.ME.WITH.BELLIGERENCE.NET MICROSOFT.COM.CAN.GO.FUCK.ITSELF.AT.SECZY.COM MICROSOFT.COM.ARE.GODDAMN.PIGFUCKERS.NET.NS-NOT-IN-SERVICE.COM MICROSOFT.COM.AND.MINDSUCK.BOTH.SUCK.HUGE.ONES.AT.EXEGETE.NET MICROSOFT.COM To single out one record, look it up with "xxx", where xxx is one of the of the records displayed above. If the records are the same, look them up with "=xxx" to receive a full display for each record. >>> Last update of whois database: Fri, 06 Jun 2008 15:42:43 EDT <<< -----Original Message----- From: David Coulson [mailto:david at davidcoulson.net] Sent: Friday, June 06, 2008 3:30 PM To: nanog at nanog.org Subject: Re: OT: www.Amazon.com down? > I expect this means that DNS has been compromised somewhere. > I see that whois is wonky, but DNS looks right. cr1:~# dig amazon.com @j.gtld-servers.net | grep NS ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 2 amazon.com. 172800 IN NS udns1.ultradns.net. amazon.com. 172800 IN NS udns2.ultradns.net. There is weird whois data for facebook.com, youtube.com, myspace.com and some others From marc at let.de Fri Jun 6 14:50:29 2008 From: marc at let.de (Marc Manthey) Date: Fri, 6 Jun 2008 21:50:29 +0200 Subject: OT: www.Amazon.com down? In-Reply-To: <4849903C.9050909@west.net> References: <20080606191923.GF22025@lola.aquick.org> <4849903C.9050909@west.net> Message-ID: <469FAE6D-12F6-4ECC-B436-4A2C2E9C5B21@let.de> >> This is rather suspicious (and confirmed by three other people): >> ------------------------------------------------ >> $ whois amazon.com >> AMAZON.COM.ZZZZZ.GET.LAID.AT.WWW.SWINGINGCOMMUNITY.COM >> AMAZON.COM.MORE.INFO.AT.WWW.BEYONDWHOIS.COM >> AMAZON.COM.IS.N0T.AS.1337.AS.WWW.GULLI.COM >> AMAZON.COM >> ------------------------------------------------ >> whois for yahoo.com and google.com yield similar results. good evening, someone posted something similar thrue a list a while ago , i think its because amazon was registred with "networksolutions" and so on its not visiblle in the normal "whois " querry ? >> I expect this means that DNS has been compromised somewhere. > > No compromise, just people getting cute by registering host records. > Microsoft.com is a mild example... > No, you should just learn to read WHOIS output :) you mean its about this ? > Domain names in the .com and .net domains can now be registered > with many different competing registrars. Go to http://www.internic.net > for detailed information. i get the same from terminal but when i try networksolutions whois on website i get Registrant: Amazon.com, Inc Legal Dept, P.O. Box 81226 Seattle, WA 98108-1226 US Administrative Contact , Technical Contact : Amazon.com, Inc. hostmaster at AMAZON.COM PO BOX 81226 SEATTLE, WA 98108-1300 US Phone: +1 206 266 4064 Fax: +1 206 266 7010 Record expires on 31-Oct-2017 Record created on 01-Nov-1994 Database last updated on 28-Mar-2008 just my 2 cents marc -- "Imagination is more important than Knowledge". Les enfants teribbles - research and deployment Marc Manthey - head of research and innovation Hildeboldplatz 1a D - 50672 K?ln - Germany Tel.:0049-221-3558032 Mobil:0049-1577-3329231 jabber :marc at kgraff.net blog : http://www.let.de ipv6 http://www.stattfernsehen.com xing : https://www.xing.com/profile/Marc_Manthey From jabley at ca.afilias.info Fri Jun 6 14:50:31 2008 From: jabley at ca.afilias.info (Joe Abley) Date: Fri, 6 Jun 2008 15:50:31 -0400 Subject: OT: www.Amazon.com down? In-Reply-To: References: Message-ID: <76A3E682-C9FB-4CB1-8250-D92FE3B38109@ca.afilias.info> On 6 Jun 2008, at 15:40, Darden, Patrick S. wrote: > I cannot reproduce this. I wouldn't worry. The "SOMEONE HACKED XXXX CHECK WHOIS OMG" meme reproduces on its own. Joe From nanog304985 at aquick.org Fri Jun 6 14:50:56 2008 From: nanog304985 at aquick.org (Adam Fields) Date: Fri, 6 Jun 2008 15:50:56 -0400 Subject: OT: www.Amazon.com down? In-Reply-To: <20080606192834.GA82098@catpipe.net> References: <20080606191923.GF22025@lola.aquick.org> <20080606192834.GA82098@catpipe.net> Message-ID: <20080606195055.GH22025@lola.aquick.org> On Fri, Jun 06, 2008 at 09:28:35PM +0200, Phil Regnauld wrote: [...] > > I expect this means that DNS has been compromised somewhere. > > No, you should just learn to read WHOIS output :) Indeed. Still, I feel better having asked and having it be nothing than the other way around. From Jon.Kibler at aset.com Fri Jun 6 14:43:38 2008 From: Jon.Kibler at aset.com (Jon Kibler) Date: Fri, 06 Jun 2008 15:43:38 -0400 Subject: www.Amazon.com down? In-Reply-To: <20080606191800.GG10911@cgi.jachomes.com> References: <780C8CBA-1E5E-44D5-8E5F-4DAA7703299E@bsdboy.com> <484989D4.8000609@connection2.com> <20080606191800.GG10911@cgi.jachomes.com> Message-ID: <4849936A.6020409@aset.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 My highly reliable grapevine is reporting: "just heard that it is due to a game release (Metal Gear , some kind of playstation bundle). I guess some bots try to order it." Jon - -- Jon R. Kibler Chief Technical Officer Advanced Systems Engineering Technology, Inc. Charleston, SC USA o: 843-849-8214 c: 843-224-2494 s: 843-564-4224 My PGP Fingerprint is: BAA2 1F2C 5543 5D25 4636 A392 515C 5045 CF39 4253 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkhJk2oACgkQUVxQRc85QlO/oACfYUS1X+gmxjR/w89vP4s+XBte 2b8An0M2FqS5j138Ij1JRH4HpZubRSSW =b+EC -----END PGP SIGNATURE----- ================================================== Filtered by: TRUSTEM.COM's Email Filtering Service http://www.trustem.com/ No Spam. No Viruses. Just Good Clean Email. From Jon.Kibler at aset.com Fri Jun 6 14:43:38 2008 From: Jon.Kibler at aset.com (Jon Kibler) Date: Fri, 06 Jun 2008 15:43:38 -0400 Subject: www.Amazon.com down? In-Reply-To: <20080606191800.GG10911@cgi.jachomes.com> References: <780C8CBA-1E5E-44D5-8E5F-4DAA7703299E@bsdboy.com> <484989D4.8000609@connection2.com> <20080606191800.GG10911@cgi.jachomes.com> Message-ID: <4849936A.6020409@aset.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 My highly reliable grapevine is reporting: "just heard that it is due to a game release (Metal Gear , some kind of playstation bundle). I guess some bots try to order it." Jon - -- Jon R. Kibler Chief Technical Officer Advanced Systems Engineering Technology, Inc. Charleston, SC USA o: 843-849-8214 c: 843-224-2494 s: 843-564-4224 My PGP Fingerprint is: BAA2 1F2C 5543 5D25 4636 A392 515C 5045 CF39 4253 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkhJk2oACgkQUVxQRc85QlO/oACfYUS1X+gmxjR/w89vP4s+XBte 2b8An0M2FqS5j138Ij1JRH4HpZubRSSW =b+EC -----END PGP SIGNATURE----- ================================================== Filtered by: TRUSTEM.COM's Email Filtering Service http://www.trustem.com/ No Spam. No Viruses. Just Good Clean Email. From eddy at fasteddy.org Fri Jun 6 15:16:22 2008 From: eddy at fasteddy.org (Eddy Martinez) Date: Fri, 6 Jun 2008 13:16:22 -0700 Subject: OT: www.Amazon.com down? In-Reply-To: <75cb24520806061133p3a3f9f8bk1b56e5d4f1bcd448@mail.gmail.com> References: <200806061229.21215.cstone@axint.net> <75cb24520806061133p3a3f9f8bk1b56e5d4f1bcd448@mail.gmail.com> Message-ID: On Jun 6, 2008, at 11:33 AM, Christopher Morrow wrote: > On Fri, Jun 6, 2008 at 2:29 PM, Chris Stone wrote: > > and to pile on... > > http://www.downforeveryoneorjustme.com/www.amazon.com > > down as of - 2008-06-06 14:33:38 - now. Anyone see the humor in the Google ads... Buy Books at Amazon.com Find Lower Price at Amazon. Free Shipping Featured Items. Eddy From pmessri at gmail.com Fri Jun 6 17:02:26 2008 From: pmessri at gmail.com (Pedram M) Date: Fri, 6 Jun 2008 15:02:26 -0700 Subject: OT: www.Amazon.com down? In-Reply-To: References: <200806061229.21215.cstone@axint.net> <75cb24520806061133p3a3f9f8bk1b56e5d4f1bcd448@mail.gmail.com> Message-ID: <9c9aa5d00806061502m46b97062h41c24551ac7a38c9@mail.gmail.com> Seems to have made some headlines. http://news.google.com/news?ned=us&hl=en&ned=us&q=amazon+down&btnG=Search+News On Fri, Jun 6, 2008 at 1:16 PM, Eddy Martinez wrote: > On Jun 6, 2008, at 11:33 AM, Christopher Morrow wrote: > >> On Fri, Jun 6, 2008 at 2:29 PM, Chris Stone wrote: > >> >> and to pile on... >> >> http://www.downforeveryoneorjustme.com/www.amazon.com >> >> down as of - 2008-06-06 14:33:38 - now. > > > Anyone see the humor in the Google ads... > > Buy Books at Amazon.com > Find Lower Price at Amazon. > Free Shipping Featured Items. > > > Eddy > > > From xploitable at gmail.com Fri Jun 6 17:16:48 2008 From: xploitable at gmail.com (n3td3v) Date: Fri, 6 Jun 2008 23:16:48 +0100 Subject: OT: www.Amazon.com down? In-Reply-To: <9c9aa5d00806061502m46b97062h41c24551ac7a38c9@mail.gmail.com> References: <200806061229.21215.cstone@axint.net> <75cb24520806061133p3a3f9f8bk1b56e5d4f1bcd448@mail.gmail.com> <9c9aa5d00806061502m46b97062h41c24551ac7a38c9@mail.gmail.com> Message-ID: <4b6ee9310806061516i165eef63uc6e2110f953bd842@mail.gmail.com> On Fri, Jun 6, 2008 at 11:02 PM, Pedram M wrote: > Seems to have made some headlines. > > http://news.google.com/news?ned=us&hl=en&ned=us&q=amazon+down&btnG=Search+News Maybe because its a major global website like Yahoo.com. Microsoft.com and CNN.com? All the best, n3td3v From trelane at trelane.net Fri Jun 6 21:31:27 2008 From: trelane at trelane.net (Andrew D Kirch) Date: Fri, 06 Jun 2008 22:31:27 -0400 Subject: OT: www.Amazon.com down? In-Reply-To: <4b6ee9310806061516i165eef63uc6e2110f953bd842@mail.gmail.com> References: <200806061229.21215.cstone@axint.net> <75cb24520806061133p3a3f9f8bk1b56e5d4f1bcd448@mail.gmail.com> <9c9aa5d00806061502m46b97062h41c24551ac7a38c9@mail.gmail.com> <4b6ee9310806061516i165eef63uc6e2110f953bd842@mail.gmail.com> Message-ID: <4849F2FF.2060409@trelane.net> n3td3v wrote: > On Fri, Jun 6, 2008 at 11:02 PM, Pedram M wrote: > >> Seems to have made some headlines. >> >> http://news.google.com/news?ned=us&hl=en&ned=us&q=amazon+down&btnG=Search+News >> > > Maybe because its a major global website like Yahoo.com. Microsoft.com > and CNN.com? > > All the best, > > n3td3v > > I'm not seeing IMDB in DNS. this is also an Amazon asset. # host www.imdb.com Host www.imdb.com not found: 2(SERVFAIL) # host www.google.com www.google.com is an alias for www.l.google.com.etc Andrew From fergdawg at netzero.net Fri Jun 6 21:53:05 2008 From: fergdawg at netzero.net (Paul Ferguson) Date: Sat, 7 Jun 2008 02:53:05 GMT Subject: OT: www.Amazon.com down? Message-ID: <20080606.195305.12147.0@webmail16.vgs.untd.com> ------BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - - Andrew D Kirch wrote: >I'm not seeing IMDB in DNS. this is also an Amazon asset. ># host www.imdb.com >Host www.imdb.com not found: 2(SERVFAIL) Are you looking in the right place? :-) %dig www.imdb.com ; <<>> DiG 9.3.2 <<>> www.imdb.com ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 924 ;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;www.imdb.com. IN A ;; ANSWER SECTION: www.imdb.com. 4400 IN CNAME us.imdb.com. us.imdb.com. 4 IN CNAME us.dd.imdb.com. us.dd.imdb.com. 16 IN A 72.21.206.70 ;; Query time: 2750 msec ;; SERVER: 68.87.76.178#53(68.87.76.178) ;; WHEN: Fri Jun 06 19:48:47 2008 ;; MSG SIZE rcvd: 83 - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.6.3 (Build 3017) wj8DBQFISffyq1pz9mNUZTMRAoTWAJ9ZmuFht/77ZFwdOzs1yAGL8pPzFQCgz04P I7wDtwgDNKmmnKlc3v+RWs8= =5dN8 -----END PGP SIGNATURE----- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(at)netzero.net ferg's tech blog: http://fergdawg.blogspot.com/ From trelane at trelane.net Fri Jun 6 22:00:26 2008 From: trelane at trelane.net (Andrew D Kirch) Date: Fri, 06 Jun 2008 23:00:26 -0400 Subject: OT: www.Amazon.com down? In-Reply-To: <20080606.195305.12147.0@webmail16.vgs.untd.com> References: <20080606.195305.12147.0@webmail16.vgs.untd.com> Message-ID: <4849F9CA.6050603@trelane.net> Paul Ferguson wrote: > ------BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > - - Andrew D Kirch wrote: > > >> I'm not seeing IMDB in DNS. this is also an Amazon asset. >> # host www.imdb.com >> Host www.imdb.com not found: 2(SERVFAIL) >> > > > Are you looking in the right place? :-) > > %dig www.imdb.com > > ; <<>> DiG 9.3.2 <<>> www.imdb.com > ;; global options: printcmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 924 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0 > > ;; QUESTION SECTION: > ;www.imdb.com. IN A > > ;; ANSWER SECTION: > www.imdb.com. 4400 IN CNAME us.imdb.com. > us.imdb.com. 4 IN CNAME us.dd.imdb.com. > us.dd.imdb.com. 16 IN A 72.21.206.70 > > ;; Query time: 2750 msec > ;; SERVER: 68.87.76.178#53(68.87.76.178) > ;; WHEN: Fri Jun 06 19:48:47 2008 > ;; MSG SIZE rcvd: 83 > > - - ferg > > -----BEGIN PGP SIGNATURE----- > Version: PGP Desktop 9.6.3 (Build 3017) > > wj8DBQFISffyq1pz9mNUZTMRAoTWAJ9ZmuFht/77ZFwdOzs1yAGL8pPzFQCgz04P > I7wDtwgDNKmmnKlc3v+RWs8= > =5dN8 > -----END PGP SIGNATURE----- > > > > -- > "Fergie", a.k.a. Paul Ferguson > Engineering Architecture for the Internet > fergdawg(at)netzero.net > ferg's tech blog: http://fergdawg.blogspot.com/ > > Odd, I'm seeing it now. Couldn't see it for 20-30 minutes. Andrew From williams.bruce at gmail.com Sat Jun 7 02:01:39 2008 From: williams.bruce at gmail.com (Bruce Williams) Date: Sat, 07 Jun 2008 00:01:39 -0700 Subject: senate.gov down Message-ID: <484A3253.9090404@gmail.com> * Looking for who is responsible for root zone and followed b.root-servers.net. * Looking for who is responsible for gov and followed g.gov.zoneedit.com. * Looking for who is responsible for senate.gov and followed sen-dmzp.senate.gov. Nameservers for www.senate.gov: * *sen-dmzp.senate.gov* returned (SERVFAIL) * *sen-dmzs.senate.gov* returned (SERVFAIL) Bruce Williams From jof at thejof.com Sat Jun 7 03:05:30 2008 From: jof at thejof.com (Jonathan Lassoff) Date: Sat, 7 Jun 2008 01:05:30 -0700 Subject: senate.gov down In-Reply-To: <484A3253.9090404@gmail.com> References: <484A3253.9090404@gmail.com> Message-ID: <20080607080530.GA28259@sfo.thejof.com> Querying from here (inside 69.59.128.0/18), I see sen-dmzp.senate.gov (156.33.195.40) and sen-dmzs.senate.gov (156.33.195.41) returning authoritatively for senate.gov: ---------- jonathan at sfo:~$ dig @156.33.195.40 senate.gov. in a ; <<>> DiG 9.3.4 <<>> @156.33.195.40 senate.gov. in a ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50611 ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2 ;; QUESTION SECTION: ;senate.gov. IN A ;; ANSWER SECTION: senate.gov. 10800 IN A 156.33.195.33 ---------- What if you query the nameservers directly by IP instead of by name? Cheers, jonathan On Sat, Jun 07, 2008 at 12:01:39AM -0700, Bruce Williams wrote: > * Looking for who is responsible for root zone and followed > b.root-servers.net. > * Looking for who is responsible for gov and followed > g.gov.zoneedit.com. > * Looking for who is responsible for senate.gov and followed > sen-dmzp.senate.gov. > > > Nameservers for www.senate.gov: > > * *sen-dmzp.senate.gov* returned (SERVFAIL) > * *sen-dmzs.senate.gov* returned (SERVFAIL) > > Bruce Williams > From kkibiego at jambo.co.ke Sat Jun 7 07:04:57 2008 From: kkibiego at jambo.co.ke (Kipkemoi Kibiego) Date: Sat, 07 Jun 2008 15:04:57 +0300 Subject: OT: www.Amazon.com down? In-Reply-To: <4849F2FF.2060409@trelane.net> References: <200806061229.21215.cstone@axint.net> <75cb24520806061133p3a3f9f8bk1b56e5d4f1bcd448@mail.gmail.com> <9c9aa5d00806061502m46b97062h41c24551ac7a38c9@mail.gmail.com> <4b6ee9310806061516i165eef63uc6e2110f953bd842@mail.gmail.com> <4849F2FF.2060409@trelane.net> Message-ID: <484A7969.4080704@jambo.co.ke> Seems to work now $ host [1]www.imdb.com [2]www.imdb.com is an alias for us.imdb.com. us.imdb.com is an alias for us.dd.imdb.com. us.dd.imdb.com has address 207.171.166.140 Andrew D Kirch wrote: n3td3v wrote: On Fri, Jun 6, 2008 at 11:02 PM, Pedram M [3] wrote: Seems to have made some headlines. [4]http://news.google.com/news?ned=us&hl=en&ned=us&q=amazon+down&btn G=Search+News Maybe because its a major global website like Yahoo.com. Microsoft.com and CNN.com? All the best, n3td3v I'm not seeing IMDB in DNS. this is also an Amazon asset. # host [5]www.imdb.com Host [6]www.imdb.com not found: 2(SERVFAIL) # host [7]www.google.com [8]www.google.com is an alias for [9]www.l.google.com.etc Andrew ---------------------------------------------- This message has been scanned for viruses and dangerous content by Jambo MailScanner, and is believed to be clean. --------------------------------------------- "easy access to the world" References 1. http://www.imdb.com/ 2. http://www.imdb.com/ 3. mailto:pmessri at gmail.com 4. http://news.google.com/news?ned=us&hl=en&ned=us&q=amazon+down&btnG=Search+News 5. http://www.imdb.com/ 6. http://www.imdb.com/ 7. http://www.google.com/ 8. http://www.google.com/ 9. http://www.l.google.com.etc/ From williams.bruce at gmail.com Sat Jun 7 09:47:11 2008 From: williams.bruce at gmail.com (Bruce Williams) Date: Sat, 07 Jun 2008 07:47:11 -0700 Subject: senate.gov down In-Reply-To: <20080607080530.GA28259@sfo.thejof.com> References: <484A3253.9090404@gmail.com> <20080607080530.GA28259@sfo.thejof.com> Message-ID: <484A9F6F.6040006@gmail.com> No problem by IP, it's an OpenDNS problem, seven hours and they still don't resolve it. Bruce Williams Jonathan Lassoff wrote: > Querying from here (inside 69.59.128.0/18), I see sen-dmzp.senate.gov (156.33.195.40) and sen-dmzs.senate.gov (156.33.195.41) returning authoritatively for senate.gov: > > ---------- > > jonathan at sfo:~$ dig @156.33.195.40 senate.gov. in a > > ; <<>> DiG 9.3.4 <<>> @156.33.195.40 senate.gov. in a > ; (1 server found) > ;; global options: printcmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50611 > ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2 > > ;; QUESTION SECTION: > ;senate.gov. IN A > > ;; ANSWER SECTION: > senate.gov. 10800 IN A 156.33.195.33 > > ---------- > > What if you query the nameservers directly by IP instead of by name? > > Cheers, > jonathan > > On Sat, Jun 07, 2008 at 12:01:39AM -0700, Bruce Williams wrote: > >> * Looking for who is responsible for root zone and followed >> b.root-servers.net. >> * Looking for who is responsible for gov and followed >> g.gov.zoneedit.com. >> * Looking for who is responsible for senate.gov and followed >> sen-dmzp.senate.gov. >> >> >> Nameservers for www.senate.gov: >> >> * *sen-dmzp.senate.gov* returned (SERVFAIL) >> * *sen-dmzs.senate.gov* returned (SERVFAIL) >> >> Bruce Williams >> >> > > From Ed.Lewis at neustar.biz Sat Jun 7 09:58:37 2008 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Sat, 7 Jun 2008 10:58:37 -0400 Subject: OT: www.Amazon.com down? In-Reply-To: <4849F9CA.6050603@trelane.net> References: <20080606.195305.12147.0@webmail16.vgs.untd.com> <4849F9CA.6050603@trelane.net> Message-ID: At 23:00 -0400 6/6/08, Andrew D Kirch wrote: >Paul Ferguson wrote: >> Are you looking in the right place? :-) >> >> %dig www.imdb.com >> >> ; <<>> DiG 9.3.2 <<>> www.imdb.com >> ;; global options: printcmd >> ;; Got answer: >> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 924 >> ;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0 >> >> ;; QUESTION SECTION: >> ;www.imdb.com. IN A >> >> ;; ANSWER SECTION: >> www.imdb.com. 4400 IN CNAME us.imdb.com. >> us.imdb.com. 4 IN CNAME us.dd.imdb.com. >> us.dd.imdb.com. 16 IN A 72.21.206.70 ... >Odd, I'm seeing it now. Couldn't see it for 20-30 minutes. > >Andrew I saw this problem late last night too. The problem was "downstream" in the CNAME chain. I was able to access IMDB by using us.dd.imdb.com (http://us.dd.imdb.com) while the www.imdb.com address was (in some sense of the word) "broken." My local recursor got a SERVFAIL for www.imdb.com and inserted a redirection page for it. Using dig +trace at the time I could work my way around the issue. I bet the recursor got most of the way there but couldn't get the A record or something. As it was very late for me, I didn't try to "debug" it. Just had a burning question about I movie I had just seen. ;) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Never confuse activity with progress. Activity pays more. From mhernand1 at comcast.net Sat Jun 7 15:40:24 2008 From: mhernand1 at comcast.net (manolo) Date: Sat, 07 Jun 2008 16:40:24 -0400 Subject: Comcast peering contacts Message-ID: <484AF238.7000507@comcast.net> All, I have misplaced the website that lists the contacts for bgp peering with a provider at a NAP. Does anyone have this link handy or have a email for requesting direct peering with comcast? Thanks, Manolo From ckoch at qualitytech.com Sat Jun 7 15:44:34 2008 From: ckoch at qualitytech.com (Koch, Christian) Date: Sat, 7 Jun 2008 16:44:34 -0400 Subject: Comcast peering contacts Message-ID: <5888FCB767AD5F41A65DC0DCFE91C921066F47D3@EDC-SUW-EXCH.edeltacom.biz> Manolo - peeringdb.com is the site you're looking for Sent via Blackberry Wireless Handheld -----Original Message----- From: manolo To: nanog at merit.edu Sent: Sat Jun 07 16:40:24 2008 Subject: Comcast peering contacts All, I have misplaced the website that lists the contacts for bgp peering with a provider at a NAP. Does anyone have this link handy or have a email for requesting direct peering with comcast? Thanks, Manolo QUALITY TECHNOLOGY SERVICES CONFIDENTIALITY NOTICE: This e-mail message including its attachments is classified COMPANY CONFIDENTIAL. It is intended for the person or entity to which it is addressed and may contain confidential material. Quality Technology Services controls the distribution of COMPANY CONFIDENTIAL assets, as such, any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact us at irt at qualitytech.com or 866-239-5000 and destroy all copies of the original message. Thank you. From ren.provo at gmail.com Sat Jun 7 15:45:31 2008 From: ren.provo at gmail.com (Ren Provo) Date: Sat, 7 Jun 2008 16:45:31 -0400 Subject: Comcast peering contacts In-Reply-To: <484AF238.7000507@comcast.net> References: <484AF238.7000507@comcast.net> Message-ID: <787581440806071345o44cec255g34b5c37cb8e49bed@mail.gmail.com> Hi Manolo, Peeringdb.com is the best place to cross-check what is available at a certain IX for public or private interconnection. http://as7922.peeringdb.com is what you are looking for WRT Comcast. http://www.comcast.com/peering details settlement-free interconnection guidelines. Cheers, -ren On Sat, Jun 7, 2008 at 4:40 PM, manolo wrote: > All, > > I have misplaced the website that lists the contacts for bgp peering with > a provider at a NAP. Does anyone have this link handy or have a email for > requesting direct peering with comcast? > > > > Thanks, > > > Manolo > > From hrlinneweh at sbcglobal.net Sun Jun 8 01:24:14 2008 From: hrlinneweh at sbcglobal.net (Henry Linneweh) Date: Sat, 7 Jun 2008 23:24:14 -0700 (PDT) Subject: senate.gov down Message-ID: <750251.22880.qm@web82906.mail.mud.yahoo.com> Works now ----- Original Message ---- From: Bruce Williams To: nanog at merit.edu Sent: Saturday, June 7, 2008 12:01:39 AM Subject: senate.gov down ? ? *? Looking for who is responsible for root zone and followed ? ? ? b.root-servers.net. ? ? * Looking for who is responsible for gov and followed ? ? ? g.gov.zoneedit.com. ? ? * Looking for who is responsible for senate.gov and followed ? ? ? sen-dmzp.senate.gov. ? ? ? ? Nameservers for www.senate.gov: ? ? * *sen-dmzp.senate.gov* returned (SERVFAIL) ? ? * *sen-dmzs.senate.gov* returned (SERVFAIL) Bruce Williams From rblayzor at inoc.net Mon Jun 9 07:35:16 2008 From: rblayzor at inoc.net (Robert Blayzor) Date: Mon, 9 Jun 2008 08:35:16 -0400 Subject: NYC - 60 Hudson Problems? Message-ID: <0C6BB8FF-E712-4FA5-8C16-1FCD5EEFE2D8@inoc.net> On this cheerful Monday morning around 3:40 EDT I'm seeing a few different service outages from Albany into NYC to 60 Hudson. Our Level3 internet connection has gone down (again) and still down as of this time, and also noticing some dark fiber facilities we have going into 60 Husdon also have LoS. Anyone know whats up? We have tickets in with Level3 another the other dark fiber provider, but it's been pretty quiet.. -- Robert Blayzor, BOFH INOC, LLC rblayzor at inoc.net http://www.inoc.net/~rblayzor/ From asawchuk at colospace.com Mon Jun 9 07:38:45 2008 From: asawchuk at colospace.com (Aaron Sawchuk) Date: Mon, 9 Jun 2008 08:38:45 -0400 Subject: NYC - 60 Hudson Problems? Message-ID: Is anyone aware if these L3 issues are affecting Burlington, Vermont again? Regards, Aaron ----- Original Message ----- From: Robert Blayzor To: nanog at merit.edu Sent: Mon Jun 09 08:35:16 2008 Subject: NYC - 60 Hudson Problems? On this cheerful Monday morning around 3:40 EDT I'm seeing a few different service outages from Albany into NYC to 60 Hudson. Our Level3 internet connection has gone down (again) and still down as of this time, and also noticing some dark fiber facilities we have going into 60 Husdon also have LoS. Anyone know whats up? We have tickets in with Level3 another the other dark fiber provider, but it's been pretty quiet.. -- Robert Blayzor, BOFH INOC, LLC rblayzor at inoc.net http://www.inoc.net/~rblayzor/ From rblayzor.bulk at inoc.net Mon Jun 9 07:39:15 2008 From: rblayzor.bulk at inoc.net (Robert Blayzor) Date: Mon, 9 Jun 2008 08:39:15 -0400 Subject: NYC - 60 Hudson Problems? Message-ID: <7A587C16-5D5E-4BC4-95E2-045721F3705A@inoc.net> On this cheerful Monday morning around 3:40 EDT I'm seeing a few different service outages from Albany into NYC to 60 Hudson. Our Level3 internet connection has gone down (again) and still down as of this time, and also noticing some dark fiber facilities we have going into 60 Husdon also have LoS. Anyone know whats up? We have tickets in with Level3 another the other dark fiber provider, but it's been pretty quiet.. -- Robert Blayzor, BOFH INOC, LLC rblayzor at inoc.net http://www.inoc.net/~rblayzor/ From rblayzor.bulk at inoc.net Mon Jun 9 07:50:06 2008 From: rblayzor.bulk at inoc.net (Robert Blayzor) Date: Mon, 9 Jun 2008 08:50:06 -0400 Subject: NYC - 60 Hudson Problems? In-Reply-To: References: Message-ID: <13F87392-3EAF-434A-8A85-E26B3EA08943@inoc.net> On Jun 9, 2008, at 8:38 AM, Aaron Sawchuk wrote: > Is anyone aware if these L3 issues are affecting Burlington, Vermont > again? Aaron I assume you're talking about the same issue back on May 18th - 20th. We were also effected during that time; however this time I'm seeing services effected on other carriers dark fiber paths, so perhaps it's something larger scale. -- Robert Blayzor, BOFH INOC, LLC rblayzor at inoc.net http://www.inoc.net/~rblayzor/ From sharp at sharpone.net Mon Jun 9 07:56:53 2008 From: sharp at sharpone.net (Justin Sharp) Date: Mon, 09 Jun 2008 06:56:53 -0600 Subject: Savvis outage Message-ID: <484D2895.2010607@sharpone.net> Anyone know what might be up w/ XO to Savvis peering? This is a trace to netsuite.com, notice 80% packet loss at bpr2 in Los Angeles Host Loss% Snt Last Avg Best Wrst StDev 1. 10.0.0.1 0.0% 21 0.3 0.4 0.3 1.6 0.3 2. ip65-44-114-97.z114-44-65.custom 0.0% 21 1.2 1.2 1.1 1.8 0.2 3. ip65-46-48-29.z48-46-65.customer 0.0% 20 2.8 3.1 2.7 5.6 0.6 4. p6-0-0d0.mar2.saltlake-ut.us.xo. 10.0% 20 3.0 7.0 3.0 68.5 15.4 5. p3-1-0d0.rar2.la-ca.us.xo.net 0.0% 20 90.2 31.3 16.8 114.1 32.1 6. p0-0-0d0.rar1.la-ca.us.xo.net 5.0% 20 17.9 18.8 17.7 26.2 2.6 7. te-4-1-0.rar3.la-ca.us.xo.net 0.0% 20 19.5 20.0 18.6 27.9 1.9 8. 207.88.12.154.ptr.us.xo.net 0.0% 20 16.9 17.4 16.8 22.4 1.3 9. bpr2-so-6-1-0.losangeles.savvis. 57.9% 20 85.9 85.9 84.9 90.4 1.8 10. cr1-gig-0-7-5-3.LosAngeles.savvi 78.9% 20 1040. 349.8 105.6 1040. 460.6 cr2-gig-0-7-5-3.losangeles.savvis.net 11. cr2-pos-0-0-5-0.sanfrancisco.sav 84.2% 20 133.0 406.4 94.7 991.5 507.1 cr1-loopback.sfo.savvis.net 12. er1-te-1-0-1.sanjose3equinix.sav 68.4% 20 94.2 94.8 94.2 95.7 0.5 er1-te-2-0-1.SanJose3Equinix.savvis.net 13. hr1-te-2-0-0.santaclarasc5.savvi 78.9% 20 94.3 95.2 94.3 95.8 0.7 14. hr1-te-2-0-0.santaclarasc8.savvi 70.0% 20 94.3 94.7 94.0 95.7 0.6 15. 66.35.192.2 75.0% 20 96.2 95.4 94.5 96.2 0.8 16. 167.216.129.12 78.9% 20 95.0 95.4 94.4 96.9 1.1 Thanks, --Justin From sharp at sharpone.net Mon Jun 9 12:29:40 2008 From: sharp at sharpone.net (Justin Sharp) Date: Mon, 09 Jun 2008 11:29:40 -0600 Subject: Savvis outage In-Reply-To: <484D2895.2010607@sharpone.net> References: <484D2895.2010607@sharpone.net> Message-ID: <484D6884.3080206@sharpone.net> Same old story.. Savvis points finger at XO, XO points finger at Savvis.. Neither side actually finds out and tells me who/what fixed the issue, but at least its fixed. --Justin Justin Sharp wrote: > Anyone know what might be up w/ XO to Savvis peering? > > This is a trace to netsuite.com, notice 80% packet loss at bpr2 in Los > Angeles > > Host Loss% Snt Last Avg Best > Wrst StDev > 1. 10.0.0.1 0.0% 21 0.3 0.4 0.3 1.6 0.3 > 2. ip65-44-114-97.z114-44-65.custom 0.0% 21 1.2 1.2 1.1 > 1.8 0.2 > 3. ip65-46-48-29.z48-46-65.customer 0.0% 20 2.8 3.1 2.7 > 5.6 0.6 > 4. p6-0-0d0.mar2.saltlake-ut.us.xo. 10.0% 20 3.0 7.0 3.0 > 68.5 15.4 > 5. p3-1-0d0.rar2.la-ca.us.xo.net 0.0% 20 90.2 31.3 16.8 > 114.1 32.1 > 6. p0-0-0d0.rar1.la-ca.us.xo.net 5.0% 20 17.9 18.8 17.7 > 26.2 2.6 > 7. te-4-1-0.rar3.la-ca.us.xo.net 0.0% 20 19.5 20.0 18.6 > 27.9 1.9 > 8. 207.88.12.154.ptr.us.xo.net 0.0% 20 16.9 17.4 16.8 > 22.4 1.3 > 9. bpr2-so-6-1-0.losangeles.savvis. 57.9% 20 85.9 85.9 84.9 > 90.4 1.8 > 10. cr1-gig-0-7-5-3.LosAngeles.savvi 78.9% 20 1040. 349.8 105.6 > 1040. 460.6 > cr2-gig-0-7-5-3.losangeles.savvis.net > 11. cr2-pos-0-0-5-0.sanfrancisco.sav 84.2% 20 133.0 406.4 94.7 > 991.5 507.1 > cr1-loopback.sfo.savvis.net > 12. er1-te-1-0-1.sanjose3equinix.sav 68.4% 20 94.2 94.8 94.2 > 95.7 0.5 > er1-te-2-0-1.SanJose3Equinix.savvis.net > 13. hr1-te-2-0-0.santaclarasc5.savvi 78.9% 20 94.3 95.2 94.3 > 95.8 0.7 > 14. hr1-te-2-0-0.santaclarasc8.savvi 70.0% 20 94.3 94.7 94.0 > 95.7 0.6 > 15. 66.35.192.2 75.0% 20 96.2 95.4 94.5 > 96.2 0.8 > 16. 167.216.129.12 78.9% 20 95.0 95.4 94.4 > 96.9 1.1 > > > Thanks, > --Justin > From pauldotwall at gmail.com Mon Jun 9 19:18:16 2008 From: pauldotwall at gmail.com (Paul Wall) Date: Mon, 9 Jun 2008 20:18:16 -0400 Subject: Comcast peering contacts In-Reply-To: <787581440806071345o44cec255g34b5c37cb8e49bed@mail.gmail.com> References: <484AF238.7000507@comcast.net> <787581440806071345o44cec255g34b5c37cb8e49bed@mail.gmail.com> Message-ID: <620fd17c0806091718i63a15e66yed8c4afa8ffb2856@mail.gmail.com> Manolo, As the peeringdb entry alludes to, a good contact might be Comcast sales: barry_tishgart at cable.comcast.com steven_lacoff at cable.comcast.com The Comcast peering policy is very restrictive, and only the largest access providers qualify. Additionally, they are not peering at any public fabrics at this time. Paul Wall From jra at baylink.com Tue Jun 10 09:53:08 2008 From: jra at baylink.com (Jay R. Ashworth) Date: Tue, 10 Jun 2008 10:53:08 -0400 Subject: So, what *really* happened to Amazon last Friday? Message-ID: <20080610145308.GA28582@cgi.jachomes.com> According to the New York Times, two analysts at Bank of America Equity Research think that their layer 3 pukes screwed up while preparing to rollout Unbox: http://mobile.nytimes.com/2008/06/09/is-a-new-digital-video-service-derailing-amazoncom/index.xml?partner=rssnyt&single=1&emc=rss Cheers, -- jra -- Jay R. Ashworth jra at baylink.com Designer +-Internetworking------+---------+ RFC 2100 Ashworth & Associates | Best Practices Wiki | | '87 e24 St Petersburg FL USA +-http://bestpractices.wikia.com-+ +1 727 647 1274 If you can read this... thank a system administrator. Or two. --me From psirt at cisco.com Tue Jun 10 12:25:00 2008 From: psirt at cisco.com (Cisco Systems Product Security Incident Response Team) Date: Tue, 10 Jun 2008 17:25:00 -0000 Subject: Cisco Security Advisory: SNMP Version 3 Authentication Vulnerabilities Message-ID: <20080610.snmp@psirt.cisco.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Cisco Security Advisory: SNMP Version 3 Authentication Vulnerabilities Document ID: 107408 Advisory ID: cisco-sa-20080610-snmpv3 http://www.cisco.com/warp/public/707/cisco-sa-20080610-snmpv3.shtml Revision 1.0 For Public Release 2008 June 10 1600 UTC (GMT) - --------------------------------------------------------------------- Summary ======= Multiple Cisco products contain either of two authentication vulnerabilities in the Simple Network Management Protocol version 3 (SNMPv3) feature. These vulnerabilities can be exploited when processing a malformed SNMPv3 message. These vulnerabilities could allow the disclosure of network information or may enable an attacker to perform configuration changes to vulnerable devices. The SNMP server is an optional service that is disabled by default in Cisco products. Only SNMPv3 is impacted by these vulnerabilities. Workarounds are available for mitigating the impact of the vulnerabilities described in this document. The United States Computer Emergency Response Team (US-CERT) has assigned Vulnerability Note VU#878044 to these vulnerabilities. Common Vulnerabilities and Exposures (CVE) identifier CVE-2008-0960 has also been assigned to these vulnerabilities. This advisory is posted at http://www.cisco.com/warp/public/707/cisco-sa-20080610-snmpv3.shtml Affected Products ================= Vulnerable Products +------------------ The following Cisco products are vulnerable. * Cisco IOS * Cisco IOS-XR * Cisco Catalyst Operating System (CatOS) * Cisco NX-OS * Cisco Application Control Engine (ACE) Module * Cisco ACE Appliance * Cisco ACE XML Gateway * Cisco MDS 9000 Series Multilayer Fabric Switches Note: The SNMP server is disabled by default. These vulnerabilities only impact devices that are configured for SNMPv3. To determine the version of SNMP configured in Cisco IOS, CatOS and IOS-XR, log in to the device and issue the show snmp group command. The security model field indicates the version of SNMP configured. The output "usm" is the abbreviation for user-based security model and this indicates SNMPv3 is configured. Cisco IOS router#show snmp group groupname: test security model:v3 noauth readview : v1default writeview: notifyview: row status: active Cisco CatOS 5500-1 (enable) show snmp group Security Model: v3 Security Name: userv3 Group Name: groupv3 Storage Type: nonvolatile Row Status: active Cisco IOS-XR RP/0/RP0/CPU0:ios#show snmp group groupname: test security model:usm readview : v1default writeview: - notifyview: v1default row status: nonVolatile IronPort +------- IronPort C-Series, X-Series, and M-Series appliances utilize code covered by this advisory, but are not susceptible to any security risk. IronPort C-Series, X-Series, and M-Series incorporate the libraries under the advisory to provide anonymous read-only access to system health data. There is no risk of escalated authorization privileges allowing a 3rd party to make any configuration changes to the IronPort devices. IronPort S-Series and Encryption Appliances are not affected by this advisory. This announcement has also been posted on the IronPort Support Portal, available to IronPort customers: https://supportportal.ironport.com/irppcnctr/srvcd?u=http://secure-support.soma.ironport.com/announcement&sid=900016 Products Confirmed Not Vulnerable +-------------------------------- The following Cisco products are confirmed not vulnerable: * Cisco PIX Security Appliances * Cisco ASA Security Appliances * Cisco Firewall Services Module (FWSM) * Cisco Security Monitoring, Analysis, and Response System (MARS) * Cisco Network Admission Control (NAC) Appliance * CiscoWorks Wireless LAN Solution Engine (WLSE) No other Cisco products are currently known to be affected by these vulnerabilities. Details ======= SNMP defines a standard mechanism for remote management and monitoring of devices in an Internet Protocol (IP) network. There are three general types of SNMP operations: "get" requests to request information, "set" requests that modify the configuration of a remote device, and "trap" messages that provide a monitoring function. SNMP requests and traps are transported over User Datagram Protocol (UDP) and are received at the assigned destination port numbers 161 and 162, respectively. SNMPv3 provides secure access to devices by authenticating and encrypting packets over the network. RFC2574 defines the use of HMAC-MD5-96 and HMAC-SHA-96 as the possible authentication protocols for SNMPv3. Vulnerabilities have been identified in the authentication code of multiple SNMPv3 implementations. This advisory identifies two vulnerabilities that are almost identical. Both are specifically related to malformed SNMPv3 packets that manipulate the Hash Message Authentication Code (HMAC). The two vulnerabilities may impact both Secure Hashing Algorithm-1 (SHA-1) and Message-Digest Algorithm 5 (MD5). The vulnerabilities described in this document can be successfully exploited using spoofed SNMPv3 packets. These vulnerabilities are documented in the following Cisco Bug IDs: * CSCsf04754 - IOS SNMPv3 HMAC Authentication issue * CSCsf30109 - IOS-XR SNMPv3 HMAC Authentication issue * CSCsf29976 - CatOS SNMPv3 HMAC Authentication issue * CSCsq62662 - ACE XML Gw SNMPv3 HMAC Authentication issue * CSCsq60664 - ACE Appliance SNMPv3 HMAC Authentication issue * CSCsq60695 - ACE Module SNMPv3 HMAC Authentication issue * CSCsq60582 - Nexus SNMPv3 HMAC Authentication issue Note: Although multiple software defects are listed, this advisory only identifies two vulnerabilities. Because different Cisco products require their own fixes, additional Bug IDs have been assigned. Vulnerability Scoring Details ============================= Cisco has provided scores for the vulnerabilities in this advisory based on the Common Vulnerability Scoring System (CVSS). The CVSS scoring in this Security Advisory is done in accordance with CVSS version 2.0. CVSS is a standards-based scoring method that conveys vulnerability severity and helps determine urgency and priority of response. Cisco has provided a base and temporal score. Customers can then compute environmental scores to assist in determining the impact of the vulnerability in individual networks. Cisco has provided an FAQ to answer additional questions regarding CVSS at http://www.cisco.com/web/about/security/intelligence/cvss-qandas.html Cisco has also provided a CVSS calculator to help compute the environmental impact for individual networks at http://intellishield.cisco.com/security/alertmanager/cvss CSCsf04754 - IOS SNMPv3 HMAC Authentication issue - ----------------------------------------------------- CVSS Base Score - 10 Access Vector - Network Access Complexity - Low Authentication - None Confidentiality Impact - Complete Integrity Impact - Complete Availability Impact - Complete CVSS Temporal Score - 8.3 Exploitability - Functional Remediation Level - Official-Fix Report Confidence - Confirmed CSCsf30109 - IOS-XR SNMPv3 HMAC Authentication issue - -------------------------------------------------------- CVSS Base Score - 10 Access Vector - Network Access Complexity - Low Authentication - None Confidentiality Impact - Complete Integrity Impact - Complete Availability Impact - Complete CVSS Temporal Score - 8.3 Exploitability - Functional Remediation Level - Official-Fix Report Confidence - Confirmed CSCsf29976 - CatOS SNMPv3 HMAC Authentication issue - ------------------------------------------------------- CVSS Base Score - 10 Access Vector - Network Access Complexity - Low Authentication - None Confidentiality Impact - Complete Integrity Impact - Complete Availability Impact - Complete CVSS Temporal Score - 8.3 Exploitability - Functional Remediation Level - Official-Fix Report Confidence - Confirmed CSCsq62662 - ACE XML Gw SNMPv3 HMAC Authentication issue - ------------------------------------------------------------ CVSS Base Score - 9.3 Access Vector - Network Access Complexity - Medium Authentication - None Confidentiality Impact - Complete Integrity Impact - Complete Availability Impact - Complete CVSS Temporal Score - 7.7 Exploitability - Functional Remediation Level - Official-Fix Report Confidence - Confirmed CSCsq60664 - ACE Appliance SNMPv3 HMAC Authentication issue - --------------------------------------------------------------- CVSS Base Score - 9.3 Access Vector - Network Access Complexity - Medium Authentication - None Confidentiality Impact - Complete Integrity Impact - Complete Availability Impact - Complete CVSS Temporal Score - 8.4 Exploitability - Functional Remediation Level - Workaround Report Confidence - Confirmed CSCsq60695 - ACE Module SNMPv3 HMAC Authentication issue - ------------------------------------------------------------ CVSS Base Score - 9.3 Access Vector - Network Access Complexity - Medium Authentication - None Confidentiality Impact - Complete Integrity Impact - Complete Availability Impact - Complete CVSS Temporal Score - 8.4 Exploitability - Functional Remediation Level - Workaround Report Confidence - Confirmed CSCsq60582 - Nexus SNMPv3 HMAC Authentication issue - ------------------------------------------------------- CVSS Base Score - 9.3 Access Vector - Network Access Complexity - Medium Authentication - None Confidentiality Impact - Complete Integrity Impact - Complete Availability Impact - Complete CVSS Temporal Score - 8.4 Exploitability - Functional Remediation Level - Workaround Report Confidence - Confirmed Impact ====== Successful exploitation of these vulnerabilities could result in the disclosure of sensitive information on a device or allow an attacker to make configuration changes to a vulnerable device that is based on the SNMP configuration. Software Versions and Fixes =========================== When considering software upgrades, also consult http://www.cisco.com/go/psirt and any subsequent advisories to determine exposure and a complete upgrade solution. In all cases, customers should exercise caution to be certain the devices to be upgraded contain sufficient memory and that current hardware and software configurations will continue to be supported properly by the new release. If the information is not clear, contact the Cisco Technical Assistance Center (TAC) or your contracted maintenance provider for assistance. Each row of the Cisco IOS software table (below) names a Cisco IOS release train. If a given release train is vulnerable, then the earliest possible releases that contain the fix (along with the anticipated date of availability for each, if applicable) are listed in the "First Fixed Release" column of the table. The "Recommended Release" column indicates the releases which have fixes for all the published vulnerabilities at the time of this Advisory. A device running a release in the given train that is earlier than the release in a specific column (less than the First Fixed Release) is known to be vulnerable. Cisco recommends upgrading to a release equal to or later than the release in the "Recommended Releases" column of the table. +----------------------------------------+ | Major | Availability of Repaired | | Release | Releases | |------------+---------------------------| | Affected | First Fixed | Recommended | | 12.0-Based | Release | Release | | Releases | | | |------------+-------------+-------------| | 12.0 | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.0DA | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.0DB | 12.0(2)DB | 12.4(18b) | |------------+-------------+-------------| | | Vulnerable; | | | 12.0DC | first fixed | 12.4(18b) | | | in 12.3T | | |------------+-------------+-------------| | | 12.0(28)S1 | | | | | | | 12.0S | 12.0(32)S5 | | | | | | | | 12.0(33)S | | |------------+-------------+-------------| | 12.0SC | 12.0(7)SC | | |------------+-------------+-------------| | | Vulnerable; | | | 12.0SL | first fixed | | | | in 12.0S | | |------------+-------------+-------------| | | Vulnerable; | | | 12.0SP | first fixed | | | | in 12.0S | | |------------+-------------+-------------| | | Vulnerable; | | | 12.0ST | first fixed | | | | in 12.0S | | |------------+-------------+-------------| | | Vulnerable; | | | 12.0SX | first fixed | | | | in 12.0S | | |------------+-------------+-------------| | 12.0SY | 12.0(32)SY1 | | |------------+-------------+-------------| | 12.0SZ | 12.0(30)SZ4 | | |------------+-------------+-------------| | 12.0T | 12.0(1)T | 12.4(18b) | |------------+-------------+-------------| | 12.0W | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.0WC | 12.0(5)WC16 | | |------------+-------------+-------------| | 12.0WT | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.0XA | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.0XB | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.0XC | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.0XD | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.0XE | 12.0(1)XE | | |------------+-------------+-------------| | 12.0XF | 12.0(2)XF1 | 12.0(2)XF | |------------+-------------+-------------| | | Vulnerable; | | | 12.0XG | first fixed | 12.4(18b) | | | in 12.2 | | |------------+-------------+-------------| | | Vulnerable; | | | 12.0XH | first fixed | 12.4(18b) | | | in 12.2 | | |------------+-------------+-------------| | | Releases | | | | prior to | | | | 12.0(4)XI2 | | | | are | | | | vulnerable, | | | 12.0XI | release | 12.4(18b) | | | 12.0(4)XI2 | | | | and later | | | | are not | | | | vulnerable; | | | | first fixed | | | | in 12.2 | | |------------+-------------+-------------| | | Vulnerable; | | | 12.0XJ | first fixed | 12.4(18b) | | | in 12.2 | | |------------+-------------+-------------| | | Vulnerable; | | | 12.0XK | first fixed | 12.4(18b) | | | in 12.2 | | |------------+-------------+-------------| | | Vulnerable; | | | 12.0XL | first fixed | 12.4(18b) | | | in 12.2 | | |------------+-------------+-------------| | | Vulnerable; | | | 12.0XM | first fixed | 12.4(18b) | | | in 12.0T | | |------------+-------------+-------------| | | Vulnerable; | | | 12.0XN | first fixed | 12.4(18b) | | | in 12.2 | | |------------+-------------+-------------| | | Vulnerable; | | | 12.0XQ | first fixed | 12.4(18b) | | | in 12.0T | | |------------+-------------+-------------| | | Vulnerable; | | | 12.0XR | first fixed | 12.4(18b) | | | in 12.2 | | |------------+-------------+-------------| | | Vulnerable; | | | 12.0XS | first fixed | | | | in 12.1E | | |------------+-------------+-------------| | | Vulnerable; | | | 12.0XV | first fixed | 12.4(18b) | | | in 12.0T | | |------------+-------------+-------------| | 12.0XW | Not | | | | Vulnerable | | |------------+-------------+-------------| | Affected | First Fixed | Recommended | | 12.1-Based | Release | Release | | Releases | | | |------------+-------------+-------------| | | Vulnerable; | | | 12.1 | first fixed | 12.4(18b) | | | in 12.2 | | |------------+-------------+-------------| | | Vulnerable; | | | 12.1AA | first fixed | 12.4(18b) | | | in 12.2 | | |------------+-------------+-------------| | | Vulnerable; | | | 12.1AX | first fixed | | | | in 12.2EY | | |------------+-------------+-------------| | | Vulnerable; | 12.1(22) | | 12.1AY | first fixed | EA11 | | | in 12.1EA | | |------------+-------------+-------------| | | Vulnerable; | 12.1(22) | | 12.1AZ | first fixed | EA11 | | | in 12.1EA | | |------------+-------------+-------------| | | Releases | | | | prior to | | | | 12.1(7)CX | | | | are | | | | vulnerable, | | | 12.1CX | release | 12.4(18b) | | | 12.1(7)CX | | | | and later | | | | are not | | | | vulnerable; | | | | first fixed | | | | in 12.2 | | |------------+-------------+-------------| | | Vulnerable; | | | 12.1DA | first fixed | | | | in 12.2DA | | |------------+-------------+-------------| | | Vulnerable; | | | 12.1DB | first fixed | 12.4(18b) | | | in 12.3T | | |------------+-------------+-------------| | | Vulnerable; | | | 12.1DC | first fixed | 12.4(18b) | | | in 12.3T | | |------------+-------------+-------------| | 12.1E | 12.1(1)E2 | | |------------+-------------+-------------| | 12.1EA | 12.1(22) | 12.1(22) | | | EA10 | EA11 | |------------+-------------+-------------| | 12.1EB | Vulnerable; | | | | contact TAC | | |------------+-------------+-------------| | | Vulnerable; | | | 12.1EC | first fixed | | | | in 12.3BC | | |------------+-------------+-------------| | | | 12.2(29) | | | | SVD1; | | 12.1EO | 12.1(19)EO6 | Available | | | | on | | | | 13-JUN-2008 | |------------+-------------+-------------| | | | 12.2(25) | | | | EWA14 | | | Vulnerable; | | | 12.1EU | first fixed | 12.2(31) | | | in 12.2SG | SGA7 | | | | | | | | 12.2(44)SG | |------------+-------------+-------------| | | | 12.2(29) | | | Vulnerable; | SVD1; | | 12.1EV | first fixed | Available | | | in 12.2SV | on | | | | 13-JUN-2008 | |------------+-------------+-------------| | | | 12.2(25) | | | | EWA14 | | | Vulnerable; | | | 12.1EW | first fixed | 12.2(31) | | | in 12.2EW | SGA7 | | | | | | | | 12.2(44)SG | |------------+-------------+-------------| | | Vulnerable; | | | 12.1EX | first fixed | | | | in 12.1E | | |------------+-------------+-------------| | | Vulnerable; | | | 12.1EY | first fixed | | | | in 12.1E | | |------------+-------------+-------------| | | Vulnerable; | | | 12.1EZ | first fixed | | | | in 12.1E | | |------------+-------------+-------------| | | Vulnerable; | | | 12.1GA | first fixed | 12.4(18b) | | | in 12.2 | | |------------+-------------+-------------| | | Vulnerable; | | | 12.1GB | first fixed | 12.4(18b) | | | in 12.2 | | |------------+-------------+-------------| | | Vulnerable; | | | 12.1T | first fixed | 12.4(18b) | | | in 12.2 | | |------------+-------------+-------------| | | Vulnerable; | | | 12.1XA | first fixed | 12.4(18b) | | | in 12.2 | | |------------+-------------+-------------| | | Vulnerable; | | | 12.1XB | first fixed | 12.4(18b) | | | in 12.2 | | |------------+-------------+-------------| | | Vulnerable; | | | 12.1XC | first fixed | 12.4(18b) | | | in 12.2 | | |------------+-------------+-------------| | | Vulnerable; | | | 12.1XD | first fixed | 12.4(18b) | | | in 12.2 | | |------------+-------------+-------------| | | Vulnerable; | | | 12.1XE | first fixed | | | | in 12.1E | | |------------+-------------+-------------| | | Vulnerable; | | | 12.1XF | first fixed | 12.4(18b) | | | in 12.3 | | |------------+-------------+-------------| | | Vulnerable; | | | 12.1XG | first fixed | 12.4(18b) | | | in 12.3 | | |------------+-------------+-------------| | | Vulnerable; | | | 12.1XH | first fixed | 12.4(18b) | | | in 12.2 | | |------------+-------------+-------------| | | Vulnerable; | | | 12.1XI | first fixed | 12.4(18b) | | | in 12.2 | | |------------+-------------+-------------| | | Vulnerable; | | | 12.1XJ | first fixed | 12.4(18b) | | | in 12.3 | | |------------+-------------+-------------| | 12.1XK | Not | | | | Vulnerable | | |------------+-------------+-------------| | | Vulnerable; | | | 12.1XL | first fixed | 12.4(18b) | | | in 12.3 | | |------------+-------------+-------------| | | Vulnerable; | | | 12.1XM | first fixed | 12.4(18b) | | | in 12.3 | | |------------+-------------+-------------| | 12.1XN | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.1XO | Not | | | | Vulnerable | | |------------+-------------+-------------| | | Vulnerable; | | | 12.1XP | first fixed | 12.4(18b) | | | in 12.3 | | |------------+-------------+-------------| | | Vulnerable; | | | 12.1XQ | first fixed | 12.4(18b) | | | in 12.3 | | |------------+-------------+-------------| | | Vulnerable; | | | 12.1XR | first fixed | 12.4(18b) | | | in 12.3 | | |------------+-------------+-------------| | | Vulnerable; | | | 12.1XS | first fixed | 12.4(18b) | | | in 12.2 | | |------------+-------------+-------------| | | Vulnerable; | | | 12.1XT | first fixed | 12.4(18b) | | | in 12.3 | | |------------+-------------+-------------| | | Vulnerable; | | | 12.1XU | first fixed | 12.4(18b) | | | in 12.3 | | |------------+-------------+-------------| | | Vulnerable; | | | 12.1XV | first fixed | 12.4(18b) | | | in 12.3 | | |------------+-------------+-------------| | | Vulnerable; | | | 12.1XW | first fixed | 12.4(18b) | | | in 12.2 | | |------------+-------------+-------------| | | Vulnerable; | | | 12.1XX | first fixed | 12.4(18b) | | | in 12.2 | | |------------+-------------+-------------| | | Vulnerable; | | | 12.1XY | first fixed | 12.4(18b) | | | in 12.2 | | |------------+-------------+-------------| | | Vulnerable; | | | 12.1XZ | first fixed | 12.4(18b) | | | in 12.2 | | |------------+-------------+-------------| | | Vulnerable; | | | 12.1YA | first fixed | 12.4(18b) | | | in 12.3 | | |------------+-------------+-------------| | | Vulnerable; | | | 12.1YB | first fixed | 12.4(18b) | | | in 12.3 | | |------------+-------------+-------------| | | Vulnerable; | | | 12.1YC | first fixed | 12.4(18b) | | | in 12.3 | | |------------+-------------+-------------| | | Vulnerable; | | | 12.1YD | first fixed | 12.4(18b) | | | in 12.3 | | |------------+-------------+-------------| | | Releases | | | | prior to | | | | 12.1(5)YE6 | | | | are | | | | vulnerable, | | | 12.1YE | release | 12.4(18b) | | | 12.1(5)YE6 | | | | and later | | | | are not | | | | vulnerable; | | | | first fixed | | | | in 12.3 | | |------------+-------------+-------------| | | Vulnerable; | | | 12.1YF | first fixed | 12.4(18b) | | | in 12.3 | | |------------+-------------+-------------| | 12.1YG | Not | | | | Vulnerable | | |------------+-------------+-------------| | | Vulnerable; | | | 12.1YH | first fixed | 12.4(18b) | | | in 12.3 | | |------------+-------------+-------------| | | Vulnerable; | | | 12.1YI | first fixed | 12.4(18b) | | | in 12.3 | | |------------+-------------+-------------| | | Vulnerable; | 12.1(22) | | 12.1YJ | first fixed | EA11 | | | in 12.1EA | | |------------+-------------+-------------| | Affected | First Fixed | Recommended | | 12.2-Based | Release | Release | | Releases | | | |------------+-------------+-------------| | | 12.2(26c) | | | | | | | | 12.2(27c) | | | | | | | 12.2 | 12.2(28d) | 12.4(18b) | | | | | | | 12.2(29b) | | | | | | | | 12.2(40) | | |------------+-------------+-------------| | | Vulnerable; | | | 12.2B | first fixed | 12.4(18b) | | | in 12.3T | | |------------+-------------+-------------| | | Vulnerable; | | | 12.2BC | first fixed | | | | in 12.3BC | | |------------+-------------+-------------| | | Vulnerable; | | | 12.2BW | first fixed | 12.4(18b) | | | in 12.3 | | |------------+-------------+-------------| | | Vulnerable; | | | 12.2BY | first fixed | 12.4(18b) | | | in 12.3T | | |------------+-------------+-------------| | | Vulnerable; | | | 12.2BZ | first fixed | | | | in 12.3XI | | |------------+-------------+-------------| | | Vulnerable; | | | 12.2CX | first fixed | | | | in 12.3BC | | |------------+-------------+-------------| | | Vulnerable; | | | 12.2CY | first fixed | | | | in 12.3BC | | |------------+-------------+-------------| | 12.2CZ | Not | | | | Vulnerable | | |------------+-------------+-------------| | | 12.2(10)DA4 | | | 12.2DA | | | | | 12.2(12) | | | | DA11 | | |------------+-------------+-------------| | | Vulnerable; | | | 12.2DD | first fixed | 12.4(18b) | | | in 12.3T | | |------------+-------------+-------------| | | Vulnerable; | | | 12.2DX | first fixed | 12.4(18b) | | | in 12.3T | | |------------+-------------+-------------| | | | 12.2(25) | | | | EWA14 | | | Vulnerable; | | | 12.2EU | first fixed | 12.2(31) | | | in 12.2SG | SGA7 | | | | | | | | 12.2(44)SG | |------------+-------------+-------------| | | | 12.2(25) | | | | EWA14 | | | 12.2(18)EW7 | | | 12.2EW | | 12.2(31) | | | 12.2(20)EW4 | SGA7 | | | | | | | | 12.2(44)SG | |------------+-------------+-------------| | | 12.2(20) | | | | EWA3 | | | | | | | | 12.2(25) | | | | EWA11 | 12.2(25) | | 12.2EWA | | EWA14 | | | 12.2(25) | | | | EWA7 | | | | | | | | 12.2(25) | | | | EWA8 | | |------------+-------------+-------------| | | | 12.2(44)EX; | | 12.2EX | 12.2(35)EX | Available | | | | on | | | | 26-JUN-2008 | |------------+-------------+-------------| | 12.2EY | 12.2(37)EY | | |------------+-------------+-------------| | | Vulnerable; | | | 12.2EZ | first fixed | | | | in 12.2SEE | | |------------+-------------+-------------| | | Vulnerable; | | | 12.2FX | first fixed | | | | in 12.2SEE | | |------------+-------------+-------------| | | Vulnerable; | | | 12.2FY | first fixed | | | | in 12.2SEG | | |------------+-------------+-------------| | | Vulnerable; | | | 12.2FZ | first fixed | 12.2(44)SE2 | | | in 12.2SE | | |------------+-------------+-------------| | | Vulnerable; | | | 12.2IXA | migrate to | | | | any release | | | | in 12.2IXD | | |------------+-------------+-------------| | 12.2IXB | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.2IXC | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.2IXD | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.2IXE | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.2IXF | Not | | | | Vulnerable | | |------------+-------------+-------------| | | Vulnerable; | | | 12.2JA | first fixed | | | | in 12.3JA | | |------------+-------------+-------------| | | Vulnerable; | | | 12.2JK | first fixed | 12.4(15)T5 | | | in 12.4T | | |------------+-------------+-------------| | | Vulnerable; | | | 12.2MB | first fixed | | | | in 12.2SW | | |------------+-------------+-------------| | 12.2MC | 12.2(15) | 12.4(18b) | | | MC2h | | |------------+-------------+-------------| | | 12.2(14)S18 | | | | | 12.2(31) | | | 12.2(18)S13 | SB12 | | 12.2S | | | | | 12.2(20)S13 | 12.2(33) | | | | SRC1 | | | 12.2(25)S11 | | |------------+-------------+-------------| | | 12.2(28)SB4 | | | | | | | 12.2SB | 12.2(31)SB2 | 12.2(31) | | | | SB12 | | | 12.2(31) | | | | SB3x | | |------------+-------------+-------------| | | Vulnerable; | 12.2(31) | | 12.2SBC | first fixed | SB12 | | | in 12.2SB | | |------------+-------------+-------------| | 12.2SCA | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.2SE | 12.2(35)SE | 12.2(44)SE2 | |------------+-------------+-------------| | | Vulnerable; | | | 12.2SEA | first fixed | | | | in 12.2SEE | | |------------+-------------+-------------| | | Vulnerable; | | | 12.2SEB | first fixed | | | | in 12.2SEE | | |------------+-------------+-------------| | | Vulnerable; | | | 12.2SEC | first fixed | | | | in 12.2SEE | | |------------+-------------+-------------| | | Vulnerable; | | | 12.2SED | first fixed | | | | in 12.2SEE | | |------------+-------------+-------------| | 12.2SEE | 12.2(25) | | | | SEE3 | | |------------+-------------+-------------| | 12.2SEF | 12.2(25) | 12.2(44)SE2 | | | SEF2 | | |------------+-------------+-------------| | 12.2SEG | 12.2(25) | | | | SEG2 | | |------------+-------------+-------------| | | 12.2(25)SG1 | | | | | | | | 12.2(31)SG1 | | | 12.2SG | | 12.2(44)SG | | | 12.2(31)SG2 | | | | | | | | 12.2(37)SG | | |------------+-------------+-------------| | 12.2SGA | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.2SL | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.2SM | 12.2(29)SM2 | 12.2(29)SM3 | |------------+-------------+-------------| | | | 12.2(29) | | | | SVD1; | | 12.2SO | 12.2(18)SO7 | Available | | | | on | | | | 13-JUN-2008 | |------------+-------------+-------------| | 12.2SRA | 12.2(33) | | | | SRA1 | | |------------+-------------+-------------| | 12.2SRB | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.2SRC | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.2SU | Not | | | | Vulnerable | | |------------+-------------+-------------| | | 12.2(27)SV5 | | | | | | | | 12.2(28)SV1 | 12.2(29) | | | | SVD1; | | 12.2SV | 12.2(29)SV3 | Available | | | | on | | | 12.2(29a) | 13-JUN-2008 | | | SV1 | | | | | | | | 12.2(29b)SV | | |------------+-------------+-------------| | 12.2SVA | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.2SVC | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.2SVD | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.2SW | 12.2(25)SW8 | | |------------+-------------+-------------| | | | 12.2(18) | | | Vulnerable; | SXF15; | | 12.2SX | first fixed | Available | | | in 12.2SXF | on | | | | 08-AUG-2008 | |------------+-------------+-------------| | | | 12.2(18) | | | Vulnerable; | SXF15; | | 12.2SXA | first fixed | Available | | | in 12.2SXF | on | | | | 08-AUG-2008 | |------------+-------------+-------------| | | | 12.2(18) | | | Vulnerable; | SXF15; | | 12.2SXB | first fixed | Available | | | in 12.2SXF | on | | | | 08-AUG-2008 | |------------+-------------+-------------| | | | 12.2(18) | | | 12.2(18) | SXF15; | | 12.2SXD | SXD7a | Available | | | | on | | | | 08-AUG-2008 | |------------+-------------+-------------| | | | 12.2(18) | | | 12.2(18) | SXF15; | | 12.2SXE | SXE6a | Available | | | | on | | | | 08-AUG-2008 | |------------+-------------+-------------| | | 12.2(18) | | | | SXF10a | 12.2(18) | | | | SXF15; | | 12.2SXF | 12.2(18) | Available | | | SXF12a | on | | | | 08-AUG-2008 | | | 12.2(18) | | | | SXF6 | | |------------+-------------+-------------| | 12.2SXH | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.2SY | Not | | | | Vulnerable | | |------------+-------------+-------------| | | | 12.2(31) | | | Vulnerable; | SB12 | | 12.2SZ | first fixed | | | | in 12.2S | 12.2(33) | | | | SRC1 | |------------+-------------+-------------| | | Vulnerable; | | | 12.2T | first fixed | 12.4(18b) | | | in 12.3 | | |------------+-------------+-------------| | 12.2TPC | 12.2(8) | | | | TPC10b | | |------------+-------------+-------------| | | Vulnerable; | 12.2(31) | | 12.2UZ | first fixed | SB12 | | | in 12.2SB | | |------------+-------------+-------------| | | Vulnerable; | | | 12.2XA | first fixed | 12.4(18b) | | | in 12.3 | | |------------+-------------+-------------| | | Vulnerable; | | | 12.2XB | first fixed | 12.4(18b) | | | in 12.3 | | |------------+-------------+-------------| | | Vulnerable; | | | 12.2XC | first fixed | 12.4(18b) | | | in 12.3T | | |------------+-------------+-------------| | | Vulnerable; | | | 12.2XD | first fixed | 12.4(18b) | | | in 12.3 | | |------------+-------------+-------------| | | Vulnerable; | | | 12.2XE | first fixed | 12.4(18b) | | | in 12.3 | | |------------+-------------+-------------| | | Vulnerable; | | | 12.2XF | first fixed | | | | in 12.3BC | | |------------+-------------+-------------| | | Vulnerable; | | | 12.2XG | first fixed | 12.4(18b) | | | in 12.3 | | |------------+-------------+-------------| | | Vulnerable; | | | 12.2XH | first fixed | 12.4(18b) | | | in 12.3 | | |------------+-------------+-------------| | | Vulnerable; | | | 12.2XI | first fixed | 12.4(18b) | | | in 12.3 | | |------------+-------------+-------------| | | Vulnerable; | | | 12.2XJ | first fixed | 12.4(18b) | | | in 12.3 | | |------------+-------------+-------------| | | Vulnerable; | | | 12.2XK | first fixed | 12.4(18b) | | | in 12.3 | | |------------+-------------+-------------| | | Vulnerable; | | | 12.2XL | first fixed | 12.4(18b) | | | in 12.3 | | |------------+-------------+-------------| | | Vulnerable; | | | 12.2XM | first fixed | 12.4(18b) | | | in 12.3 | | |------------+-------------+-------------| | 12.2XN | 12.2(33)XN1 | 12.4(18b) | |------------+-------------+-------------| | 12.2XNA | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.2XO | Not | | | | Vulnerable | | |------------+-------------+-------------| | | Vulnerable; | | | 12.2XQ | first fixed | 12.4(18b) | | | in 12.3 | | |------------+-------------+-------------| | | Vulnerable; | | | 12.2XR | first fixed | 12.4(18b) | | | in 12.3 | | |------------+-------------+-------------| | | Vulnerable; | | | 12.2XS | first fixed | 12.4(18b) | | | in 12.3 | | |------------+-------------+-------------| | | Vulnerable; | | | 12.2XT | first fixed | 12.4(18b) | | | in 12.3 | | |------------+-------------+-------------| | | Vulnerable; | | | 12.2XU | first fixed | 12.4(18b) | | | in 12.3 | | |------------+-------------+-------------| | | Vulnerable; | | | 12.2XV | first fixed | 12.4(18b) | | | in 12.3 | | |------------+-------------+-------------| | | Vulnerable; | | | 12.2XW | first fixed | 12.4(18b) | | | in 12.3 | | |------------+-------------+-------------| | 12.2YA | 12.2(4)YA12 | 12.4(18b) | |------------+-------------+-------------| | | Vulnerable; | | | 12.2YB | first fixed | 12.4(18b) | | | in 12.3 | | |------------+-------------+-------------| | | Vulnerable; | | | 12.2YC | first fixed | 12.4(18b) | | | in 12.3 | | |------------+-------------+-------------| | | Vulnerable; | | | 12.2YD | first fixed | 12.4(18b) | | | in 12.3T | | |------------+-------------+-------------| | 12.2YE | Not | | | | Vulnerable | | |------------+-------------+-------------| | | Vulnerable; | | | 12.2YF | first fixed | 12.4(18b) | | | in 12.3 | | |------------+-------------+-------------| | | Vulnerable; | | | 12.2YG | first fixed | 12.4(18b) | | | in 12.3 | | |------------+-------------+-------------| | | Vulnerable; | | | 12.2YH | first fixed | 12.4(18b) | | | in 12.3 | | |------------+-------------+-------------| | | Vulnerable; | | | 12.2YJ | first fixed | 12.4(18b) | | | in 12.3 | | |------------+-------------+-------------| | | Vulnerable; | | | 12.2YK | first fixed | 12.4(18b) | | | in 12.3T | | |------------+-------------+-------------| | | Vulnerable; | | | 12.2YL | first fixed | 12.4(18b) | | | in 12.3T | | |------------+-------------+-------------| | | Vulnerable; | | | 12.2YM | first fixed | 12.4(18b) | | | in 12.3T | | |------------+-------------+-------------| | | Vulnerable; | | | 12.2YN | first fixed | 12.4(18b) | | | in 12.3T | | |------------+-------------+-------------| | | Vulnerable; | 12.2(18) | | | migrate to | SXF15; | | 12.2YO | any release | Available | | | in 12.2SY | on | | | | 08-AUG-2008 | |------------+-------------+-------------| | | Vulnerable; | | | 12.2YP | first fixed | 12.4(18b) | | | in 12.3 | | |------------+-------------+-------------| | | Vulnerable; | | | 12.2YQ | first fixed | 12.4(18b) | | | in 12.3T | | |------------+-------------+-------------| | | Vulnerable; | | | 12.2YR | first fixed | 12.4(18b) | | | in 12.3T | | |------------+-------------+-------------| | | Vulnerable; | | | 12.2YS | first fixed | 12.4(18b) | | | in 12.3T | | |------------+-------------+-------------| | | Vulnerable; | | | 12.2YT | first fixed | 12.4(18b) | | | in 12.3 | | |------------+-------------+-------------| | | Vulnerable; | | | 12.2YU | first fixed | 12.4(18b) | | | in 12.3T | | |------------+-------------+-------------| | | Vulnerable; | | | 12.2YV | first fixed | 12.4(18b) | | | in 12.3T | | |------------+-------------+-------------| | | Vulnerable; | | | 12.2YW | first fixed | 12.4(18b) | | | in 12.3T | | |------------+-------------+-------------| | 12.2YX | Not | | | | Vulnerable | | |------------+-------------+-------------| | | Vulnerable; | | | 12.2YY | first fixed | 12.4(18b) | | | in 12.3T | | |------------+-------------+-------------| | | | 12.2(31) | | | Vulnerable; | SB12 | | 12.2YZ | first fixed | | | | in 12.2S | 12.2(33) | | | | SRC1 | |------------+-------------+-------------| | | | 12.2(18) | | | Vulnerable; | SXF15; | | 12.2ZA | first fixed | Available | | | in 12.2SXF | on | | | | 08-AUG-2008 | |------------+-------------+-------------| | | Vulnerable; | | | 12.2ZB | first fixed | 12.4(18b) | | | in 12.3T | | |------------+-------------+-------------| | | Vulnerable; | | | 12.2ZC | first fixed | 12.4(18b) | | | in 12.3T | | |------------+-------------+-------------| | 12.2ZD | Vulnerable; | | | | contact TAC | | |------------+-------------+-------------| | | Vulnerable; | | | 12.2ZE | first fixed | 12.4(18b) | | | in 12.3 | | |------------+-------------+-------------| | | Vulnerable; | | | 12.2ZF | first fixed | 12.4(18b) | | | in 12.3T | | |------------+-------------+-------------| | | | 12.3(2)XA7 | | | Vulnerable; | | | 12.2ZG | first fixed | 12.4(15)T5 | | | in 12.3YG | | | | | 12.4(18b) | |------------+-------------+-------------| | 12.2ZH | 12.2(13)ZH9 | 12.2(13) | | | | ZH11 | |------------+-------------+-------------| | | Vulnerable; | | | 12.2ZJ | first fixed | 12.4(18b) | | | in 12.3T | | |------------+-------------+-------------| | | Vulnerable; | 12.4(15)T5 | | 12.2ZL | first fixed | | | | in 12.3T | 12.4(18b) | |------------+-------------+-------------| | | Vulnerable; | | | 12.2ZP | first fixed | 12.4(18b) | | | in 12.3T | | |------------+-------------+-------------| | | | 12.2(33) | | | | SXH3; | | 12.2ZU | 12.2(18)ZU1 | Available | | | | on | | | | 03-JUL-2008 | |------------+-------------+-------------| | 12.2ZY | Not | | | | Vulnerable | | |------------+-------------+-------------| | Affected | First Fixed | Recommended | | 12.3-Based | Release | Release | | Releases | | | |------------+-------------+-------------| | | 12.3(17c) | | | | | | | | 12.3(18a) | | | | | | | 12.3 | 12.3(19a) | 12.4(18b) | | | | | | | 12.3(20a) | | | | | | | | 12.3(21) | | |------------+-------------+-------------| | | Vulnerable; | | | 12.3B | first fixed | 12.4(18b) | | | in 12.3T | | |------------+-------------+-------------| | | 12.3(17b) | | | 12.3BC | BC3 | | | | | | | | 12.3(21)BC | | |------------+-------------+-------------| | | Vulnerable; | | | 12.3BW | first fixed | 12.4(18b) | | | in 12.3T | | |------------+-------------+-------------| | 12.3EU | Not | | | | Vulnerable | | |------------+-------------+-------------| | | 12.3(11)JA | | | | | | | | 12.3(7)JA5 | | | 12.3JA | | | | | 12.3(8)JA3; | | | | Available | | | | on | | | | 18-SEP-2008 | | |------------+-------------+-------------| | 12.3JEA | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.3JEB | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.3JEC | Not | | | | Vulnerable | | |------------+-------------+-------------| | | | 12.3(2)JK4; | | | | Available | | | | on | | | 12.3(2)JK2 | 30-JUN-2008 | | 12.3JK | | | | | 12.3(8)JK1 | 12.3(8)JK2; | | | | Available | | | | on | | | | 30-JUN-2008 | |------------+-------------+-------------| | 12.3JL | 12.3(2)JL1 | 12.3(2)JL4 | |------------+-------------+-------------| | 12.3JX | Vulnerable; | 12.3(7)JX11 | | | contact TAC | | |------------+-------------+-------------| | 12.3T | 12.3(11)T11 | 12.4(18b) | |------------+-------------+-------------| | 12.3TPC | 12.3(4) | | | | TPC11b | | |------------+-------------+-------------| | 12.3VA | Vulnerable; | | | | contact TAC | | |------------+-------------+-------------| | 12.3XA | 12.3(2)XA6 | 12.3(2)XA7 | |------------+-------------+-------------| | | Vulnerable; | | | 12.3XB | first fixed | 12.4(18b) | | | in 12.3T | | |------------+-------------+-------------| | | | 12.4(15)T5 | | 12.3XC | 12.3(2)XC5 | | | | | 12.4(18b) | |------------+-------------+-------------| | | Vulnerable; | | | 12.3XD | first fixed | 12.4(18b) | | | in 12.3T | | |------------+-------------+-------------| | | | 12.4(15)T5 | | 12.3XE | 12.3(2)XE5 | | | | | 12.4(18b) | |------------+-------------+-------------| | | Vulnerable; | | | 12.3XF | first fixed | 12.4(18b) | | | in 12.3T | | |------------+-------------+-------------| | | Vulnerable; | 12.4(15)T5 | | 12.3XG | first fixed | | | | in 12.3YG | 12.4(18b) | |------------+-------------+-------------| | | Vulnerable; | | | 12.3XH | first fixed | 12.4(18b) | | | in 12.3T | | |------------+-------------+-------------| | 12.3XI | 12.3(7)XI8a | | |------------+-------------+-------------| | | Vulnerable; | 12.3(14) | | 12.3XJ | first fixed | YX11 | | | in 12.3YX | | | | | 12.4(15)T5 | |------------+-------------+-------------| | | Vulnerable; | | | 12.3XK | first fixed | 12.4(18b) | | | in 12.3T | | |------------+-------------+-------------| | | Vulnerable; | | | 12.3XQ | first fixed | 12.4(18b) | | | in 12.4 | | |------------+-------------+-------------| | | | 12.4(15)T5 | | 12.3XR | 12.3(7)XR7 | | | | | 12.4(18b) | |------------+-------------+-------------| | | Vulnerable; | | | 12.3XS | first fixed | 12.4(18b) | | | in 12.4 | | |------------+-------------+-------------| | | Vulnerable; | | | 12.3XU | first fixed | 12.4(15)T5 | | | in 12.4T | | |------------+-------------+-------------| | | Vulnerable; | 12.3(14) | | 12.3XW | first fixed | YX11 | | | in 12.3YX | | | | | 12.4(15)T5 | |------------+-------------+-------------| | | Vulnerable; | | | 12.3XY | first fixed | 12.4(18b) | | | in 12.3T | | |------------+-------------+-------------| | | Vulnerable; | 12.4(15)T5 | | 12.3YA | first fixed | | | | in 12.4 | 12.4(18b) | |------------+-------------+-------------| | | Vulnerable; | | | 12.3YD | first fixed | 12.4(15)T5 | | | in 12.4T | | |------------+-------------+-------------| | | Vulnerable; | 12.3(14) | | 12.3YF | first fixed | YX11 | | | in 12.3YX | | | | | 12.4(15)T5 | |------------+-------------+-------------| | 12.3YG | 12.3(8)YG6 | 12.4(15)T5 | |------------+-------------+-------------| | | Vulnerable; | | | 12.3YH | first fixed | 12.4(15)T5 | | | in 12.4T | | |------------+-------------+-------------| | | Vulnerable; | | | 12.3YI | first fixed | 12.4(15)T5 | | | in 12.4T | | |------------+-------------+-------------| | | Vulnerable; | | | 12.3YJ | first fixed | 12.4(15)T5 | | | in 12.4T | | |------------+-------------+-------------| | 12.3YK | 12.3(11)YK3 | 12.4(15)T5 | |------------+-------------+-------------| | 12.3YM | 12.3(14)YM8 | 12.3(14) | | | | YM12 | |------------+-------------+-------------| | | Vulnerable; | | | 12.3YQ | first fixed | 12.4(15)T5 | | | in 12.4T | | |------------+-------------+-------------| | 12.3YS | 12.3(11)YS2 | 12.4(15)T5 | |------------+-------------+-------------| | | Vulnerable; | | | 12.3YT | first fixed | 12.4(15)T5 | | | in 12.4T | | |------------+-------------+-------------| | | Vulnerable; | | | 12.3YU | first fixed | | | | in 12.4XB | | |------------+-------------+-------------| | 12.3YX | 12.3(14)YX4 | 12.3(14) | | | | YX11 | |------------+-------------+-------------| | 12.3YZ | 12.3(11)YZ2 | | |------------+-------------+-------------| | Affected | First Fixed | Recommended | | 12.4-Based | Release | Release | | Releases | | | |------------+-------------+-------------| | | 12.4(10) | | | | | | | | 12.4(3f) | | | | | | | 12.4 | 12.4(5c) | 12.4(18b) | | | | | | | 12.4(7c) | | | | | | | | 12.4(8b) | | |------------+-------------+-------------| | 12.4JA | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.4JK | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.4JMA | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.4JMB | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.4JMC | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.4JX | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.4MD | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.4MR | 12.4(9)MR | | |------------+-------------+-------------| | 12.4SW | Not | | | | Vulnerable | | |------------+-------------+-------------| | | 12.4(11)T | | | | | | | | 12.4(2)T6 | | | | | | | 12.4T | 12.4(4)T5 | 12.4(15)T5 | | | | | | | 12.4(6)T4 | | | | | | | | 12.4(9)T1 | | |------------+-------------+-------------| | | Vulnerable; | | | 12.4XA | first fixed | 12.4(15)T5 | | | in 12.4T | | |------------+-------------+-------------| | 12.4XB | 12.4(2)XB3 | | |------------+-------------+-------------| | 12.4XC | 12.4(4)XC5 | | |------------+-------------+-------------| | 12.4XD | 12.4(4)XD4 | 12.4(15)T5 | |------------+-------------+-------------| | 12.4XE | 12.4(6)XE2 | 12.4(15)T5 | |------------+-------------+-------------| | 12.4XF | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.4XG | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.4XJ | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.4XK | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.4XL | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.4XM | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.4XN | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.4XQ | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.4XT | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.4XV | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.4XW | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.4XY | Not | | | | Vulnerable | | |------------+-------------+-------------| | 12.4XZ | Not | | | | Vulnerable | | +----------------------------------------+ Cisco CatOS +---------- The following table lists fixed Cisco Catalyst Operating System (CatOS) software. +---------------------------------------+ | Affected | Affected | First | | Product | Release | Fixed | | | | Release | |-----------------+----------+----------| | | 6.x | 6.4(23) | | |----------+----------| | Cisco Catalyst | 7.x | 7.6(19) | |Operating |----------+----------| | System (CatOS) | 8.5.x | 8.5(7) | | |----------+----------| | | 8.6.x | 8.6(1) | +---------------------------------------+ Cisco IOS XR +----------- The following table lists fixed Cisco IOS XR software. +---------------------------------------------------+ | Cisco | | | | IOS XR | SMU ID | SMU Name | | Version | | | |---------+------------+----------------------------| | 3.2.2 | AA01681 | hfr-base-3.2.2.CSCsf30109 | |---------+------------+----------------------------| | 3.2.3 | AA01682 | hfr-base-3.2.3.CSCsf30109 | |---------+------------+----------------------------| | 3.2.4 | AA01683 | hfr-base-3.2.4.CSCsf30109 | |---------+------------+----------------------------| | 3.2.6 | AA01684 | hfr-base-3.2.6.CSCsf30109 | |---------+------------+----------------------------| | 3.3.0 | AA01685 | hfr-base-3.3.0.CSCsf30109 | |---------+------------+----------------------------| | 3.3.0 | AA01690 | c12k-base-3.3.0.CSCsf30109 | |---------+------------+----------------------------| | 3.3.1 | AA01686 | hfr-base-3.3.1.CSCsf30109 | |---------+------------+----------------------------| | 3.3.1 | AA01688 | c12k-base-3.3.1.CSCsf30109 | |---------+------------+----------------------------| | 3.3.2 | Not | Not vulnerable | | | vulnerable | | |---------+------------+----------------------------| | 3.4.x | Not | Not vulnerable | | | vulnerable | | +---------------------------------------------------+ Cisco NX-OS +---------- The following table lists fixed Cisco NX-OS software. +----------------------------------------+ | Affected | Affected | First Fixed | | Product | Release | Release | |-----------+-----------+----------------| | Cisco | | 4.0.(2) | | NX-OS | 4.0.(1)a | Available June | | | | 2008 | +----------------------------------------+ Cisco ACE Products +----------------- The following table lists fixed Cisco Application Control Engine (ACE) software. +---------------------------------------+ | Affected | Affected | First | | Product | Release | Fixed | | | | Release | |----------------+----------+-----------| | | 3.0(0)A1 | | | Cisco | (6.x) | | | Application | | A2(1.1) | | Control Engine | A2(1.0) | | | (ACE) Module | | | | | A2(1.0a) | | |----------------+----------+-----------| | | A1(7.0) | | | | | | | Cisco | A1(7.0a) | | | Application | | | | Control Engine | A1(7.0b) | A1(8.0a) | | (ACE) | | | | Appliance | A1(7.0c) | | | | | | | | A1(8.0) | | |----------------+----------+-----------| | Cisco | 4.x | | | Application | | 6.0.1 | | Control Engine | 5.x | Available | | (ACE) XML | | June 2008 | | Gateway | 6.0 | | +---------------------------------------+ Cisco MDS software +----------------- The following table lists fixed Cisco MDS Multilayer Switch software. +---------------------------------------+ | Affected | Affected | First Fixed | | Product | Release | Release | |-----------+-----------+---------------| | | 2.1 | | | Cisco MDS | | 3.4.1 | | 9000 | 3.0 | Available | | | | June 2008 | | | 3.2 | | +---------------------------------------+ Workarounds =========== The following workarounds have been identified for these vulnerabilities. Infrastructure Access Control Lists +---------------------------------- Although it is often difficult to block traffic that transits a network, it is possible to identify traffic that should never be allowed to target infrastructure devices and block that traffic at the border of networks. Infrastructure Access Control Lists (iACLs) are a network security best practice and should be considered as a long-term addition to good network security as well as a workaround for these specific vulnerabilities. The iACL example below should be included as part of the deployed infrastructure access-list which will protect all devices with IP addresses in the infrastructure IP address range: Note: UDP port 161 is applicable for all versions of SNMP. !--- Permit SNMP UDP 161 packets from !--- trusted hosts destined to infrastructure addresses. access-list 150 permit udp TRUSTED_HOSTS MASK INFRASTRUCTURE_ADDRESSES MASK eq 161 !--- Deny SNMP UDP 161 packets from all !--- other sources destined to infrastructure addresses. access-list 150 deny udp any INFRASTRUCTURE_ADDRESSES MASK eq 161 !--- Permit/deny all other Layer 3 and Layer 4 traffic in accordance !--- with existing security policies and configurations !--- Permit all other traffic to transit the device. access-list 150 permit ip any anyinterface serial 2/0ip access-group 150 in The white paper entitled "Protecting Your Core: Infrastructure Protection Access Control Lists" presents guidelines and recommended deployment techniques for infrastructure protection access lists. This white paper can be obtained at the following link: http://www.cisco.com/en/US/tech/tk648/tk361/technologies_white_paper09186a00801a1a55.shtml Control Plane Policing +--------------------- Control Plane Policing (CoPP) can be used to block untrusted SNMP access to the device. Cisco IOS software releases 12.0S, 12.2SX, 12.2S, 12.3T, 12.4, and 12.4T support the CoPP feature. CoPP can be configured on a device to protect the management and control planes and minimize the risk and effectiveness of direct infrastructure attacks by explicitly permitting only authorized traffic that is sent to infrastructure devices in accordance with existing security policies and configurations. The following example, which uses 192.168.100.1 to represent a trusted host, can be adapted to your network. !--- Deny SNMP UDP traffic from trusted hosts to all IP addresses !--- configured on all interfaces of the affected device so that !--- it will be allowed by the CoPP feature access-list 111 deny udp host 192.168.100.1 any eq 161 !--- Permit all other SNMP UDP traffic sent to all IP addresses !--- configured on all interfaces of the affected device so that it !--- will be policed and dropped by the CoPP feature access-list 111 permit udp any any eq 161 !--- Permit (Police or Drop)/Deny (Allow) all other Layer3 and Layer4 !--- traffic in accordance with existing security policies and !--- configurations for traffic that is authorized to be sent !--- to infrastructure devices !--- Create a Class-Map for traffic to be policed by !--- the CoPP feature class-map match-all drop-snmpv3-class match access-group 111 !--- Create a Policy-Map that will be applied to the !--- Control-Plane of the device. policy-map drop-snmpv3-traffic class drop-snmpv3-class drop !--- Apply the Policy-Map to the !--- Control-Plane of the device control-plane service-policy input drop-snmpv3-traffic In the above CoPP example, the access control list entries (ACEs) that match the potential exploit packets with the "permit" action result in these packets being discarded by the policy-map "drop" function, while packets that match the "deny" action (not shown) are not affected by the policy-map drop function. Please note that the policy-map syntax is different in the 12.2S and 12.0S Cisco IOS trains: policy-map drop-snmpv3-traffic class drop-snmpv3-class police 32000 1500 1500 conform-action drop exceed-action drop Additional information on the configuration and use of the CoPP feature is available at the following links: http://www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6586/ps6642/prod_white_paper0900aecd804fa16a.html and http://www.cisco.com/en/US/docs/ios/12_3t/12_3t4/feature/guide/gtrtlimt.html Transit Access Control Lists +--------------------------- Filters that deny SNMP packets using UDP port 161 should be deployed throughout the network as part of a Transit Access Control List (tACL) policy for protection of traffic that enters the network at ingress access points. This policy should be configured to protect the network device where the filter is applied and other devices behind it. Filters for SNMP packets that use UDP port 161 should also be deployed in front of vulnerable network devices so that traffic is only allowed from trusted clients. Additional information about tACLs is available in "Transit Access Control Lists: Filtering at Your Edge:" http://www.cisco.com/en/US/tech/tk648/tk361/technologies_white_paper09186a00801afc76.shtml Hardening Guide Statement +------------------------ Customers are advised to review the "Fortifying the Simple Network Management Protocol" section of the "Cisco Guide to Harden Cisco IOS Devices" for information on configuring an IOS device for SNMPv3 authentication and privacy: http://www.cisco.com/en/US/tech/tk648/tk361/technologies_tech_note09186a0080120f48.shtml#fortify Cisco IOS authPriv Configuration +------------------------------- Enabling the SNMPv3 privacy subsystem (if it is not already in use) is a short-term workaround for users who are unable to upgrade in a timely fashion. This subsystem is used to encrypt SNMPv3 traffic using a shared secret. In Cisco IOS, administrators can enable this workaround by using the authPriv SNMPv3 feature. Only Cisco IOS crypto images can run the authPriv feature. Note: Ensure that the management application supports SNMPv3 authPriv before implementing this feature. Applied Mitigation Bulletin +-------------------------- Additional mitigation techniques that can be deployed on Cisco devices within the network are available in the Cisco Applied Intelligence companion document for this advisory: http://www.cisco.com/warp/public/707/cisco-amb-20080610-SNMPv3.shtml Obtaining Fixed Software ======================== Cisco has released free software updates that address these vulnerabilities. Prior to deploying software, customers should consult their maintenance provider or check the software for feature set compatibility and known issues specific to their environment. Customers may only install and expect support for the feature sets they have purchased. By installing, downloading, accessing or otherwise using such software upgrades, customers agree to be bound by the terms of Cisco's software license terms found at http://www.cisco.com/en/US/products/prod_warranties_item09186a008088e31f.html or as otherwise set forth at Cisco.com Downloads at http://www.cisco.com/public/sw-center/sw-usingswc.shtml. Do not contact psirt at cisco.com or security-alert at cisco.com for software upgrades. Customers with Service Contracts +------------------------------- Customers with contracts should obtain upgraded software through their regular update channels. For most customers, this means that upgrades should be obtained through the Software Center on Cisco's worldwide website at http://www.cisco.com. Customers using Third Party Support Organizations +------------------------------------------------ Customers whose Cisco products are provided or maintained through prior or existing agreements with third-party support organizations, such as Cisco Partners, authorized resellers, or service providers should contact that support organization for guidance and assistance with the appropriate course of action in regards to this advisory. The effectiveness of any workaround or fix is dependent on specific customer situations, such as product mix, network topology, traffic behavior, and organizational mission. Due to the variety of affected products and releases, customers should consult with their service provider or support organization to ensure any applied workaround or fix is the most appropriate for use in the intended network before it is deployed. Customers without Service Contracts +---------------------------------- Customers who purchase direct from Cisco but do not hold a Cisco service contract, and customers who purchase through third-party vendors but are unsuccessful in obtaining fixed software through their point of sale should acquire upgrades by contacting the Cisco Technical Assistance Center (TAC). TAC contacts are as follows. * +1 800 553 2447 (toll free from within North America) * +1 408 526 7209 (toll call from anywhere in the world) * e-mail: tac at cisco.com Customers should have their product serial number available and be prepared to give the URL of this notice as evidence of entitlement to a free upgrade. Free upgrades for non-contract customers must be requested through the TAC. Refer to http://www.cisco.com/warp/public/687/Directory/DirTAC.shtml for additional TAC contact information, including localized telephone numbers, and instructions and e-mail addresses for use in various languages. Exploitation and Public Announcements ===================================== Cisco is releasing this combined Cisco IOS and non-IOS product advisory out of our normal bi-yearly IOS security advisory cycle due to public disclosure of these vulnerabilities. Cisco is not aware of any malicious exploitation of these vulnerabilities. These vulnerabilities were reported to Cisco by Dr. Tom Dunigan of the University of Tennessee and Net-SNMP in cooperation with the CERT Coordination Center. Status of this Notice: FINAL ============================ THIS DOCUMENT IS PROVIDED ON AN "AS IS" BASIS AND DOES NOT IMPLY ANY KIND OF GUARANTEE OR WARRANTY, INCLUDING THE WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR USE. YOUR USE OF THE INFORMATION ON THE DOCUMENT OR MATERIALS LINKED FROM THE DOCUMENT IS AT YOUR OWN RISK. CISCO RESERVES THE RIGHT TO CHANGE OR UPDATE THIS DOCUMENT AT ANY TIME. A stand-alone copy or Paraphrase of the text of this document that omits the distribution URL in the following section is an uncontrolled copy, and may lack important information or contain factual errors. Distribution ============ This advisory is posted on Cisco's worldwide website at : http://www.cisco.com/warp/public/707/cisco-sa-20080610-snmpv3.shtml In addition to worldwide web posting, a text version of this notice is clear-signed with the Cisco PSIRT PGP key and is posted to the following e-mail and Usenet news recipients. * cust-security-announce at cisco.com * first-teams at first.org * bugtraq at securityfocus.com * vulnwatch at vulnwatch.org * cisco at spot.colorado.edu * cisco-nsp at puck.nether.net * full-disclosure at lists.grok.org.uk * comp.dcom.sys.cisco at newsgate.cisco.com Future updates of this advisory, if any, will be placed on Cisco's worldwide website, but may or may not be actively announced on mailing lists or newsgroups. Users concerned about this problem are encouraged to check the above URL for any updates. Revision History ================ +---------------------------------------+ | Revision | | Initial | | 1.0 | 2008-June-10 | public | | | | release | +---------------------------------------+ Cisco Security Procedures ========================= Complete information on reporting security vulnerabilities in Cisco products, obtaining assistance with security incidents, and registering to receive security information from Cisco, is available on Cisco's worldwide website at http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html. This includes instructions for press inquiries regarding Cisco security notices. All Cisco security advisories are available at http://www.cisco.com/go/psirt. - --------------------------------------------------------------------- Updated: Jun 10, 2008 Document ID: 107408 - --------------------------------------------------------------------- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD8DBQFITruJ86n/Gc8U/uARAiuNAJwIq42/p8CUh7Dc88nAn9a1pfhhqgCfWXjv 8bYhCD0EKNQ28koObq4S+vQ= =zOBL -----END PGP SIGNATURE----- From justin at justinshore.com Tue Jun 10 14:59:23 2008 From: justin at justinshore.com (Justin Shore) Date: Tue, 10 Jun 2008 14:59:23 -0500 Subject: NANOG 43 presentation video content? Message-ID: <484EDD1B.2060409@justinshore.com> Is there an ETA for the recordings of the presentations to be posted to the website? It's possible that I'm just missing them though I've found the presentation docs. No rush, but I'm itching to see what I missed. Thanks Justin From james at iroute.org Tue Jun 10 17:37:47 2008 From: james at iroute.org (James Spenceley) Date: Wed, 11 Jun 2008 08:37:47 +1000 Subject: Call for Presentations - AusNOG-02 Message-ID: Call for Presentations - AusNOG-02 --------------------------------- AusNOG-02 is to be held in Sydney, Australia between 21st and 22nd of August 2008 The AusNOG meeting provides the Australian community with a forum to exchange information and experiences on a number of issues relating to the operation and support of networks, with a specific focus on the coming 6-12 months. The conference is expected to have a strong technical representation companies operating networks in Australia. Soon information will be posted at http://www.ausnog.net with further details, we will post back out to this list once that is done. Submissions ------------ Please read the below carefully. Send you proposed topics and details to organisers at ausnog.net. Be sure to specify which part of the conference best suits your proposal (Topic Sessions, Panel Discussions, Keynote Address or Peering Forum), include a detailed overview including the expected length of your presentation. The program committee will confirm your application and may get back to you with questions. Please remember this is a technical event for network operators and presentations should be representative of this. If you feel that you have a relevant presentation please also send that through, while we are attempting to get a certain theme running those who attended last would recall the diversity of presentations we received. Important Dates --------------- - 6 June 2008 - Call for Presentations Opens - 4 July 2008 - Deadline for Proposals - 11 July 2008 - Response to presentation proposals - 18 July 2008 - Draft program published to website - 25 July 2008 - Final program published Presentations are Required for the Following: --------------------------------------------- Topic Sessions - Required Speakers: Variable - Number of Topics: 4 The conference will consist of 4 Topics Sessions, each running for approximately 90 minutes. There are no fixed requirements on length of presentation, speakers will have the opportunity to present a longer formal presentation or a smaller lightening talk. This is your chance to share your experiences with the industry. The Topics Sessions selected for AusNOG-02 are. 1. Moving to higher speed. With the coming of many new submarine cable systems in the next 12 to 18 months there will soon be a glut of cheaper high quality bandwidth. This will bring its own issues in dealing with the larger traffic flows in the core and at the access edge. We need talks from people involved with routing high capacity flows, how this occurs, lessons that were learnt, things to avoid etc. 2. Scaling services to meet demand. Broadband penetrations is reaching its growth peak, while new user numbers will not be as high in the past improved data plans and open ADSL2+ ports mean that users can do more - how can services (mail, web, caching (?), NNTP etc) be scaled to meet this rising demand. We are seeking talks from people experienced in deploying services for growing user bases and how they have dealt with many of these issues. 3. Back to a virtual world. Many operators currently use the outsourced Layer 2 ports of other providers be it either dial or DSL. With FTTN a lot more may be forced to, this will also open the door back up to the 'ISP in box' operations where ISPs head back to being infrastructure light. We are seeking talks from people of the issues in deploying mass LNS - good ways to do it, does open source work, etc ? 4. Regulatory, Market Data and Overseas Trends (Regulatory and Industry Bodies Updates, Market Data and Statistics, Trends from Overseas Markets) Panel Discussions ----------------- - Required Panellists: 8-10 - Panel Length: 45 mins - Number of Panels: 2 Panels are the interactive part of the conference. The job of Panellists will be to stimulate and moderate the discussion. Whether you are on the panel or in the audience your input would be appreciated. The two Panel Topics will be related to the industry at the time of the conference. Propose a topics that you think will be interesting, or if you think you are interesting, propose yourself for inclusion to the panel :-) Keynote Addresses ----------------- - Required Speakers: 2 - Presentation Length: 45 mins - Number of Topics: 2 We are seeking 2 speakers for Keynotes Addresses. Each Keynote will be of 45 mins in length, including time for input from the industry. If you would like to be considered for a Keynote topic, please email ausnog-meeting at ausnog.net with details of yourself and your topic. Peering Forum ------------- We would like to meld the peering sessions into the main conference this year as we believe that it fits well with the general higher speed mature of the requests above, as such there will be no separate peering forum at AusNOG-02. We still welcome speakers from the peering industry to put together a relevant topic for the audience. The Organisers. _______________________________________________ AusNOG mailing list AusNOG at ausnog.net http://www.ausnog.net/mailman/listinfo/ausnog From rblayzor.bulk at inoc.net Tue Jun 10 19:28:04 2008 From: rblayzor.bulk at inoc.net (Robert Blayzor) Date: Tue, 10 Jun 2008 20:28:04 -0400 Subject: Why word on fiber outages in NY? Message-ID: <54B33501-388E-4283-A5E2-5C7A0A87908B@inoc.net> Anyone have the exact news or information of whats going on in NYC with a rather large fiber cut? I keep hearing that there was some large Con-Ed electrical vault that caught fire and burned up a ton of CavTel and Level3 fiber. I believe this happened sometime Sunday morning around 3:40 EDT. At that time I saw some CavTel dark fiber go away and Level3 DIA circuits just drop off... Level3 has been less than useful on giving updates rather than saying "extensive fiber damage in the NY metro area, no ETA". I've heard that the damage is so extensive it will be several days before anyone is allowed in to work on the fiber. I've been trying to search news and information, but nothing. I've heard this is huge outage for Level3 in the New York/Northeast area. Anyone have anything to share? -- Robert Blayzor, BOFH INOC, LLC rblayzor at inoc.net http://www.inoc.net/~rblayzor/ From surfer at mauigateway.com Tue Jun 10 19:49:08 2008 From: surfer at mauigateway.com (Scott Weeks) Date: Tue, 10 Jun 2008 17:49:08 -0700 Subject: Why word on fiber outages in NY? Message-ID: <20080610174908.35B73F5F@resin13.mta.everyone.net> You might try over on the outages mailing list: http://isotf.org/mailman/listinfo/outages scott --- rblayzor.bulk at inoc.net wrote: Anyone have the exact news or information of whats going on in NYC with a rather large fiber cut? I keep hearing that there was some large Con-Ed electrical vault that caught fire and burned up a ton of CavTel and Level3 fiber. I believe this happened sometime Sunday morning around 3:40 EDT. At that time I saw some CavTel dark fiber go away and Level3 DIA circuits just drop off... Level3 has been less than useful on giving updates rather than saying "extensive fiber damage in the NY metro area, no ETA". I've heard that the damage is so extensive it will be several days before anyone is allowed in to work on the fiber. I've been trying to search news and information, but nothing. I've heard this is huge outage for Level3 in the New York/Northeast area. Anyone have anything to share? ------------------------------ From mawatari at dti.ad.jp Wed Jun 11 04:44:36 2008 From: mawatari at dti.ad.jp (MAWATARI Masataka) Date: Wed, 11 Jun 2008 18:44:36 +0900 Subject: JANOG's English Page fully renewed Message-ID: <20080611180029.1D7D.E4598BCF@dti.ad.jp> Dear NANOG Colleagues, Japan Network Operators' Group (JANOG) is a forum for network operators in Japan and has been active since 1997. JANOG' s official language is Japanese, with biannual meetings in January and July as well as its mailing list janog[at]janog.gr.jp . JANOG has received numerous requests to make forum discussions available to non Japanese speakers, as discussion topics in a country with very high penetration ratio of broadband access, especially FTTH, would be something different from others and it is felt that other NOG groups could benefit if JANOG's discussion were more widely shared. JANOG volunteer members have been working together recently to make JANOG content available in English in order that non Japanese speakers can share it. This effort is going on through Wiki on JANOG Server and available content is still very limited, however we think that we have reached the initial stage to have it released with a minimum set of content. We are really delighted to announce that the JANOG English website is now available from: http://www.janog.gr.jp/en/ Please visit this site to see what is going on in JANOG. Your comments are most welcome for us to bring better content to English Website. Regards, MAWATARI Masataka, for JANOG i18n Team From michele at blacknight.ie Wed Jun 11 06:27:29 2008 From: michele at blacknight.ie (Michele Neylon) Date: Wed, 11 Jun 2008 12:27:29 +0100 Subject: So, what *really* happened to Amazon last Friday? In-Reply-To: <20080610145308.GA28582@cgi.jachomes.com> References: <20080610145308.GA28582@cgi.jachomes.com> Message-ID: <99326663-EDDD-4CDC-918A-ECAB2565EB4C@blacknight.ie> On 10 Jun 2008, at 15:53, Jay R. Ashworth wrote: > According to the New York Times, two analysts at Bank of America > Equity > Research think that their layer 3 pukes screwed up while preparing to > rollout Unbox: > > http://mobile.nytimes.com/2008/06/09/is-a-new-digital-video-service-derailing-amazoncom/index.xml?partner=rssnyt&single=1&emc=rss Fine, but what about the Amazon UK outage on Monday? > > > Cheers, > -- jra > -- > Jay R. Ashworth jra at baylink.com > Designer +-Internetworking------+--------- > + RFC 2100 > Ashworth & Associates | Best Practices Wiki | > | '87 e24 > St Petersburg FL USA +-http://bestpractices.wikia.com-+ +1 > 727 647 1274 > > If you can read this... thank a system administrator. Or two. > --me Mr Michele Neylon Blacknight Solutions Hosting & Colocation, Brand Protection http://www.blacknight.com/ http://blog.blacknight.com/ Intl. +353 (0) 59 9183072 Locall: 1850 929 929 Direct Dial: +353 (0)59 9183090 Fax. +353 (0) 1 4811 763 ------------------------------- Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty Road,Graiguecullen,Carlow,Ireland Company No.: 370845 From rcorbin at hostmysite.com Wed Jun 11 09:28:18 2008 From: rcorbin at hostmysite.com (Raymond L. Corbin) Date: Wed, 11 Jun 2008 10:28:18 -0400 Subject: Gmail contact? In-Reply-To: <99326663-EDDD-4CDC-918A-ECAB2565EB4C@blacknight.ie> References: <20080610145308.GA28582@cgi.jachomes.com> <99326663-EDDD-4CDC-918A-ECAB2565EB4C@blacknight.ie> Message-ID: <609B96CBFE9ED64A9346C05705CA495204A7EFA24D@MBX02.corp.safesecureweb.com> Hey, Anyone have any contacts within Gmail? Seem to be having a problem with their blacklist. Thanks! -Ray From jfmezei at vaxination.ca Wed Jun 11 10:45:09 2008 From: jfmezei at vaxination.ca (=?ISO-8859-1?Q?Jean-Fran=E7ois_Mezei?=) Date: Wed, 11 Jun 2008 11:45:09 -0400 Subject: PPPoE over L2TP over GigE questions Message-ID: <484FF305.8010001@vaxination.ca> Pardon my ignorance on the subject, but I would need to know how packets between a BAS/LAC and an ISP's router are transported (this is within Bell Canada ADSL territory). Bell uses L2TP to link each BAS/LAC to the ISP. Some of the ISPs get a Gigabit Ethernet link to the Bell cloud. Would the L2TP payload be an ethernet packet which contains a PPPoE packet, or would the L2TP payload be the PPPoE packet only ? Also, while I am at it: Architecturally, is a BAS considered a router, or a bridge/switch ? (since the PPPoE packet has no routing information (source, destination), it is the BAS which maintains the table of source/destination for each PPPoE session ID. Yet, the BAS machines are supposedly Juniper ERX routers in Bell territory... And while I am at it: >From the end user point of view, the ADSL modem sends all ATM frames to a predetermined ATM destination (VPI/VCI). I assume that VPI/VCI points to the BAS. How does the BAS address ATM packets back to an individual subscriber ? Do each subscribers get their own VPI/VCI that points to the right port on the right DSLAM ? And in cases where the telcos are extending the ethernet to the DSLAM, with the fragmentation into multiple ATM frames limited to the ADSL link itself, how does the BAS address invididual customers ? Does each ADSL port on the DSLAM get its own ethernet address ? (since some services do not use PPPoE, I have to assume that the DSLAM doesn't base its packet switching on PPPoE session IDs.) From if at xip.at Wed Jun 11 11:13:23 2008 From: if at xip.at (Ingo Flaschberger) Date: Wed, 11 Jun 2008 18:13:23 +0200 (CEST) Subject: PPPoE over L2TP over GigE questions In-Reply-To: <484FF305.8010001@vaxination.ca> References: <484FF305.8010001@vaxination.ca> Message-ID: Dear Mezei, > Would the L2TP payload be an ethernet packet which contains a PPPoE > packet, or would the L2TP payload be the PPPoE packet only ? ppp frame in l2tp (udp packet). http://www.faqs.org/rfcs/rfc2661.html 5.0 Protocol Operation l2tp is designed for minimal overhead. > Also, while I am at it: > > Architecturally, is a BAS considered a router, or a bridge/switch ? > (since the PPPoE packet has no routing information (source, > destination), it is the BAS which maintains the table of > source/destination for each PPPoE session ID. Yet, the BAS machines are > supposedly Juniper ERX routers in Bell territory... the BAS is a LAC (L2TP Access Concentrator), which preauth the pppoe session, create, if needed a L2TP tunnel to a LNS (L2TP Network Server), handle the authentication between client (pppoe) and LNS. L2TP use one tunnel for 1 LAC - LNS link, meaning more than one pppoe tunnel use a L2TP tunnel link. > And while I am at it: > >> From the end user point of view, the ADSL modem sends all ATM frames to > a predetermined ATM destination (VPI/VCI). I assume that VPI/VCI points > to the BAS. Depends on network design. As adsl use ATM as line protocol, you need VPI/VCI. protocol stack: pppoe ethernet ATM at the provider side you have various options. it is very common that the dslam, that terminates the adsl line has an ethernet upstream port. > How does the BAS address ATM packets back to an individual subscriber ? > Do each subscribers get their own VPI/VCI that points to the right port > on the right DSLAM ? That is done via ppp(oe) authentication. > And in cases where the telcos are extending the ethernet to the DSLAM, > with the fragmentation into multiple ATM frames limited to the ADSL link > itself, how does the BAS address invididual customers ? Does each ADSL > port on the DSLAM get its own ethernet address ? pppoe is ethernet, so they use the mac adress of the pppoe source (client pc, adsl modem, whatever) > (since some services do not use PPPoE, I have to assume that the DSLAM > doesn't base its packet switching on PPPoE session IDs.) pppoe is commonly used for large scale setups. but you can also build a network without pppoe and plain ethernet. Kind regards, Ingo Flaschberger From rs at seastrom.com Wed Jun 11 14:37:42 2008 From: rs at seastrom.com (Robert E. Seastrom) Date: Wed, 11 Jun 2008 15:37:42 -0400 Subject: PPPoE over L2TP over GigE questions In-Reply-To: <484FF305.8010001@vaxination.ca> (=?iso-8859-1?Q?Jean-Fran=E7?= =?iso-8859-1?Q?ois?= Mezei's message of "Wed, 11 Jun 2008 11:45:09 -0400") References: <484FF305.8010001@vaxination.ca> Message-ID: <86od67u5ix.fsf@seastrom.com> Jean-Fran?ois Mezei writes: > Pardon my ignorance on the subject, but I would need to know how packets > between a BAS/LAC and an ISP's router are transported (this is within > Bell Canada ADSL territory). > > Bell uses L2TP to link each BAS/LAC to the ISP. Some of the ISPs get a > Gigabit Ethernet link to the Bell cloud. Actually, they don't set up connections directly from the BASes and SMSes anymore. I'm quite sure they've got some old Redback kit still out there too, as well as perhaps some other ancient stuff. You're going to be talking to a tunnel switch (TSW2-TORONTO63 for instance). These are all Juniper ERXes to the best of my knowledge. N number of BAS/SMS devices talk to a TSW, which talks to your LNS. This cuts down drastically on the number of tunnels that you have to manage (Bell has a couple of hundred BASes out there last I checked). Brings the number of tunnels (and VLANs) down to a couple of hundred. The tunnel switch is smart enough to look inside the authentication packets at session start time and switch you properly based on the realm the customer is logging into. > Would the L2TP payload be an ethernet packet which contains a PPPoE > packet, or would the L2TP payload be the PPPoE packet only ? My recollection is that it includes the src/dst MAC addresses and the rest of the ethernet header in the L2TP frame. > Also, while I am at it: > > Architecturally, is a BAS considered a router, or a bridge/switch ? > (since the PPPoE packet has no routing information (source, > destination), it is the BAS which maintains the table of > source/destination for each PPPoE session ID. Yet, the BAS machines are > supposedly Juniper ERX routers in Bell territory... I'd call them VPN endpoints for a layer 2 VPN; thus the functionality they're providing is more like a bridge than a router, notwithstanding their peeking into layer 5. > And while I am at it: > >>From the end user point of view, the ADSL modem sends all ATM frames to > a predetermined ATM destination (VPI/VCI). I assume that VPI/VCI points > to the BAS. Yes, and at that point it's PPPoEoATM. Which gets turned into PPPoEoATMoL2TP on the upstream side of the BAS. > How does the BAS address ATM packets back to an individual subscriber ? > Do each subscribers get their own VPI/VCI that points to the right port > on the right DSLAM ? Nothing that's visible on the upstream side of the BAS - it's all src/dst mac address at that point. > And in cases where the telcos are extending the ethernet to the DSLAM, > with the fragmentation into multiple ATM frames limited to the ADSL link > itself, how does the BAS address invididual customers ? Does each ADSL > port on the DSLAM get its own ethernet address ? the ADSL router has its own ethernet address. > (since some services do not use PPPoE, I have to assume that the DSLAM > doesn't base its packet switching on PPPoE session IDs.) These other services are VLAN-per-customer and don't use PPPoE or L2TP at all. I think we looked at these and decided not to use 'em. You may be thinking too deeply about this though. Contact me offline if you want a working redacted config for Cisco kit talking to Bell Canada. :-) -r From todd-nanog at renesys.com Wed Jun 11 20:47:52 2008 From: todd-nanog at renesys.com (Todd Underwood) Date: Thu, 12 Jun 2008 01:47:52 +0000 Subject: [NANOG-announce] NANOG 44 Call For Presentations Posted Message-ID: <20080612014752.GV6599@renesys.com> The Call for Presentations for NANOG 44, to be held in Los Angeles, CA October 12 - 15 is posted: http://www.nanog.org/mtg-0810/callforpresent.html The deadline for submissions is July 7 (fast approaching) so please post your abstracts at: http://www.nanogpc.org/ where you will receive instructions on how to submit slideware. If you have a good idea but a presentation but need some feedback or some help developing it, please contact me and I'll be happy to either work directly with you or find someone else on the program committee to help you put together a presentation. Note also that this conference is held just before the ARIN meeting in LA and we are working on programming Wednesday morning to be of special interest to the ARIN audience. So any engineering or operations talks that impact registry policies under consideration would be most appreciated for that segment. The CFP lists a number of subjects were interested in, but as previous NANOG attendees know: if it's on-topic on the mailing list and of interest to network operators, we want it in the program. Submissions have already started rolling in, so for the best chance to have your talk accepted, please submit by the deadline above. Thanks, todd underwood NANOG Program Committee Chair -- _____________________________________________________________________ todd underwood +1 603 643 9300 x101 renesys corporation general manager babbledog todd at renesys.com http://www.renesys.com/blog _______________________________________________ NANOG-announce mailing list NANOG-announce at nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-announce From hank at efes.iucc.ac.il Thu Jun 12 01:16:08 2008 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Thu, 12 Jun 2008 09:16:08 +0300 Subject: Verizon and spam reports Message-ID: <5.1.0.14.2.20080612091125.00b106e8@efes.iucc.ac.il> 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_report at lists.verizonbusiness.com >NOTE: there is no need to acknowledge these reports, the email address: >email_report at lists.verizonbusiness.com 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-0000 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 From andrew at prowant.us Thu Jun 12 09:50:16 2008 From: andrew at prowant.us (Andrew Prowant) Date: Thu, 12 Jun 2008 09:50:16 -0500 Subject: cox.net mail =?UTF-8?Q?contact=3F?= Message-ID: I hate to do this but I have been unable to get anyone at cox.net to respond. No answer from postmaster after weeks of trying. If there is a cox.net contact on the list, I would be extremely grateful if you could put me in contact with a cox.net mail admin. Email to our customers is accepted by the cox.net mail servers but our customers claim the mail never arrives. Thank you, Andrew From heather.schiller at verizonbusiness.com Thu Jun 12 10:25:52 2008 From: heather.schiller at verizonbusiness.com (Heather Schiller) Date: Thu, 12 Jun 2008 11:25:52 -0400 Subject: Verizon and spam reports In-Reply-To: <5.1.0.14.2.20080612091125.00b106e8@efes.iucc.ac.il> References: <5.1.0.14.2.20080612091125.00b106e8@efes.iucc.ac.il> Message-ID: <48514000.6050403@verizonbusiness.com> 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_report at lists.verizonbusiness.com >> NOTE: there is no need to acknowledge these reports, the email >> address: email_report at lists.verizonbusiness.com 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-0000 > > 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 ~*~*~*~*~*~*~*~*~*~*~*~ From jeffshultz at wvi.com Thu Jun 12 12:53:54 2008 From: jeffshultz at wvi.com (Jeff Shultz) Date: Thu, 12 Jun 2008 10:53:54 -0700 Subject: [Outages] outages wiki? feedback please In-Reply-To: <20080612161104.GD7246@cgi.jachomes.com> References: <4850AB10.3060606@gmail.com> <20080612161104.GD7246@cgi.jachomes.com> Message-ID: <485162B2.6040300@wvi.com> Jay R. Ashworth wrote: > On Wed, Jun 11, 2008 at 09:50:24PM -0700, virendra rode // wrote: >> Wiki would serve well for documentation purposes such as operational, >> ISP related such as peer relationships, isp contacts, tools, etc., but >> nothing comes close to real-time outages (user feedback) via e-mail. > > Or, perhaps, an RSS feed from a user-maintained ticketing system. > > I've always wanted to build a public ticketing system, where you could, > for example, hang a ticket on a traffic signal that was out... > > Cheers, > -- jra I can think of a few people I know that would report every single traffic signal (and maybe a few stop signs) as out within 3 days. I'm sure they'd be imaginative in their use of names too. -- Jeff Shultz From rcorbin at hostmysite.com Thu Jun 12 13:55:11 2008 From: rcorbin at hostmysite.com (Raymond L. Corbin) Date: Thu, 12 Jun 2008 14:55:11 -0400 Subject: Spamhaus down? In-Reply-To: <485162B2.6040300@wvi.com> References: <4850AB10.3060606@gmail.com> <20080612161104.GD7246@cgi.jachomes.com> <485162B2.6040300@wvi.com> Message-ID: <609B96CBFE9ED64A9346C05705CA495204A7EFA284@MBX02.corp.safesecureweb.com> Something going on with SpamHaus site/ dnsbl servers? spamhaus.org 1 SOA server: need.to.know.only 259200s email: hostmaster at spamhaus.org serial: 2008060901 refresh: 3600 retry: 600 expire: 2419200 minimum ttl: 3600 spamhaus.org 1 TXT v=spf1 ip4:82.94.216.224/27 -all 172800s spamhaus.org 1 NS ns8.spamhaus.org 172800s spamhaus.org 1 NS ns20.ja.net 172800s spamhaus.org 1 NS hq-ns.oarc.isc.org 172800s spamhaus.org 1 NS ns2.spamhaus.org 172800s spamhaus.org 1 NS ns3.xs4all.nl 172800s spamhaus.org 1 NS ns3.spamhaus.org 172800s spamhaus.org 1 MX preference: 10 300s exchange: smtp-ext-layer.spamhaus.org -Ray From jra at baylink.com Thu Jun 12 14:01:44 2008 From: jra at baylink.com (Jay R. Ashworth) Date: Thu, 12 Jun 2008 15:01:44 -0400 Subject: [Outages] outages wiki? feedback please In-Reply-To: <485162B2.6040300@wvi.com> References: <4850AB10.3060606@gmail.com> <20080612161104.GD7246@cgi.jachomes.com> <485162B2.6040300@wvi.com> Message-ID: <20080612190144.GP7246@cgi.jachomes.com> On Thu, Jun 12, 2008 at 10:53:54AM -0700, Jeff Shultz wrote: > Jay R. Ashworth wrote: > >On Wed, Jun 11, 2008 at 09:50:24PM -0700, virendra rode // wrote: > >>Wiki would serve well for documentation purposes such as operational, > >>ISP related such as peer relationships, isp contacts, tools, etc., but > >>nothing comes close to real-time outages (user feedback) via e-mail. > > > >Or, perhaps, an RSS feed from a user-maintained ticketing system. > > > >I've always wanted to build a public ticketing system, where you could, > >for example, hang a ticket on a traffic signal that was out... > > I can think of a few people I know that would report every single > traffic signal (and maybe a few stop signs) as out within 3 days. > > I'm sure they'd be imaginative in their use of names too. Yeah, this world would be so nice, if it weren't for all the *people* in it. We may have a loop: I didn't post that to NANOG, so far as I know; I sent it to outages at isotf, and my copy back from taht list didn't mention NANOG... Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com '87 e24 St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 Those who cast the vote decide nothing. Those who count the vote decide everything. -- (Joseph Stalin) From marc at let.de Thu Jun 12 14:07:51 2008 From: marc at let.de (Marc Manthey) Date: Thu, 12 Jun 2008 21:07:51 +0200 Subject: Spamhaus down? In-Reply-To: <609B96CBFE9ED64A9346C05705CA495204A7EFA284@MBX02.corp.safesecureweb.com> References: <4850AB10.3060606@gmail.com> <20080612161104.GD7246@cgi.jachomes.com> <485162B2.6040300@wvi.com> <609B96CBFE9ED64A9346C05705CA495204A7EFA284@MBX02.corp.safesecureweb.com> Message-ID: <3C22B6F8-F85B-4BAB-A39C-620A1B6DBD79@let.de> hello gentleman sorry for my offtopic response, but i got a lot of spam in the past days from a fake email at delphi.com there is no email at the delphi.com and the sender seems to be from an dynamic dsl account it changes from different countrys .ar /co /pl is there a way to get rid of it because this email exists since a few days and i never used it. thanks for your time Marc > Von: "G?mmerler" > Datum: 12. Juni 2008 20:34:45 MESZ > An: > Betreff: Das gibt es doch gar nicht - gibt es doch > Antwort an: "G?mmerler" > Return-Path: > Received: from mx1.mail.vrmd.de ([10.0.1.20]) by vm42.mail.vrmd.de > (Cyrus v2.2.12-Invoca-RPM-2.2.12-8.1.RHEL4) with LMTPA; Thu, 12 Jun > 2008 19:58:39 +0200 > Received: from vm47.bln1.vrmd.de ([81.28.224.157] > helo=mx1.mail.vrmd.de) by mx1.mail.vrmd.de with esmtp (Exim 4.62) > (envelope-from ) id 1K6r4J-0006eT-9P for marc at let.de > ; Thu, 12 Jun 2008 19:58:39 +0200 > Received: from 87.238.199.48/32:43217 > (from=;helo=s9048.evanzo-server.de) by > eXpurgate V2.1.1.1, id=150741::080612195838-6D82DAC0-E7D1EFAE with > ESMTP for ; Thu, 12 Jun 2008 19:58:38 +0200 > Received: (qmail 20858 invoked by uid 110); 12 Jun 2008 19:58:38 +0200 > Received: (qmail 20846 invoked from network); 12 Jun 2008 19:58:37 > +0200 > Received: from 201-212-173-150.net.prima.net.ar (HELO delphi.com) > (201.212.173.150) by s9048.evanzo-server.de with SMTP; 12 Jun 2008 > 19:58:31 +0200 > X-Sieve: CMU Sieve 2.2 > Envelope-To: marc at let.de > Delivery-Date: Thu, 12 Jun 2008 19:58:39 +0200 > Delivered-To: 394-info at lettv.de > Message-Id: <81182330.ACEEB624 at delphi.com> > X-Accept-Language: en-us > Mime-Version: 1.0 > Content-Type: multipart/related; > boundary="------------023027716323052264238602" > X-Purgate: This mail is identified as Spam > X-Purgate: spam > X-Purgate-Type: spam > X-Purgate-Ad: Checked for Spam by eleven - eXpurgate www.eXpurgate.net > X-Purgate-Id: 150741::080612195838-6D82DAC0-E7D1EFAE/ > 2337982772-2712154292/0-10 > X-Purgate-Size: 26900/1513 > X-Spam-Suspicion: Yes -- "Imagination is more important than Knowledge". Les enfants teribbles - research and deployment Marc Manthey - head of research and innovation Hildeboldplatz 1a D - 50672 K?ln - Germany Tel.:0049-221-3558032 Mobil:0049-1577-3329231 jabber :marc at kgraff.net blog : http://www.let.de ipv6 http://www.stattfernsehen.com xing : https://www.xing.com/profile/Marc_Manthey From sean at craigslist.org Thu Jun 12 17:37:47 2008 From: sean at craigslist.org (Sean Knox) Date: Thu, 12 Jun 2008 15:37:47 -0700 Subject: Best utilizing fat long pipes and large file transfer Message-ID: <4851A53B.4010400@craigslist.org> Hi, I'm looking for input on the best practices for sending large files over a long fat pipe between facilities (gigabit private circuit, ~20ms RTT). I'd like to avoid modifying TCP windows and options on end hosts where possible (I have a lot of them). I've seen products that work as "transfer stations" using "reliable UDP" to get around the windowing problem. I'm thinking of setting up servers with optimized TCP settings to push big files around data centers but I'm curious to know how others deal with LFN+large transfers. thanks, Sean From oberman at es.net Thu Jun 12 18:05:50 2008 From: oberman at es.net (Kevin Oberman) Date: Thu, 12 Jun 2008 16:05:50 -0700 Subject: Best utilizing fat long pipes and large file transfer In-Reply-To: Your message of "Thu, 12 Jun 2008 15:37:47 PDT." <4851A53B.4010400@craigslist.org> Message-ID: <20080612230550.18AE44500E@ptavv.es.net> > Date: Thu, 12 Jun 2008 15:37:47 -0700 > From: Sean Knox > > Hi, > > I'm looking for input on the best practices for sending large files over > a long fat pipe between facilities (gigabit private circuit, ~20ms RTT). > I'd like to avoid modifying TCP windows and options on end hosts where > possible (I have a lot of them). I've seen products that work as > "transfer stations" using "reliable UDP" to get around the windowing > problem. > > I'm thinking of setting up servers with optimized TCP settings to push > big files around data centers but I'm curious to know how others deal > with LFN+large transfers. Not very fat or very long. I need to deal with 10GE over 200 ms (or more). These should be pretty easy, but as you realize, you will need large enough windows to keep the traffic in transit from filling the window and stalling the flow. The laws of physics (speed of light) are not forgiving. There is a project from Martin Swaney at U-Delaware (with Guy Almes and Aaron Brown) to do exactly what you are looking for. http://portal.acm.org/citation.cfm?id=1188455.1188714&coll=GUIDE&dl=GUIDE and http://www.internet2.edu/pubs/phoebus.pdf ESnet, Internet2 and Geant demonstrated it at last November's SuperComputing Conference in Reno. The idea is to use tuned proxies that are close to the source and destination and are optimized for the delay. Local systems can move data through them without dealing with the need to tune for the delay-bandwidth product. Note that this "man in the middle" may not play well with many security controls which deliberately try to prevent it, so you still may need some adjustments. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman at es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 224 bytes Desc: not available URL: From robert at tellurian.com Thu Jun 12 18:26:56 2008 From: robert at tellurian.com (Robert Boyle) Date: Thu, 12 Jun 2008 19:26:56 -0400 Subject: Best utilizing fat long pipes and large file transfer In-Reply-To: <4851A53B.4010400@craigslist.org> References: <4851A53B.4010400@craigslist.org> Message-ID: <1213313218_50122@mail1.tellurian.net> At 06:37 PM 6/12/2008, you wrote: >I'm looking for input on the best practices for sending large files >over a long fat pipe between facilities (gigabit private circuit, ~20ms RTT). >I'd like to avoid modifying TCP windows and options on end hosts >where possible (I have a lot of them). I've seen products that work >as "transfer stations" using "reliable UDP" to get around the >windowing problem. > >I'm thinking of setting up servers with optimized TCP settings to >push big files around data centers but I'm curious to know how >others deal with LFN+large transfers. In our experience, you can't get to line speed with over 20-30ms of latency using TCP regardless of how much you tweak it. We transfer files across the US with 60-70ms at line speeds with UDP based file transfer programs. There are a number of open source projects out there designed for this purpose. -Robert Tellurian Networks - Global Hosting Solutions Since 1995 http://www.tellurian.com | 888-TELLURIAN | 973-300-9211 "Well done is better than well said." - Benjamin Franklin From randy at psg.com Thu Jun 12 19:02:31 2008 From: randy at psg.com (Randy Bush) Date: Fri, 13 Jun 2008 09:02:31 +0900 Subject: Best utilizing fat long pipes and large file transfer In-Reply-To: <20080612230550.18AE44500E@ptavv.es.net> References: <20080612230550.18AE44500E@ptavv.es.net> Message-ID: <4851B917.50306@psg.com> > The idea is to use tuned proxies that are close to the source and > destination and are optimized for the delay. Local systems can move data > through them without dealing with the need to tune for the > delay-bandwidth product. Note that this "man in the middle" may not > play well with many security controls which deliberately try to prevent > it, so you still may need some adjustments. and for those of us who are addicted to simple rsync, or whatever over ssh, you should be aware of the really bad openssh windowing issue. randy From mdavis at drink-duff.com Thu Jun 12 19:18:56 2008 From: mdavis at drink-duff.com (mdavis at drink-duff.com) Date: Thu, 12 Jun 2008 20:18:56 -0400 Subject: Best utilizing fat long pipes and large file transfer In-Reply-To: <4851A53B.4010400@craigslist.org> References: <4851A53B.4010400@craigslist.org> Message-ID: <20080613001856.GA5097@drink-duff.com> Take a look at some of the stuff from Aspera. Mark On Thu, Jun 12, 2008 at 03:37:47PM -0700, Sean Knox wrote: > Hi, > > I'm looking for input on the best practices for sending large files over > a long fat pipe between facilities (gigabit private circuit, ~20ms RTT). > I'd like to avoid modifying TCP windows and options on end hosts where > possible (I have a lot of them). I've seen products that work as > "transfer stations" using "reliable UDP" to get around the windowing > problem. > > I'm thinking of setting up servers with optimized TCP settings to push > big files around data centers but I'm curious to know how others deal > with LFN+large transfers. > > thanks, > Sean From randy at psg.com Thu Jun 12 19:20:35 2008 From: randy at psg.com (Randy Bush) Date: Fri, 13 Jun 2008 09:20:35 +0900 Subject: Best utilizing fat long pipes and large file transfer In-Reply-To: <4851BAC2.8060007@cavebear.com> References: <20080612230550.18AE44500E@ptavv.es.net> <4851B917.50306@psg.com> <4851BAC2.8060007@cavebear.com> Message-ID: <4851BD53.6050004@psg.com> Karl Auerbach wrote: > Randy Bush wrote: >> and for those of us who are addicted to simple rsync, or whatever over >> ssh, you should be aware of the really bad openssh windowing issue. > I was not aware of this. Do you have a pointer to a description? see the work by rapier and stevens at psc this is why rsync starts off at a blazing pace and then takes a serious dive. randuy From darren at bolding.org Thu Jun 12 19:22:35 2008 From: darren at bolding.org (Darren Bolding) Date: Thu, 12 Jun 2008 17:22:35 -0700 Subject: Best utilizing fat long pipes and large file transfer In-Reply-To: <4851B917.50306@psg.com> References: <20080612230550.18AE44500E@ptavv.es.net> <4851B917.50306@psg.com> Message-ID: <5a318d410806121722s29f980a3lf513bddb348b44f7@mail.gmail.com> And while I certainly like open source solutions, there are plenty of commercial products that do things to optimize this. Depending on the type of traffic the products do different things. Many of the serial-byte caching variety (e.g. Riverbed/F5) now also do connection/flow optimization and proxying, while many of the network optimizers now are doing serial-byte caching. I also for a while was looking for multicast based file transfer tools, but couldn't find any that were stable. I'd be interested in seeing the names of some of the projects Robert is talking about- perhaps I missed a few when I looked. One thing that is a simple solution? Split the file and then send all the parts at the same time. This helps a fair bit, and is easy to implement. Few things drive home the issues with TCP window scaling better than moving a file via ftp and then via ttcp. Sure, you don't always get all the file, but it does get there fast! --D On Thu, Jun 12, 2008 at 5:02 PM, Randy Bush wrote: > > The idea is to use tuned proxies that are close to the source and > > destination and are optimized for the delay. Local systems can move data > > through them without dealing with the need to tune for the > > delay-bandwidth product. Note that this "man in the middle" may not > > play well with many security controls which deliberately try to prevent > > it, so you still may need some adjustments. > > and for those of us who are addicted to simple rsync, or whatever over > ssh, you should be aware of the really bad openssh windowing issue. > > randy > > -- -- Darren Bolding -- -- darren at bolding.org -- From gtb at slac.stanford.edu Thu Jun 12 19:28:52 2008 From: gtb at slac.stanford.edu (Buhrmaster, Gary) Date: Thu, 12 Jun 2008 17:28:52 -0700 Subject: Best utilizing fat long pipes and large file transfer In-Reply-To: <4851A53B.4010400@craigslist.org> References: <4851A53B.4010400@craigslist.org> Message-ID: > Hi, > > I'm looking for input on the best practices for sending large > files There are both commercial products (fastcopy) and various "free"(*) products (bbcp, bbftp, gridftp) that will send large files. While they can take advantage of larger windows they also have the capability of using multiple streams (dealing with the inability to tune the tcp stack). There are, of course, competitors to these products which you should look into. As always, YMWV. Some references: http://www.softlink.com/fastcopy_techie.html (Some parts of NASA seem to like fastcopy) http://nccs.gov/user-support/general-support/data-transfer/bbcp/ (Full disclosure, bbcp was written by someone who sits about 3 meters from where I am sitting, but I cannot find a nice web reference from him about the product, so I am showing a different sites documentation) http://doc.in2p3.fr/bbftp/ (One of the first to use multistream for BaBar) http://www.globus.org/grid_software/data/gridftp.php (Part of the globus toolkit. Somewhat heavier weight if all you want is file transfer.) http://fasterdata.es.net/tools.html (A reference I am surprised Kevin did not point to :-) http://www.slac.stanford.edu/grp/scs/net/talk/ggf5_jul2002/NMWG_GGF5.pdf (A few year old performance evaluation) www.triumf.ca/canarie/amsterdam-test/References/010402-ftp.ppt (Another older performance evaluation) Gary (*) Some are GPL, and some (modified) BSD licenses. Which one is "free enough" depends on some strongly held beliefs of the validator. From ltd at interlink.com.au Thu Jun 12 19:58:46 2008 From: ltd at interlink.com.au (Lincoln Dale) Date: Fri, 13 Jun 2008 10:58:46 +1000 Subject: Best utilizing fat long pipes and large file transfer In-Reply-To: <4851A53B.4010400@craigslist.org> References: <4851A53B.4010400@craigslist.org> Message-ID: <01b401c8ccf0$a6549ec0$046f09cb@ltdbeast> > I'm looking for input on the best practices for sending large files over > a long fat pipe between facilities (gigabit private circuit, ~20ms RTT). providing you have RFC1323 type extensions enabled on a semi-decent OS, a 4MB TCP window should be more than sufficient to fill a GbE pipe over 30msec. with a modified TCP stack, that uses TCP window sizes up to 32MB, i've worked with numerous customers to achieve wire-rate GbE async replication for storage-arrays with FCIP. the modifications to TCP were mostly to adjust how it reacts to packet loss, e.g. don't "halve the window". the intent of those modifications is that it doesn't use the "greater internet" but is more suited for private connections within an enterprise customer environment. that is used in production today on many Cisco MDS 9xxx FC switch environments. > I'd like to avoid modifying TCP windows and options on end hosts where > possible (I have a lot of them). I've seen products that work as > "transfer stations" using "reliable UDP" to get around the windowing > problem. given you don't want to modify all your hosts, you could 'proxy' said TCP connections via 'socat' or 'netcat++'. cheers, lincoln. From Taeko.Thompson at wizards.com Thu Jun 12 20:02:52 2008 From: Taeko.Thompson at wizards.com (Thompson, Taeko) Date: Thu, 12 Jun 2008 18:02:52 -0700 Subject: comcast In-Reply-To: <01b401c8ccf0$a6549ec0$046f09cb@ltdbeast> References: <4851A53B.4010400@craigslist.org> <01b401c8ccf0$a6549ec0$046f09cb@ltdbeast> Message-ID: <1924A50606A1904F8897B9CCE1B6ACA401AB6F43@USRNTWZEXG01.wz.hasbro.com> Does anybody heard if comcast is having problems today? Thank you, Taeko From mpalmer at hezmatt.org Thu Jun 12 20:09:28 2008 From: mpalmer at hezmatt.org (Matt Palmer) Date: Fri, 13 Jun 2008 11:09:28 +1000 Subject: comcast In-Reply-To: <1924A50606A1904F8897B9CCE1B6ACA401AB6F43@USRNTWZEXG01.wz.hasbro.com> References: <4851A53B.4010400@craigslist.org> <01b401c8ccf0$a6549ec0$046f09cb@ltdbeast> <1924A50606A1904F8897B9CCE1B6ACA401AB6F43@USRNTWZEXG01.wz.hasbro.com> Message-ID: <20080613010928.GI9702@hezmatt.org> On Thu, Jun 12, 2008 at 06:02:52PM -0700, Thompson, Taeko wrote: > Does anybody heard if comcast is having problems today? Since I got on shift two hours ago, I've done nothing but stare at traceroutes into and out of Comcast space trying to reassure dozens of customers that we're not down, Comcast is having problems. Our upstream claims they've been dealing with Comcast customers all (US) day. I'm pretty sure there's some serious weirdness going on in there. (Oh, and don't reply to an existing message to start a new thread) - Matt From rs at seastrom.com Thu Jun 12 20:15:49 2008 From: rs at seastrom.com (Robert E. Seastrom) Date: Thu, 12 Jun 2008 21:15:49 -0400 Subject: Best utilizing fat long pipes and large file transfer In-Reply-To: <4851B917.50306@psg.com> (Randy Bush's message of "Fri, 13 Jun 2008 09:02:31 +0900") References: <20080612230550.18AE44500E@ptavv.es.net> <4851B917.50306@psg.com> Message-ID: <86od66t9ru.fsf@seastrom.com> Randy Bush writes: > and for those of us who are addicted to simple rsync, or whatever over > ssh, you should be aware of the really bad openssh windowing issue. As a user of hpn-ssh for years, I have to wonder if there is any reason (aside from the sheer cussedness for which Theo is infamous) that the window improvements at least from hpn-ssh haven't been backported into mainline openssh? I suppose there might be portability concerns with the multithreaded ciphers, and there's certainly a good argument for not supporting NONE as a cipher type out of the box without a recompile, but there's not much excuse for the fixed size tiny buffers - I mean, it's 2008 already... -r From randy at psg.com Thu Jun 12 20:17:07 2008 From: randy at psg.com (Randy Bush) Date: Fri, 13 Jun 2008 10:17:07 +0900 Subject: comcast In-Reply-To: <1924A50606A1904F8897B9CCE1B6ACA401AB6F43@USRNTWZEXG01.wz.hasbro.com> References: <4851A53B.4010400@craigslist.org> <01b401c8ccf0$a6549ec0$046f09cb@ltdbeast> <1924A50606A1904F8897B9CCE1B6ACA401AB6F43@USRNTWZEXG01.wz.hasbro.com> Message-ID: <4851CA93.9040006@psg.com> > Does anybody heard if comcast is having problems today? lucy was having problems in eugene orygun. she diagnosed and then gave up and went to dinner. randy From orion at pirk.com Thu Jun 12 20:23:45 2008 From: orion at pirk.com (Steve Pirk) Date: Thu, 12 Jun 2008 18:23:45 -0700 (PDT) Subject: comcast In-Reply-To: <4851CA93.9040006@psg.com> References: <4851A53B.4010400@craigslist.org> <01b401c8ccf0$a6549ec0$046f09cb@ltdbeast> <1924A50606A1904F8897B9CCE1B6ACA401AB6F43@USRNTWZEXG01.wz.hasbro.com> <4851CA93.9040006@psg.com> Message-ID: On Fri, 13 Jun 2008, Randy Bush wrote: >> Does anybody heard if comcast is having problems today? > > lucy was having problems in eugene orygun. she diagnosed and then gave > up and went to dinner. > > randy > I have a comcast business line in Western WA and have seen no hiccups so far today. Main IP is 75.146.60.201. If someone that is seeing issues can send me an IP, I can traceroute to see if I can reach it from within Comcast. -- Steve Equal bytes for women. From bifrost at minions.com Thu Jun 12 20:51:48 2008 From: bifrost at minions.com (Tom) Date: Thu, 12 Jun 2008 18:51:48 -0700 (PDT) Subject: comcast In-Reply-To: <1924A50606A1904F8897B9CCE1B6ACA401AB6F43@USRNTWZEXG01.wz.hasbro.com> References: <4851A53B.4010400@craigslist.org> <01b401c8ccf0$a6549ec0$046f09cb@ltdbeast> <1924A50606A1904F8897B9CCE1B6ACA401AB6F43@USRNTWZEXG01.wz.hasbro.com> Message-ID: <20080612184749.G59005@evil.minions.com> On Thu, 12 Jun 2008, Thompson, Taeko wrote: > Does anybody heard if comcast is having problems today? I've got a customer in 73.72.92.0/24, and I don't see the prefix on the net. From pstewart at nexicomgroup.net Thu Jun 12 20:55:39 2008 From: pstewart at nexicomgroup.net (Paul Stewart) Date: Thu, 12 Jun 2008 21:55:39 -0400 Subject: comcast In-Reply-To: <20080612184749.G59005@evil.minions.com> References: <4851A53B.4010400@craigslist.org><01b401c8ccf0$a6549ec0$046f09cb@ltdbeast><1924A50606A1904F8897B9CCE1B6ACA401AB6F43@USRNTWZEXG01.wz.hasbro.com> <20080612184749.G59005@evil.minions.com> Message-ID: <89D27DE3375BB6428DDCC2927489826A01537D2D@nexus.nexicomgroup.net> Just to confirm from here (Toronto): core2-rtr-to#sh ip bgp 73.72.92.0 % Network not in table Paul -----Original Message----- From: Tom [mailto:bifrost at minions.com] Sent: Thursday, June 12, 2008 9:52 PM To: nanog at merit.edu Subject: Re: comcast On Thu, 12 Jun 2008, Thompson, Taeko wrote: > Does anybody heard if comcast is having problems today? I've got a customer in 73.72.92.0/24, and I don't see the prefix on the net. ---------------------------------------------------------------------------- "The information transmitted is intended only for the person or entity to which it is addressed and contains confidential and/or privileged material. If you received this in error, please contact the sender immediately and then destroy this transmission, including all attachments, without copying, distributing or disclosing same. Thank you." From ekagan at axsne.com Thu Jun 12 21:01:03 2008 From: ekagan at axsne.com (ekagan at axsne.com) Date: Thu, 12 Jun 2008 22:01:03 -0400 Subject: comcast In-Reply-To: References: <4851A53B.4010400@craigslist.org><01b401c8ccf0$a6549ec0$046f09cb@ltdbeast><1924A50606A1904F8897B9CCE1B6ACA401AB6F43@USRNTWZEXG01.wz.hasbro.com><4851CA93.9040006@psg.com> Message-ID: <42F2995AD6FA0C4CA1EFBFD0CD3E9ABE011B7181@exch01.axsdom.local> > On Fri, 13 Jun 2008, Randy Bush wrote: > > >> Does anybody heard if comcast is having problems today? > > > > lucy was having problems in eugene orygun. she diagnosed > and then gave > > up and went to dinner. > > > > randy > > > > I have a comcast business line in Western WA and have seen no hiccups > so far today. Main IP is 75.146.60.201. > > If someone that is seeing issues can send me an IP, I can traceroute > to see if I can reach it from within Comcast. > -- > Steve > Equal bytes for women. > I have Smokeping running from behind my Comcast (Eastern MA / New England) and have alarms of latency from 6:28P-7:18pm EST. Not sure if attachments make it through - but doc of last 3 hr graph showing .13% loss avg and 4.57% max loss. Seems clean otherwise. On Tuesday I had alarms going all day long.....I run monitors to my Corp Network and Legacy Genuity DNS and the results are the same for both. Eric -------------- next part -------------- A non-text attachment was scrubbed... Name: Offline-Monitor_last_10800[1].png Type: image/png Size: 34149 bytes Desc: Offline-Monitor_last_10800[1].png URL: From oberman at es.net Thu Jun 12 21:11:06 2008 From: oberman at es.net (Kevin Oberman) Date: Thu, 12 Jun 2008 19:11:06 -0700 Subject: Best utilizing fat long pipes and large file transfer In-Reply-To: Your message of "Fri, 13 Jun 2008 09:02:31 +0900." <4851B917.50306@psg.com> Message-ID: <20080613021106.CD6FD4500E@ptavv.es.net> > Date: Fri, 13 Jun 2008 09:02:31 +0900 > From: Randy Bush > > > The idea is to use tuned proxies that are close to the source and > > destination and are optimized for the delay. Local systems can move data > > through them without dealing with the need to tune for the > > delay-bandwidth product. Note that this "man in the middle" may not > > play well with many security controls which deliberately try to prevent > > it, so you still may need some adjustments. > > and for those of us who are addicted to simple rsync, or whatever over > ssh, you should be aware of the really bad openssh windowing issue. Actually, OpenSSH has a number of issues that restrict performance. Read about them at Pittsburgh Supercomputer Center fixed these problems and on FreeBSD, you can get these by replacing the base OpenSSH with the openssh-portable port and select the HPN (High Performance Networking) and OVERWRITE_BASE options. I assume other OSes can deal with this or you can get the patches directly from: The port may also be built to support SmartCards which we require for authentication. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman at es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 224 bytes Desc: not available URL: From dcp at dcptech.com Thu Jun 12 21:12:15 2008 From: dcp at dcptech.com (David Prall) Date: Thu, 12 Jun 2008 22:12:15 -0400 Subject: comcast In-Reply-To: <20080612184749.G59005@evil.minions.com> References: <4851A53B.4010400@craigslist.org><01b401c8ccf0$a6549ec0$046f09cb@ltdbeast><1924A50606A1904F8897B9CCE1B6ACA401AB6F43@USRNTWZEXG01.wz.hasbro.com> <20080612184749.G59005@evil.minions.com> Message-ID: <007f01c8ccfa$e9512a40$1dfe200a@cisco.com> Tom, Where would that be located. From my house my UUNet/MCI/Verizon Business Link doesn't have it. My speakeasy link doesn't have it either. All of Comcast was out in my neighborhood (Alexandria, VA) yesterday at 7pm when I got home, was still out at 11pm when I went to bed, up and running fine this AM. David -- http://dcp.dcptech.com > -----Original Message----- > From: Tom [mailto:bifrost at minions.com] > Sent: Thursday, June 12, 2008 9:52 PM > To: nanog at merit.edu > Subject: Re: comcast > > On Thu, 12 Jun 2008, Thompson, Taeko wrote: > > Does anybody heard if comcast is having problems today? > > I've got a customer in 73.72.92.0/24, and I don't see the > prefix on the > net. From christian at visr.org Thu Jun 12 21:24:32 2008 From: christian at visr.org (Christian) Date: Thu, 12 Jun 2008 22:24:32 -0400 Subject: comcast In-Reply-To: <20080612184749.G59005@evil.minions.com> References: <4851A53B.4010400@craigslist.org> <01b401c8ccf0$a6549ec0$046f09cb@ltdbeast> <1924A50606A1904F8897B9CCE1B6ACA401AB6F43@USRNTWZEXG01.wz.hasbro.com> <20080612184749.G59005@evil.minions.com> Message-ID: <9b62cf2f0806121924u6693389ci847d7569e32c83a9@mail.gmail.com> when was the last time you saw this prefix reachable? i dont see anything announced from comcasts 73.0.0.0/8 allocation within the past 2 weeks... On Thu, Jun 12, 2008 at 9:51 PM, Tom wrote: > On Thu, 12 Jun 2008, Thompson, Taeko wrote: > >> Does anybody heard if comcast is having problems today? >> > > I've got a customer in 73.72.92.0/24, and I don't see the prefix on the > net. > > From oberman at es.net Thu Jun 12 21:34:46 2008 From: oberman at es.net (Kevin Oberman) Date: Thu, 12 Jun 2008 19:34:46 -0700 Subject: Best utilizing fat long pipes and large file transfer In-Reply-To: Your message of "Thu, 12 Jun 2008 21:15:49 EDT." <86od66t9ru.fsf@seastrom.com> Message-ID: <20080613023446.9CF254500E@ptavv.es.net> > From: "Robert E. Seastrom" > Date: Thu, 12 Jun 2008 21:15:49 -0400 > > > Randy Bush writes: > > > and for those of us who are addicted to simple rsync, or whatever over > > ssh, you should be aware of the really bad openssh windowing issue. > > As a user of hpn-ssh for years, I have to wonder if there is any > reason (aside from the sheer cussedness for which Theo is infamous) > that the window improvements at least from hpn-ssh haven't been > backported into mainline openssh? I suppose there might be > portability concerns with the multithreaded ciphers, and there's > certainly a good argument for not supporting NONE as a cipher type out > of the box without a recompile, but there's not much excuse for the > fixed size tiny buffers - I mean, it's 2008 already... Theo is known for his amazing stubbornness, but for area involving security and cryptography, I find it hard to say that his conservatism is excessive. Crypto is hard and often it is very non-intuitive. I remember the long discussions on entropy harvesting and seeding in FreeBSD which fortunately has cryptography professionals who could pick every nit and make sure FreeBSD did not end up with Debian-type egg all over its virtual face. Than again, the tiny buffers are silly and I can't imagine any possible security issue there. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman at es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 224 bytes Desc: not available URL: From yahoo at jimpop.com Thu Jun 12 21:35:08 2008 From: yahoo at jimpop.com (Jim Popovitch) Date: Thu, 12 Jun 2008 22:35:08 -0400 Subject: comcast In-Reply-To: <9b62cf2f0806121924u6693389ci847d7569e32c83a9@mail.gmail.com> References: <4851A53B.4010400@craigslist.org> <01b401c8ccf0$a6549ec0$046f09cb@ltdbeast> <1924A50606A1904F8897B9CCE1B6ACA401AB6F43@USRNTWZEXG01.wz.hasbro.com> <20080612184749.G59005@evil.minions.com> <9b62cf2f0806121924u6693389ci847d7569e32c83a9@mail.gmail.com> Message-ID: <7ff145960806121935t406e833fw2287fb9d210b3735@mail.gmail.com> On Thu, Jun 12, 2008 at 10:24 PM, Christian wrote: > when was the last time you saw this prefix reachable? > > i dont see anything announced from comcasts 73.0.0.0/8 allocation within the > past 2 weeks... FYI: Internally within Comcast it does route: $ mtr --report -c 1 73.0.0.1 HOST: blue Loss% Snt Last Avg Best Wrst StDev 1. linksys 0.0% 1 0.9 0.9 0.9 0.9 0.0 2. c-24-98-192-1.hsd1.ga.comcas 0.0% 1 7.3 7.3 7.3 7.3 0.0 3. ge-2-5-ur01.a2atlanta.ga.atl 0.0% 1 8.0 8.0 8.0 8.0 0.0 4. te-9-1-ur02.a2atlanta.ga.atl 0.0% 1 6.0 6.0 6.0 6.0 0.0 5. te-9-3-ur01.b0atlanta.ga.atl 0.0% 1 6.5 6.5 6.5 6.5 0.0 6. 68.85.232.62 0.0% 1 6.4 6.4 6.4 6.4 0.0 7. po-15-ar01.b0atlanta.ga.atla 0.0% 1 7.6 7.6 7.6 7.6 0.0 8. te-4-1-cr01.atlanta.ga.cbone 0.0% 1 9.0 9.0 9.0 9.0 0.0 9. te-1-1-cr01.charlotte.nc.cbo 0.0% 1 11.8 11.8 11.8 11.8 0.0 10. te-1-1-cr01.richmond.va.cbon 0.0% 1 19.5 19.5 19.5 19.5 0.0 11. te-1-1-cr01.mclean.va.cbone. 0.0% 1 24.0 24.0 24.0 24.0 0.0 12. te-1-1-cr01.philadelphia.pa. 0.0% 1 25.6 25.6 25.6 25.6 0.0 13. be-40-crs01.401nbroadst.pa.p 0.0% 1 26.5 26.5 26.5 26.5 0.0 14. be-50-crs01.ivyland.pa.panjd 0.0% 1 28.8 28.8 28.8 28.8 0.0 15. po-10-ar01.verona.nj.panjde. 0.0% 1 41.7 41.7 41.7 41.7 0.0 16. po-10-ar01.eatontown.nj.panj 0.0% 1 33.5 33.5 33.5 33.5 0.0 17. po-10-ur01.middletown.nj.pan 0.0% 1 34.4 34.4 34.4 34.4 0.0 18. po-10-ur01.burlington.nj.pan 0.0% 1 48.0 48.0 48.0 48.0 0.0 -Jim P. From christian at visr.org Thu Jun 12 21:42:58 2008 From: christian at visr.org (Christian) Date: Thu, 12 Jun 2008 22:42:58 -0400 Subject: comcast In-Reply-To: <7ff145960806121935t406e833fw2287fb9d210b3735@mail.gmail.com> References: <4851A53B.4010400@craigslist.org> <01b401c8ccf0$a6549ec0$046f09cb@ltdbeast> <1924A50606A1904F8897B9CCE1B6ACA401AB6F43@USRNTWZEXG01.wz.hasbro.com> <20080612184749.G59005@evil.minions.com> <9b62cf2f0806121924u6693389ci847d7569e32c83a9@mail.gmail.com> <7ff145960806121935t406e833fw2287fb9d210b3735@mail.gmail.com> Message-ID: <9b62cf2f0806121942u213e4541jdf0e5e45cb6c3a64@mail.gmail.com> interesting enough mine goes the other way brokenrobot:~ christian$ traceroute 73.72.92.1 traceroute to 73.72.92.1 (73.72.92.1), 64 hops max, 40 byte packets 1 192.168.2.1 (192.168.2.1) 12.130 ms 1.135 ms 1.262 ms 2 * * * 3 ge-2-3-ur01.jerseycity.nj.panjde.comcast.net (68.86.220.185) 10.710 ms 9.638 ms 12.299 ms 4 po-10-ur02.jerseycity.nj.panjde.comcast.net (68.86.209.246) 15.747 ms 13.280 ms 10.082 ms 5 po-10-ur01.narlington.nj.panjde.comcast.net (68.86.209.250) 11.373 ms 10.847 ms 11.873 ms 6 po-10-ur02.narlington.nj.panjde.comcast.net (68.86.158.178) 36.034 ms 11.622 ms 16.032 ms 7 po-70-ar01.verona.nj.panjde.comcast.net (68.86.209.254) 17.642 ms 16.334 ms 11.358 ms 8 te-0-7-0-7-crs01.plainfield.nj.panjde.comcast.net (68.86.72.18) 25.986 ms 13.774 ms 12.524 ms 9 te-4-1-cr01.newyork.ny.cbone.comcast.net (68.86.72.17) 22.172 ms 24.545 ms 17.774 ms 10 te-9-1-cr01.philadelphia.pa.cbone.comcast.net (68.86.68.5) 16.040 ms 14.670 ms 14.232 ms 11 te-9-1-cr01.mclean.va.cbone.comcast.net (68.86.68.1) 32.585 ms 20.303 ms 28.397 ms 12 te-9-1-cr02.pittsburgh.pa.cbone.comcast.net (68.86.68.125) 24.909 ms 24.261 ms 34.669 ms 13 te-8-1-cr01.cleveland.oh.cbone.comcast.net (68.86.68.117) 28.253 ms 26.949 ms 27.105 ms 14 te-9-1-cr01.chicago.il.cbone.comcast.net (68.86.68.22) 37.728 ms 59.564 ms 36.835 ms 15 te-9-1-cr01.omaha.ne.cbone.comcast.net (68.86.68.30) 53.805 ms 54.945 ms 53.015 ms 16 te-9-1-cr01.denver.co.cbone.comcast.net (68.86.68.42) 62.957 ms 74.028 ms 63.913 ms 17 te-9-1-cr01.denverqwest.co.cbone.comcast.net (68.86.68.146) 62.570 ms 68.635 ms 62.655 ms 18 te-2-1-cr01.santateresa.tx.cbone.comcast.net (68.86.68.150) 74.011 ms 74.431 ms 76.615 ms 19 te-8-1-cr01.losangeles.ca.cbone.comcast.net (68.86.68.81) 92.442 ms 93.805 ms 93.965 ms 20 te-9-1-cr01.sacramento.ca.cbone.comcast.net (68.86.68.69) 105.415 ms 102.575 ms 103.331 ms 21 te-0-2-0-1-ar01.oakland.ca.sfba.comcast.net (68.87.192.134) 111.564 ms 111.281 ms 106.768 ms 22 te-9-3-ur02.pittsburg.ca.sfba.comcast.net (68.87.192.133) 105.908 ms 105.997 ms 108.539 ms 23 GE-6-1-ur01.pittsburg.ca.sfba.comcast.net (68.87.199.173) 107.303 ms 108.250 ms 110.819 ms 24 ge-0-1-ubr02.pittsburg.ca.sfba.comcast.net (68.87.197.22) 119.945 ms * 107.782 ms On Thu, Jun 12, 2008 at 10:35 PM, Jim Popovitch wrote: > On Thu, Jun 12, 2008 at 10:24 PM, Christian wrote: > > when was the last time you saw this prefix reachable? > > > > i dont see anything announced from comcasts 73.0.0.0/8 allocation within > the > > past 2 weeks... > > FYI: Internally within Comcast it does route: > > $ mtr --report -c 1 73.0.0.1 > HOST: blue Loss% Snt Last Avg Best Wrst > StDev > 1. linksys 0.0% 1 0.9 0.9 0.9 0.9 0.0 > 2. c-24-98-192-1.hsd1.ga.comcas 0.0% 1 7.3 7.3 7.3 7.3 0.0 > 3. ge-2-5-ur01.a2atlanta.ga.atl 0.0% 1 8.0 8.0 8.0 8.0 0.0 > 4. te-9-1-ur02.a2atlanta.ga.atl 0.0% 1 6.0 6.0 6.0 6.0 0.0 > 5. te-9-3-ur01.b0atlanta.ga.atl 0.0% 1 6.5 6.5 6.5 6.5 0.0 > 6. 68.85.232.62 0.0% 1 6.4 6.4 6.4 6.4 > 0.0 > 7. po-15-ar01.b0atlanta.ga.atla 0.0% 1 7.6 7.6 7.6 7.6 0.0 > 8. te-4-1-cr01.atlanta.ga.cbone 0.0% 1 9.0 9.0 9.0 9.0 0.0 > 9. te-1-1-cr01.charlotte.nc.cbo 0.0% 1 11.8 11.8 11.8 11.8 0.0 > 10. te-1-1-cr01.richmond.va.cbon 0.0% 1 19.5 19.5 19.5 19.5 > 0.0 > 11. te-1-1-cr01.mclean.va.cbone. 0.0% 1 24.0 24.0 24.0 24.0 > 0.0 > 12. te-1-1-cr01.philadelphia.pa. 0.0% 1 25.6 25.6 25.6 25.6 > 0.0 > 13. be-40-crs01.401nbroadst.pa.p 0.0% 1 26.5 26.5 26.5 26.5 > 0.0 > 14. be-50-crs01.ivyland.pa.panjd 0.0% 1 28.8 28.8 28.8 28.8 > 0.0 > 15. po-10-ar01.verona.nj.panjde. 0.0% 1 41.7 41.7 41.7 41.7 > 0.0 > 16. po-10-ar01.eatontown.nj.panj 0.0% 1 33.5 33.5 33.5 33.5 > 0.0 > 17. po-10-ur01.middletown.nj.pan 0.0% 1 34.4 34.4 34.4 34.4 > 0.0 > 18. po-10-ur01.burlington.nj.pan 0.0% 1 48.0 48.0 48.0 48.0 > 0.0 > > -Jim P. > > From smb at cs.columbia.edu Thu Jun 12 21:51:18 2008 From: smb at cs.columbia.edu (Steven M. Bellovin) Date: Thu, 12 Jun 2008 22:51:18 -0400 Subject: comcast In-Reply-To: <42F2995AD6FA0C4CA1EFBFD0CD3E9ABE011B7181@exch01.axsdom.local> References: <4851A53B.4010400@craigslist.org> <01b401c8ccf0$a6549ec0$046f09cb@ltdbeast> <1924A50606A1904F8897B9CCE1B6ACA401AB6F43@USRNTWZEXG01.wz.hasbro.com> <4851CA93.9040006@psg.com> <42F2995AD6FA0C4CA1EFBFD0CD3E9ABE011B7181@exch01.axsdom.local> Message-ID: <20080612225118.47d0ff7f@cs.columbia.edu> On Thu, 12 Jun 2008 22:01:03 -0400 wrote: > > On Fri, 13 Jun 2008, Randy Bush wrote: > > > > >> Does anybody heard if comcast is having problems today? > > > > > > lucy was having problems in eugene orygun. she diagnosed > > and then gave > > > up and went to dinner. > > > > > > randy > > > > > > > I have a comcast business line in Western WA and have seen no > > hiccups so far today. Main IP is 75.146.60.201. > > > > If someone that is seeing issues can send me an IP, I can traceroute > > to see if I can reach it from within Comcast. > > -- > > Steve > > Equal bytes for women. > > > > I have Smokeping running from behind my Comcast (Eastern MA / New > England) and have alarms of latency from 6:28P-7:18pm EST. Not sure > if attachments make it through - but doc of last 3 hr graph > showing .13% loss avg and 4.57% max loss. Seems clean otherwise. On > Tuesday I had alarms going all day long.....I run monitors to my Corp > Network and Legacy Genuity DNS and the results are the same for both. > I didn't get online tonight till ~8pm, but I haven't noticed any problems at all. (I'm on 74/8.) --Steve Bellovin, http://www.cs.columbia.edu/~smb From forsaken at targaryen.us Thu Jun 12 21:53:32 2008 From: forsaken at targaryen.us (Forsaken) Date: Thu, 12 Jun 2008 22:53:32 -0400 Subject: comcast In-Reply-To: <1924A50606A1904F8897B9CCE1B6ACA401AB6F43@USRNTWZEXG01.wz.hasbro.com> References: <4851A53B.4010400@craigslist.org> <01b401c8ccf0$a6549ec0$046f09cb@ltdbeast> <1924A50606A1904F8897B9CCE1B6ACA401AB6F43@USRNTWZEXG01.wz.hasbro.com> Message-ID: <20080612225332.4f5cc69b@tywin> On Thu, 12 Jun 2008 18:02:52 -0700 "Thompson, Taeko" wrote: They've been fine in my area (atlanta), though there was a fair bit of downtime last week. I did, however, notice today that my port 25 blocks are gone... which wasn't the case last week. > > Does anybody heard if comcast is having problems today? > > Thank you, > Taeko > From hannigan at gmail.com Thu Jun 12 22:34:20 2008 From: hannigan at gmail.com (Martin Hannigan) Date: Thu, 12 Jun 2008 23:34:20 -0400 Subject: comcast In-Reply-To: <7ff145960806121935t406e833fw2287fb9d210b3735@mail.gmail.com> References: <4851A53B.4010400@craigslist.org> <01b401c8ccf0$a6549ec0$046f09cb@ltdbeast> <1924A50606A1904F8897B9CCE1B6ACA401AB6F43@USRNTWZEXG01.wz.hasbro.com> <20080612184749.G59005@evil.minions.com> <9b62cf2f0806121924u6693389ci847d7569e32c83a9@mail.gmail.com> <7ff145960806121935t406e833fw2287fb9d210b3735@mail.gmail.com> Message-ID: <2d106eb50806122034k58991942xd833341071ed4b23@mail.gmail.com> On Thu, Jun 12, 2008 at 10:35 PM, Jim Popovitch wrote: > 18. po-10-ur01.burlington.nj.pan 0.0% 1 48.0 48.0 48.0 48.0 0.0 23 114 ms 122 ms 113 ms ge-0-1-ubr02.pittsburg.ca.sfba.comcast.net [68.8 7.197.22] F?r eine Weile hatten wir Zugang durch eine Hong Kong basiert Piraten-Netzwerk -M< From yahoo at jimpop.com Thu Jun 12 23:59:28 2008 From: yahoo at jimpop.com (Jim Popovitch) Date: Fri, 13 Jun 2008 00:59:28 -0400 Subject: comcast In-Reply-To: <2d106eb50806122034k58991942xd833341071ed4b23@mail.gmail.com> References: <4851A53B.4010400@craigslist.org> <01b401c8ccf0$a6549ec0$046f09cb@ltdbeast> <1924A50606A1904F8897B9CCE1B6ACA401AB6F43@USRNTWZEXG01.wz.hasbro.com> <20080612184749.G59005@evil.minions.com> <9b62cf2f0806121924u6693389ci847d7569e32c83a9@mail.gmail.com> <7ff145960806121935t406e833fw2287fb9d210b3735@mail.gmail.com> <2d106eb50806122034k58991942xd833341071ed4b23@mail.gmail.com> Message-ID: <7ff145960806122159r21f5158oc0f57726e081dfbc@mail.gmail.com> On Thu, Jun 12, 2008 at 11:34 PM, Martin Hannigan wrote: > On Thu, Jun 12, 2008 at 10:35 PM, Jim Popovitch wrote: > >> 18. po-10-ur01.burlington.nj.pan 0.0% 1 48.0 48.0 48.0 48.0 0.0 > > 23 114 ms 122 ms 113 ms ge-0-1-ubr02.pittsburg.ca.sfba.comcast.net [68.8 > 7.197.22] > > F?r eine Weile hatten wir Zugang durch eine Hong Kong basiert Piraten-Netzwerk Yeah, I've saw similar in traces a few days back, I wondered wtf. -Jim P. From michal at krsek.cz Fri Jun 13 01:42:57 2008 From: michal at krsek.cz (Michal Krsek) Date: Fri, 13 Jun 2008 08:42:57 +0200 Subject: Best utilizing fat long pipes and large file transfer In-Reply-To: <4851A53B.4010400@craigslist.org> References: <4851A53B.4010400@craigslist.org> Message-ID: <485216F1.1090305@krsek.cz> Hi Sean, from thursday, we have copied some ~300 GB packages from Prague to San Diego (~200 ms delay, 10 GE flat ethernet end machines connected via 1GE) files using RBUDP which worked great. Each scenario needs some planning. You have to answer several questions: 1) What is the performance of storage subsystem (sometimes you need to connect external harddrives or tape robot) 2) How many files you need to transfer? 3) How big are these files? 4) What is the consistency scenarion (it is file consistency or package consistency)? In example, I've sent some film data. Lot (~30.000) of 10 MB DPXes. Consistency was package based. Harddrives have been at the beggining connected via iLink (arrived on this media), then moved to eSATA (went to shop, bought another drive and connected it into export machine). Main tuning for RBUDP has been to buy another harddrive and tar these files. Regards Michal > Hi, > > I'm looking for input on the best practices for sending large files > over a long fat pipe between facilities (gigabit private circuit, > ~20ms RTT). > I'd like to avoid modifying TCP windows and options on end hosts where > possible (I have a lot of them). I've seen products that work as > "transfer stations" using "reliable UDP" to get around the windowing > problem. > > I'm thinking of setting up servers with optimized TCP settings to push > big files around data centers but I'm curious to know how others deal > with LFN+large transfers. > > thanks, > Sean From linford at spamhaus.org Fri Jun 13 03:02:58 2008 From: linford at spamhaus.org (Steve Linford) Date: Fri, 13 Jun 2008 08:02:58 +0000 Subject: Spamhaus down? In-Reply-To: <609B96CBFE9ED64A9346C05705CA495204A7EFA284@MBX02.corp.safesecureweb.com> References: <4850AB10.3060606@gmail.com> <20080612161104.GD7246@cgi.jachomes.com> <485162B2.6040300@wvi.com> <609B96CBFE9ED64A9346C05705CA495204A7EFA284@MBX02.corp.safesecureweb.com> Message-ID: On 12 Jun 2008, at 20:55, Raymond L. Corbin wrote: > Something going on with SpamHaus site/ dnsbl servers? > > > spamhaus.org 1 SOA > server: need.to.know.only 259200s > email: hostmaster at spamhaus.org > serial: 2008060901 > refresh: 3600 > retry: 600 > expire: 2419200 > minimum ttl: 3600 > > spamhaus.org 1 TXT v=spf1 ip4:82.94.216.224/27 - > all 172800s > spamhaus.org 1 NS ns8.spamhaus.org 172800s > spamhaus.org 1 NS ns20.ja.net 172800s > spamhaus.org 1 NS hq-ns.oarc.isc.org 172800s > spamhaus.org 1 NS ns2.spamhaus.org 172800s > spamhaus.org 1 NS ns3.xs4all.nl 172800s > spamhaus.org 1 NS ns3.spamhaus.org 172800s > spamhaus.org 1 MX preference: 10 300s > exchange: smtp-ext- > layer.spamhaus.org > Nothing we're aware of. What in our SOA or NS above are you pointing to as a fault? Steve Linford The Spamhaus Project http://www.spamhaus.org From cidr-report at potaroo.net Fri Jun 13 07:00:04 2008 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 13 Jun 2008 22:00:04 +1000 (EST) Subject: BGP Update Report Message-ID: <200806131200.m5DC04Ia023647@wattle.apnic.net> BGP Update Report Interval: 12-May-08 -to- 12-Jun-08 (32 days) Observation Point: BGP Peering with AS2.0 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS15169 301131 4.1% 2264.1 -- GOOGLE - Google Inc. 2 - AS4538 120238 1.6% 24.3 -- ERX-CERNET-BKB China Education and Research Network Center 3 - AS6140 107484 1.5% 117.1 -- IMPSAT-USA - ImpSat USA, Inc. 4 - AS5691 61721 0.8% 4747.8 -- MITRE-AS-5 - The MITRE Corporation 5 - AS9583 50288 0.7% 41.7 -- SIFY-AS-IN Sify Limited 6 - AS9198 47480 0.7% 102.5 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 7 - AS8866 46639 0.6% 143.9 -- BTC-AS Bulgarian Telecommunication Company Plc. 8 - AS42787 46218 0.6% 15406.0 -- MMIP-AS MultiMedia IP Ltd. 9 - AS17974 46141 0.6% 83.9 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia 10 - AS18231 32261 0.4% 140.3 -- EXATT-AS-AP IOL NETCOM LTD 11 - AS31003 32003 0.4% 4571.9 -- IRON-MOUNTAIN-UK-AS Iron Mountain UK Ltd 12 - AS23966 31340 0.4% 92.4 -- DANCOM-AS-AP LINKdotNET Pakistan 13 - AS9498 31247 0.4% 24.9 -- BBIL-AP BHARTI BT INTERNET LTD. 14 - AS8151 30791 0.4% 24.5 -- Uninet S.A. de C.V. 15 - AS14522 30762 0.4% 161.1 -- Satnet 16 - AS6471 29100 0.4% 69.3 -- ENTEL CHILE S.A. 17 - AS6568 27112 0.4% 222.2 -- Ag para el Desarrollo de la Sociedad de la Inf en Bolivia - ADSIB 18 - AS2386 27064 0.4% 18.3 -- INS-AS - AT&T Data Communications Services 19 - AS15611 26901 0.4% 277.3 -- Iranian Research Organization for Science & Technology 20 - AS702 25577 0.3% 46.8 -- AS702 Verizon Business EMEA - Commercial IP service provider in Europe TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS17834 19963 0.3% 19963.0 -- KYOBOAUTO-AS-KR Kyobo Auto Insurance CO.,LTD 2 - AS42787 46218 0.6% 15406.0 -- MMIP-AS MultiMedia IP Ltd. 3 - AS26829 12652 0.2% 12652.0 -- YKK-USA - YKK USA,INC 4 - AS29910 5176 0.1% 5176.0 -- IACP - INTL. ASSN OF CHIEF OF POLICEI 5 - AS5691 61721 0.8% 4747.8 -- MITRE-AS-5 - The MITRE Corporation 6 - AS31003 32003 0.4% 4571.9 -- IRON-MOUNTAIN-UK-AS Iron Mountain UK Ltd 7 - AS30929 3730 0.1% 3730.0 -- HUTCB Hidrotechnical Faculty - Technical University 8 - AS23082 17974 0.2% 3594.8 -- MPHI - Michigan Public Health Institute 9 - AS39105 3487 0.1% 3487.0 -- CLASS-AS SC Class Computers And Service SRL 10 - AS30287 3343 0.1% 3343.0 -- ALON-USA - ALON USA, LP 11 - AS9988 6591 0.1% 3295.5 -- MPT-AP Myanma Post and Telecommunication 12 - AS38513 3263 0.0% 3263.0 -- LINTASARTA-AS-ID PT Aplikanusa Lintasarta 13 - AS10551 5045 0.1% 2522.5 -- RAPID-CITY-REGIONAL - Rapid City Regional Hospital 14 - AS25250 7425 0.1% 2475.0 -- GAMTEL-AS 15 - AS44730 2289 0.0% 2289.0 -- ALFAGOMMA Alfa Gomma s.p.a. 16 - AS15169 301131 4.1% 2264.1 -- GOOGLE - Google Inc. 17 - AS38069 19663 0.3% 2184.8 -- WARIDTEL-BD-AS-AP Warid Telecom 18 - AS35324 2169 0.0% 2169.0 -- ECH-WILL-AS E.C.H. Will 19 - AS28646 2121 0.0% 2121.0 -- Confederacao Interestadual das Cooperativas Ligadas ao Sicredi 20 - AS47212 23281 0.3% 2116.5 -- UGD-AS University "Goce Delcev" TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 192.12.120.0/24 61365 0.8% AS5691 -- MITRE-AS-5 - The MITRE Corporation 2 - 193.33.184.0/23 46192 0.6% AS42787 -- MMIP-AS MultiMedia IP Ltd. 3 - 213.91.175.0/24 29515 0.4% AS8866 -- BTC-AS Bulgarian Telecommunication Company Plc. 4 - 193.239.114.0/24 27382 0.3% AS31003 -- IRON-MOUNTAIN-UK-AS Iron Mountain UK Ltd 5 - 221.128.192.0/18 27376 0.3% AS18231 -- EXATT-AS-AP IOL NETCOM LTD 6 - 84.23.102.0/24 22223 0.3% AS24731 -- ASN-NESMA National Engineering Services and Marketing Company Ltd. (NESMA) AS34400 -- ASN-ETTIHADETISALAT Etihad Etisalat 7 - 210.92.148.0/24 19963 0.3% AS17834 -- KYOBOAUTO-AS-KR Kyobo Auto Insurance CO.,LTD 8 - 221.135.230.0/23 17866 0.2% AS9583 -- SIFY-AS-IN Sify Limited 9 - 125.23.208.0/20 14147 0.2% AS9498 -- BBIL-AP BHARTI BT INTERNET LTD. 10 - 12.108.254.0/24 12652 0.2% AS26829 -- YKK-USA - YKK USA,INC 11 - 203.63.26.0/24 12471 0.2% AS9747 -- EZINTERNET-AS-AP EZInternet Pty Ltd 12 - 83.228.71.0/24 6920 0.1% AS8866 -- BTC-AS Bulgarian Telecommunication Company Plc. 13 - 193.142.125.0/24 6897 0.1% AS15169 -- GOOGLE - Google Inc. AS41264 -- GOOGLE-CORPNET Google Ireland Limited 14 - 203.81.64.0/19 6583 0.1% AS9988 -- MPT-AP Myanma Post and Telecommunication 15 - 149.117.166.0/24 6277 0.1% AS701 -- UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 16 - 203.101.87.0/24 6261 0.1% AS9498 -- BBIL-AP BHARTI BT INTERNET LTD. 17 - 203.188.220.0/24 6154 0.1% AS9519 -- VERTELNET Vertical Telecoms Pty Ltd 18 - 210.214.88.0/23 6109 0.1% AS9583 -- SIFY-AS-IN Sify Limited 19 - 64.201.128.0/20 6034 0.1% AS11915 -- TELWEST-NETWORK-SVCS-STATIC - TEL WEST COMMUNICATIONS LLC 20 - 208.83.117.0/24 5948 0.1% AS23082 -- MPHI - Michigan Public Health Institute Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at merit.edu eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From cidr-report at potaroo.net Fri Jun 13 07:00:01 2008 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 13 Jun 2008 22:00:01 +1000 (EST) Subject: The Cidr Report Message-ID: <200806131200.m5DC016t023640@wattle.apnic.net> This report has been generated at Fri Jun 13 21:14:59 2008 AEST. The report analyses the BGP Routing Table of AS2.0 router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org for a current version of this report. Recent Table History Date Prefixes CIDR Agg 06-06-08 267006 166019 07-06-08 267476 166188 08-06-08 267317 166689 09-06-08 267436 167035 10-06-08 267350 168058 11-06-08 270376 168607 12-06-08 271136 169355 13-06-08 271485 169850 AS Summary 28610 Number of ASes in routing system 12063 Number of ASes announcing only one prefix 4945 Largest number of prefixes announced by an AS AS4538 : ERX-CERNET-BKB China Education and Research Network Center 88352000 Largest address span announced by an AS (/32s) AS721 : DISA-ASNBLK - DoD Network Information Center Aggregation Summary The algorithm used in this report proposes aggregation only when there is a precise match using the AS path, so as to preserve traffic transit policies. Aggregation is also proposed across non-advertised address space ('holes'). --- 13Jun08 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 271906 169919 101987 37.5% All ASes AS4538 4945 876 4069 82.3% ERX-CERNET-BKB China Education and Research Network Center AS209 3025 667 2358 78.0% ASN-QWEST - Qwest AS6389 2355 546 1809 76.8% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS4755 1645 271 1374 83.5% VSNL-AS Videsh Sanchar Nigam Ltd. Autonomous System AS9498 1182 71 1111 94.0% BBIL-AP BHARTI BT INTERNET LTD. AS18566 1044 41 1003 96.1% COVAD - Covad Communications Co. AS4323 1466 581 885 60.4% TWTC - Time Warner Telecom, Inc. AS22773 957 89 868 90.7% CCINET-2 - Cox Communications Inc. AS11492 1228 480 748 60.9% CABLEONE - CABLE ONE AS17488 1120 381 739 66.0% HATHWAY-NET-AP Hathway IP Over Cable Internet AS8151 1245 537 708 56.9% Uninet S.A. de C.V. AS19262 913 250 663 72.6% VZGNI-TRANSIT - Verizon Internet Services Inc. AS1785 1070 411 659 61.6% AS-PAETEC-NET - PaeTec Communications, Inc. AS18101 692 115 577 83.4% RIL-IDC Reliance Infocom Ltd Internet Data Centre, AS2386 1457 894 563 38.6% INS-AS - AT&T Data Communications Services AS6478 947 402 545 57.6% ATT-INTERNET3 - AT&T WorldNet Services AS4766 878 392 486 55.4% KIXS-AS-KR Korea Telecom AS855 602 124 478 79.4% CANET-ASN-4 - Bell Aliant AS17676 525 80 445 84.8% GIGAINFRA BB TECHNOLOGY Corp. AS19916 640 216 424 66.2% ASTRUM-0001 - OLM LLC AS4134 825 410 415 50.3% CHINANET-BACKBONE No.31,Jin-rong Street AS7029 586 175 411 70.1% WINDSTREAM - Windstream Communications Inc AS22047 566 159 407 71.9% VTR BANDA ANCHA S.A. AS4668 677 273 404 59.7% LGNET-AS-KR LG CNS AS6197 950 547 403 42.4% BATI-ATL - BellSouth Network Solutions, Inc AS9443 483 85 398 82.4% INTERNETPRIMUS-AS-AP Primus Telecommunications AS7018 1396 1001 395 28.3% ATT-INTERNET4 - AT&T WorldNet Services AS3602 456 79 377 82.7% AS3602-RTI - Rogers Telecom Inc. AS4808 525 154 371 70.7% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS7011 1056 685 371 35.1% FRONTIER-AND-CITIZENS - Frontier Communications of America, Inc. Total 35456 10992 24464 69.0% Top 30 total Possible Bogus Routes 24.38.0.0/17 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 24.48.0.0/13 AS19548 ADELPHIA-AS2 - Road Runner HoldCo LLC 24.50.123.0/24 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 24.51.159.0/24 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 24.54.224.0/19 AS20001 ROADRUNNER-WEST - Road Runner HoldCo LLC 24.75.160.0/19 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 24.75.192.0/18 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 24.142.40.0/21 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 24.142.160.0/19 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 24.246.0.0/17 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 24.246.128.0/18 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV - Wireless Broadband via Satellite 63.140.213.0/24 AS22555 UTC - Universal Talkware Corporation 63.141.42.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 63.143.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 63.143.115.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 63.143.251.0/24 AS22555 UTC - Universal Talkware Corporation 63.248.0.0/16 AS3356 LEVEL3 Level 3 Communications 64.7.112.0/21 AS6453 GLOBEINTERNET TATA Communications 64.7.120.0/21 AS6453 GLOBEINTERNET TATA Communications 64.50.128.0/18 AS4565 MEGAPATH2-US - MegaPath Networks Inc. 64.64.159.0/24 AS32004 BIG-ASN - Business Information Group, Inc. 64.144.0.0/15 AS4565 MEGAPATH2-US - MegaPath Networks Inc. 64.188.0.0/16 AS3356 LEVEL3 Level 3 Communications 65.36.8.0/24 AS5696 65.36.9.0/24 AS5696 65.36.33.0/24 AS5696 65.36.52.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 66.11.32.0/20 AS6261 VISINET - Visionary Systems, Inc. 66.11.40.0/21 AS6261 VISINET - Visionary Systems, Inc. 66.54.91.0/24 AS30506 BLACKSUN-1 - Blacksun Technologies LLC 66.55.160.0/19 AS29994 66.64.96.0/20 AS3790 RADIGRAFICA COSTARRICENSE 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.199.32.0/20 AS10397 WISP-AS - Wispnet, LLC 66.206.32.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.33.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.34.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.35.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.40.0/22 AS174 COGENT Cogent/PSI 66.206.44.0/23 AS174 COGENT Cogent/PSI 66.206.47.0/24 AS17557 PKTELECOM-AS-AP Pakistan Telecom 66.207.32.0/20 AS23011 66.219.192.0/18 AS5048 FIBER - FIBERNET Corp. 67.20.0.0/14 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 67.200.0.0/17 AS6517 RELIANCEGLOBALCOM - Reliance Globalcom Services, Inc 68.64.0.0/13 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 68.168.0.0/14 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 68.232.0.0/14 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 69.71.192.0/20 AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport 69.80.0.0/17 AS3043 AMPHIB-AS - Amphibian Media Corporation 69.164.0.0/17 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 70.34.0.0/16 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 80.88.0.0/21 AS33774 DJAWEB 80.88.8.0/22 AS33774 DJAWEB 80.88.10.0/24 AS33774 DJAWEB 80.88.11.0/24 AS33774 DJAWEB 80.88.12.0/24 AS33779 wataniya-telecom-as 91.0.0.0/8 AS47287 STARDOLL Stardoll AB 91.204.112.0/22 AS41129 LOOPBACK-AS Loopback Systems AS 93.191.120.0/21 AS39342 MEDIATRAFFIC Mediatraffic Oy as-number 95.192.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 95.255.248.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 100.100.100.0/24 AS19228 ENTEL CHILE S.A. 111.111.111.0/24 AS19228 ENTEL CHILE S.A. 137.0.0.0/13 AS721 DISA-ASNBLK - DoD Network Information Center 151.135.0.0/16 AS4768 CLIX-NZ TelstraClear Ltd 159.3.211.0/24 AS2687 ASATTCA AT&T Global Network Services - AP 163.142.0.0/16 AS2500 WIDE-BB WIDE Project 166.63.0.0/16 AS33775 NITEL-AS 172.7.0.0/24 AS28175 172.10.1.0/30 AS18305 POSNET POSDATA Co.,Ltd 192.9.200.0/24 AS3602 AS3602-RTI - Rogers Telecom Inc. 192.30.93.0/24 AS17757 HPAUS-AP HP Australia 192.30.94.0/24 AS17757 HPAUS-AP HP Australia 192.40.105.0/24 AS12582 TSF-DATANET-NGD-AS TSF MPLS VPN Services 192.64.85.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.107.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.108.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.177.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.70.164.0/24 AS25689 NRCNET-AS - National Research Council of Canada 192.96.36.0/24 AS5713 SAIX-NET 192.96.37.0/24 AS10474 NETACTIVE 192.96.135.0/24 AS2018 TENET-1 192.96.136.0/23 AS2018 TENET-1 192.96.141.0/24 AS5713 SAIX-NET 192.96.143.0/24 AS2018 TENET-1 192.96.145.0/24 AS2018 TENET-1 192.96.177.0/24 AS6083 POSIX-AFRICA 192.101.45.0/24 AS2905 TICSA-ASN 192.101.46.0/24 AS6503 Avantel, S.A. 192.101.47.0/24 AS6503 Avantel, S.A. 192.101.64.0/21 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.67.0/24 AS21775 192.101.70.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.72.0/24 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.73.0/24 AS4765 WORLDNET-AS World Net & Services Co., Ltd. 192.101.74.0/24 AS1239 SPRINTLINK - Sprint 192.122.212.0/24 AS209 ASN-QWEST - Qwest 192.124.252.0/22 AS680 DFN-IP service G-WiN 192.131.233.0/24 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 192.133.6.0/24 AS10282 EQUANT-CEEUR EQUANT AS for Central and Eastern Europe region 192.153.144.0/21 AS721 DISA-ASNBLK - DoD Network Information Center 192.154.32.0/19 AS81 NCREN - MCNC 192.188.208.0/20 AS721 DISA-ASNBLK - DoD Network Information Center 193.200.114.0/23 AS31530 SERVERCREW-AS Servercrew LTD Autonomes System 194.31.227.0/24 AS21461 TRANSFAIRNET Transfair-net GmbH Krefeld 194.246.72.0/23 AS8893 ARTFILES-AS Artfiles New Media GmbH 195.43.149.0/24 AS8540 HAPPYNET-AS HAPPYnet Dienstleistungs GmbH 196.6.108.0/24 AS5713 SAIX-NET 196.10.119.0/24 AS2018 TENET-1 196.10.122.0/23 AS2018 TENET-1 196.10.251.0/24 AS2018 TENET-1 196.10.252.0/23 AS2018 TENET-1 196.10.254.0/24 AS2018 TENET-1 196.13.101.0/24 AS2018 TENET-1 196.13.102.0/23 AS2018 TENET-1 196.13.104.0/24 AS2018 TENET-1 196.13.121.0/24 AS2018 TENET-1 196.13.125.0/24 AS2018 TENET-1 196.13.126.0/24 AS2018 TENET-1 196.13.169.0/24 AS2018 TENET-1 196.13.174.0/23 AS2018 TENET-1 196.13.176.0/21 AS2018 TENET-1 196.13.192.0/22 AS2018 TENET-1 196.13.196.0/24 AS2018 TENET-1 196.201.98.0/24 AS29571 CITelecom-AS 196.216.132.0/24 AS9207 TAIDE-KE-NAIROBI Taide - Kenya POP 196.216.134.0/24 AS9207 TAIDE-KE-NAIROBI Taide - Kenya POP 198.23.26.0/24 AS4390 BELLATLANTIC-COM - Bell Atlantic, Inc. 198.54.82.0/24 AS2018 TENET-1 198.54.92.0/24 AS2018 TENET-1 198.54.222.0/24 AS2018 TENET-1 198.97.72.0/21 AS721 DISA-ASNBLK - DoD Network Information Center 198.97.80.0/20 AS721 DISA-ASNBLK - DoD Network Information Center 198.97.96.0/19 AS721 DISA-ASNBLK - DoD Network Information Center 198.97.240.0/20 AS721 DISA-ASNBLK - DoD Network Information Center 198.144.96.0/20 AS12185 198.161.87.0/24 AS6539 GT-BELL - Bell Canada 198.167.0.0/16 AS7456 INTERHOP - Interhop Network SERVICES Inc. 198.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 198.169.0.0/16 AS803 SASKTEL - Saskatchewan Telecommunications 198.180.198.0/24 AS23715 SEOUL-INTGW-GXS-AP Global Exchange Services 199.9.128.0/17 AS668 ASN-ASNET-NET-AS - Defense Research and Engineering Network 199.10.0.0/16 AS721 DISA-ASNBLK - DoD Network Information Center 199.114.0.0/21 AS721 DISA-ASNBLK - DoD Network Information Center 199.114.128.0/18 AS721 DISA-ASNBLK - DoD Network Information Center 199.114.130.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.131.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.132.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.134.0/24 AS3541 ITSDN-U4 - DoD Network Information Center 199.114.136.0/24 AS27044 DDN-ASNBLK1 - DoD Network Information Center 199.114.138.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.140.0/24 AS3544 ITSDN-U7 - DoD Network Information Center 199.114.142.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.144.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.148.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.150.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.152.0/24 AS27033 DDN-ASNBLK1 - DoD Network Information Center 199.114.153.0/24 AS27034 DDN-ASNBLK1 - DoD Network Information Center 199.114.154.0/24 AS1733 CENTAF-SWA - AF DDN PMO 199.114.156.0/24 AS1733 CENTAF-SWA - AF DDN PMO 199.114.160.0/24 AS1733 CENTAF-SWA - AF DDN PMO 199.121.0.0/16 AS721 DISA-ASNBLK - DoD Network Information Center 199.123.0.0/18 AS721 DISA-ASNBLK - DoD Network Information Center 199.123.16.0/20 AS721 DISA-ASNBLK - DoD Network Information Center 199.123.80.0/21 AS721 DISA-ASNBLK - DoD Network Information Center 199.189.32.0/19 AS7332 IQUEST-AS - IQuest Internet 199.202.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 199.246.116.0/24 AS813 UUNET-CANADA - MCI Communications Services, Inc. d/b/a Verizon Business 202.58.113.0/24 AS19161 INNOCOM-TELECOM - INNOCOM TELECOM 202.73.144.0/20 AS4788 TMNET-AS-AP TM Net, Internet Service Provider 202.80.192.0/20 AS2706 HKSUPER-HK-AP Pacific Internet (Hong Kong) Limited 202.86.252.0/22 AS4748 RESOLINK-AS-AP Resources Link Network Limited 202.86.252.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.253.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.254.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.255.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.90.33.0/24 AS9830 SWIFTONLINE-AS-AP SWIFT ONLINE BORDER AS 202.90.40.0/24 AS9830 SWIFTONLINE-AS-AP SWIFT ONLINE BORDER AS 202.90.41.0/24 AS9830 SWIFTONLINE-AS-AP SWIFT ONLINE BORDER AS 202.90.42.0/24 AS9830 SWIFTONLINE-AS-AP SWIFT ONLINE BORDER AS 202.90.43.0/24 AS9830 SWIFTONLINE-AS-AP SWIFT ONLINE BORDER AS 202.90.44.0/24 AS9830 SWIFTONLINE-AS-AP SWIFT ONLINE BORDER AS 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.94.70.0/24 AS9837 POWERTEL-AP Powertel Ltd 202.124.195.0/24 AS17557 PKTELECOM-AS-AP Pakistan Telecom 202.124.207.0/24 AS17911 BRAINPK-AS-AP Brain Telecommunication Ltd. 202.136.254.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.136.255.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.164.100.0/24 AS18101 RIL-IDC Reliance Infocom Ltd Internet Data Centre, 202.176.228.0/24 AS17988 SINOSAT-AS-AP SINOSAT (HONG KONG) LIMITED 202.176.232.0/24 AS17988 SINOSAT-AS-AP SINOSAT (HONG KONG) LIMITED 202.181.32.0/24 AS4645 ASN-HKNET-AP HKNet Co. Ltd 203.12.45.0/24 AS4854 NETSPACE-AS-AP Netspace Online Systems 203.62.0.0/17 AS7575 AARNET-AS-AP Australian Academic and Reasearch Network (AARNet) 203.78.48.0/20 AS9299 IPG-AS-AP Philippine Long Distance Telephone Company 203.89.139.0/24 AS17911 BRAINPK-AS-AP Brain Telecommunication Ltd. 203.111.192.0/20 AS7473 SINGTEL-AS-AP Singapore Telecom 203.112.97.0/24 AS9942 COMINDICO-AP SOUL Converged Communications Australia 203.112.111.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.113.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.114.0/24 AS4802 ASN-IINET iiNet Limited 203.112.116.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.117.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.118.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.119.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.120.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.121.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.127.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.128.128.0/19 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 203.128.128.0/24 AS23849 CNNIC-NET263-AP Beijing Capital-online science development Co.,Ltd. 203.152.136.0/23 AS23649 NEWSKIES-AS-AP New Skies Satellites, Hong Kong Teleport 203.152.138.0/23 AS23649 NEWSKIES-AS-AP New Skies Satellites, Hong Kong Teleport 203.152.142.0/24 AS23649 NEWSKIES-AS-AP New Skies Satellites, Hong Kong Teleport 203.152.143.0/24 AS23649 NEWSKIES-AS-AP New Skies Satellites, Hong Kong Teleport 203.160.110.0/23 AS7643 VNN-AS-AP Vietnam Posts and Telecommunications (VNPT) 204.9.216.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.9.217.0/24 AS4323 TWTC - Time Warner Telecom, Inc. 204.9.218.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.13.140.0/22 AS7270 NET2PHONE - Net2Phone Corp. 204.16.120.0/23 AS12077 204.16.122.0/23 AS12077 204.19.14.0/23 AS577 BACOM - Bell Canada 204.29.196.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 204.29.197.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 204.48.58.0/24 AS4323 TWTC - Time Warner Telecom, Inc. 204.48.60.0/24 AS4323 TWTC - Time Warner Telecom, Inc. 204.154.125.0/24 AS3952 TELLABS-ASN - TELLABS Operations, Inc. 204.154.126.0/24 AS3952 TELLABS-ASN - TELLABS Operations, Inc. 204.154.127.0/24 AS3952 TELLABS-ASN - TELLABS Operations, Inc. 205.150.0.0/15 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 206.162.224.0/19 AS23464 ILCSNET - Interlink Computer Services 206.180.240.0/20 AS12083 KNOLOGY-NET - Knology Holdings 206.220.240.0/24 AS10764 STARTAP - National Center for Supercomputing Applications 206.220.240.64/26 AS22335 MREN - Metropolitan Research and Education Network 206.220.240.128/25 AS10764 STARTAP - National Center for Supercomputing Applications 206.220.240.160/30 AS10764 STARTAP - National Center for Supercomputing Applications 206.220.240.220/32 AS10764 STARTAP - National Center for Supercomputing Applications 206.220.241.0/24 AS10764 STARTAP - National Center for Supercomputing Applications 207.98.192.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 207.98.209.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 207.98.223.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 207.191.128.0/19 AS10887 BPSI-AS - BPSI Internet Services 207.204.168.0/24 AS15150 BELLTECH-AS - BELLWETHER TECHNOLOGY CORPORATION 207.204.222.0/24 AS22773 CCINET-2 - Cox Communications Inc. 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc. 208.38.192.0/18 AS3043 AMPHIB-AS - Amphibian Media Corporation 208.38.192.0/21 AS14237 BEAMSPEED1 - Beamspeed 208.38.202.0/24 AS14237 BEAMSPEED1 - Beamspeed 208.38.203.0/24 AS14237 BEAMSPEED1 - Beamspeed 208.38.204.0/22 AS14237 BEAMSPEED1 - Beamspeed 209.54.93.0/24 AS22773 CCINET-2 - Cox Communications Inc. 209.54.111.0/24 AS22773 CCINET-2 - Cox Communications Inc. 209.54.123.0/24 AS6062 NETPLEX - NETPLEX 209.54.240.0/21 AS10887 BPSI-AS - BPSI Internet Services 209.105.224.0/19 AS20074 209.140.90.0/24 AS14461 NTSL - NET SOLUTIONS 209.140.224.0/21 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.234.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.235.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.236.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.237.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.238.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.239.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.141.16.0/21 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.141.48.0/22 AS14461 NTSL - NET SOLUTIONS 209.145.192.0/18 AS3043 AMPHIB-AS - Amphibian Media Corporation 209.145.204.0/22 AS14237 BEAMSPEED1 - Beamspeed 210.5.128.0/20 AS4837 CHINA169-BACKBONE CNCGROUP China169 Backbone 213.150.192.0/21 AS29571 CITelecom-AS 213.150.200.0/22 AS29571 CITelecom-AS 213.150.201.0/24 AS29338 AFOL-AS Used by Africaonline Operations 213.150.202.0/24 AS41042 SKYVISION SkyVision Network Services 213.172.144.0/22 AS17175 NSS-UK New Skies Satellites UK AS 216.37.114.0/23 AS3549 GBLX Global Crossing Ltd. 216.37.120.0/23 AS13377 216.59.0.0/17 AS3356 LEVEL3 Level 3 Communications 216.99.16.0/24 AS6395 LVLT-6395 - Level 3 Communications, Inc. 216.99.20.0/24 AS6395 LVLT-6395 - Level 3 Communications, Inc. 216.162.96.0/19 AS7393 CYBERCON - CYBERCON, INC. 216.172.198.0/24 AS22773 CCINET-2 - Cox Communications Inc. 216.172.199.0/24 AS22773 CCINET-2 - Cox Communications Inc. 216.210.86.0/24 AS577 BACOM - Bell Canada 216.235.96.0/19 AS13645 BROADBANDONE - BroadbandONE, Inc. 216.240.240.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 216.240.241.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 216.240.242.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 216.251.207.0/24 AS1239 SPRINTLINK - Sprint 217.78.71.0/24 AS12491 IPPLANET-AS IPPlanet 217.78.72.0/24 AS12491 IPPLANET-AS IPPlanet 217.78.73.0/24 AS12491 IPPLANET-AS IPPlanet Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at merit.edu eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From black at csulb.edu Fri Jun 13 09:35:33 2008 From: black at csulb.edu (Matthew Black) Date: Fri, 13 Jun 2008 07:35:33 -0700 Subject: Spamhaus down? In-Reply-To: References: <4850AB10.3060606@gmail.com> <20080612161104.GD7246@cgi.jachomes.com> <485162B2.6040300@wvi.com> <609B96CBFE9ED64A9346C05705CA495204A7EFA284@MBX02.corp.safesecureweb.com> Message-ID: On Fri, 13 Jun 2008 08:02:58 +0000 Steve Linford wrote: > On 12 Jun 2008, at 20:55, Raymond L. Corbin wrote: > >> Something going on with SpamHaus site/ dnsbl servers? We get a spamhaus data feed of PBL, SBL, and XBL and have not seen any problems recently. matthew black california state university, long beach From joe_hznm at yahoo.com.sg Fri Jun 13 10:03:23 2008 From: joe_hznm at yahoo.com.sg (Joe Shen) Date: Fri, 13 Jun 2008 23:03:23 +0800 (SGT) Subject: BRAS Configuration backup and trace feature segment changes Message-ID: <811455.55034.qm@web76305.mail.sg1.yahoo.com> hi, I'm looking for tools which could backup BRAS and router configuration automatically, while monitoring special configuration changes. RANCID seems to be able to backup whold configuration, but it seems it could not monitor special feature configuration segment changes ( e.g. changes on OSPF configuraion or drop code mapping configration). Is there any tools to do this ? thanks in advance. Joe Yahoo! Toolbar is now powered with Search Assist.Download it now! http://sg.toolbar.yahoo.com/ From linford at spamhaus.org Fri Jun 13 10:10:11 2008 From: linford at spamhaus.org (Steve Linford) Date: Fri, 13 Jun 2008 15:10:11 +0000 Subject: Spamhaus down? In-Reply-To: References: <4850AB10.3060606@gmail.com> <20080612161104.GD7246@cgi.jachomes.com> <485162B2.6040300@wvi.com> <609B96CBFE9ED64A9346C05705CA495204A7EFA284@MBX02.corp.safesecureweb.com> Message-ID: On 13 Jun 2008, at 16:35, Matthew Black wrote: > On Fri, 13 Jun 2008 08:02:58 +0000 > Steve Linford wrote: >> On 12 Jun 2008, at 20:55, Raymond L. Corbin wrote: >>> Something going on with SpamHaus site/ dnsbl servers? > > > We get a spamhaus data feed of PBL, SBL, and XBL > and have not seen any problems recently. > > matthew black > california state university, long beach He sent more info, the 'problem' is he's not getting an A record when looking up our zones, such as zen.spamhaus.org. I've fired back the usual canned response which says "our dns zones don't have A records because... they are dns zones, not hosts" ;) Steve Linford The Spamhaus Project http://www.spamhaus.org From pstewart at nexicomgroup.net Fri Jun 13 10:20:27 2008 From: pstewart at nexicomgroup.net (Paul Stewart) Date: Fri, 13 Jun 2008 11:20:27 -0400 Subject: BRAS Configuration backup and trace feature segment changes In-Reply-To: <811455.55034.qm@web76305.mail.sg1.yahoo.com> References: <811455.55034.qm@web76305.mail.sg1.yahoo.com> Message-ID: <89D27DE3375BB6428DDCC2927489826A01589861@nexus.nexicomgroup.net> We're using Cirrus from Solarwinds for this.... works pretty good (at least since they brough out the latest patch a few months ago).... It does full config backup but will only backup changed configs - also sends a daily email to us with any changes made to routers etc.... also daily report (if you want) on current IOS version etc. etc... Overall, happy with it - to the point we use it to script some automated IOS upgrades too... Paul -----Original Message----- From: Joe Shen [mailto:joe_hznm at yahoo.com.sg] Sent: Friday, June 13, 2008 11:03 AM To: NANGO Subject: BRAS Configuration backup and trace feature segment changes hi, I'm looking for tools which could backup BRAS and router configuration automatically, while monitoring special configuration changes. RANCID seems to be able to backup whold configuration, but it seems it could not monitor special feature configuration segment changes ( e.g. changes on OSPF configuraion or drop code mapping configration). Is there any tools to do this ? thanks in advance. Joe Yahoo! Toolbar is now powered with Search Assist.Download it now! http://sg.toolbar.yahoo.com/ ---------------------------------------------------------------------------- "The information transmitted is intended only for the person or entity to which it is addressed and contains confidential and/or privileged material. If you received this in error, please contact the sender immediately and then destroy this transmission, including all attachments, without copying, distributing or disclosing same. Thank you." From rs at seastrom.com Fri Jun 13 10:41:00 2008 From: rs at seastrom.com (Robert E. Seastrom) Date: Fri, 13 Jun 2008 11:41:00 -0400 Subject: Best utilizing fat long pipes and large file transfer In-Reply-To: <20080613023446.9CF254500E@ptavv.es.net> (Kevin Oberman's message of "Thu, 12 Jun 2008 19:34:46 -0700") References: <20080613023446.9CF254500E@ptavv.es.net> Message-ID: <86ej71gx6b.fsf@seastrom.com> "Kevin Oberman" writes: >> From: "Robert E. Seastrom" >> Date: Thu, 12 Jun 2008 21:15:49 -0400 >> >> >> Randy Bush writes: >> >> > and for those of us who are addicted to simple rsync, or whatever over >> > ssh, you should be aware of the really bad openssh windowing issue. >> >> As a user of hpn-ssh for years, I have to wonder if there is any >> reason (aside from the sheer cussedness for which Theo is infamous) >> that the window improvements at least from hpn-ssh haven't been >> backported into mainline openssh? I suppose there might be >> portability concerns with the multithreaded ciphers, and there's >> certainly a good argument for not supporting NONE as a cipher type out >> of the box without a recompile, but there's not much excuse for the >> fixed size tiny buffers - I mean, it's 2008 already... > > Theo is known for his amazing stubbornness, but for area involving > security and cryptography, I find it hard to say that his conservatism > is excessive. Crypto is hard and often it is very non-intuitive. I > remember the long discussions on entropy harvesting and seeding in > FreeBSD which fortunately has cryptography professionals who could pick > every nit and make sure FreeBSD did not end up with Debian-type egg all > over its virtual face. > > Than again, the tiny buffers are silly and I can't imagine any possible > security issue there. Many good reasons to not goof with the crypto. The window size was the main thing I was poking at. ---rob From oberman at es.net Fri Jun 13 11:01:12 2008 From: oberman at es.net (Kevin Oberman) Date: Fri, 13 Jun 2008 09:01:12 -0700 Subject: Best utilizing fat long pipes and large file transfer In-Reply-To: Your message of "Thu, 12 Jun 2008 19:26:56 EDT." <1213313218_50122@mail1.tellurian.net> Message-ID: <20080613160112.9F8B545047@ptavv.es.net> > Date: Thu, 12 Jun 2008 19:26:56 -0400 > From: Robert Boyle > > At 06:37 PM 6/12/2008, you wrote: > >I'm looking for input on the best practices for sending large files > >over a long fat pipe between facilities (gigabit private circuit, ~20ms RTT). > >I'd like to avoid modifying TCP windows and options on end hosts > >where possible (I have a lot of them). I've seen products that work > >as "transfer stations" using "reliable UDP" to get around the > >windowing problem. > > > >I'm thinking of setting up servers with optimized TCP settings to > >push big files around data centers but I'm curious to know how > >others deal with LFN+large transfers. > > In our experience, you can't get to line speed with over 20-30ms of > latency using TCP regardless of how much you tweak it. We transfer > files across the US with 60-70ms at line speeds with UDP based file > transfer programs. There are a number of open source projects out > there designed for this purpose. Clearly you have failed to try very hard or to check into what others have done. We routinely move data at MUCH higher rates over TCP at latencies over 50 ms. one way (>100 ms. RTT). We find it fairly easy to move data at over 4 Gbps continuously. If you can't fill a GE to 80% (800 Mbps) at 30 ms, you really are not tying very hard. Note: I am talking about a single TCP stream running for over 5 minutes at a time on tuned systems. Tuning for most modern network stacks is pretty trivial. Some older stacks (e.g. FreeBSD V6) are hopeless. I can't speak to how Windows does as I make no use of it for high-speed bulk transfers. It's also fairly easy to run multiple parallel TCP streams to completely fill a 10 Gbps pipe at any distance. This is the preferred method for moving large volumes of data around the world in the R&E community as it requires little or no system tuning and is available in several open-source tools. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman at es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 224 bytes Desc: not available URL: From jon at defenderhosting.com Fri Jun 13 11:18:27 2008 From: jon at defenderhosting.com (Jon Wolberg) Date: Fri, 13 Jun 2008 12:18:27 -0400 (EDT) Subject: BRAS Configuration backup and trace feature segment changes In-Reply-To: <89D27DE3375BB6428DDCC2927489826A01589861@nexus.nexicomgroup.net> Message-ID: <194195956.155441213373907611.JavaMail.root@mail.dtgmail.com> Using Hyperconf by WinAgents here, pretty satisfied with it as well. Multi vendor support, changed configs or full backups, highly configurable. Jon ----- Original Message ----- From: "Paul Stewart" To: "joe hznm" , "NANGO" Sent: Friday, June 13, 2008 11:20:27 AM GMT -05:00 US/Canada Eastern Subject: RE: BRAS Configuration backup and trace feature segment changes We're using Cirrus from Solarwinds for this.... works pretty good (at least since they brough out the latest patch a few months ago).... It does full config backup but will only backup changed configs - also sends a daily email to us with any changes made to routers etc.... also daily report (if you want) on current IOS version etc. etc... Overall, happy with it - to the point we use it to script some automated IOS upgrades too... Paul -----Original Message----- From: Joe Shen [mailto:joe_hznm at yahoo.com.sg] Sent: Friday, June 13, 2008 11:03 AM To: NANGO Subject: BRAS Configuration backup and trace feature segment changes hi, I'm looking for tools which could backup BRAS and router configuration automatically, while monitoring special configuration changes. RANCID seems to be able to backup whold configuration, but it seems it could not monitor special feature configuration segment changes ( e.g. changes on OSPF configuraion or drop code mapping configration). Is there any tools to do this ? thanks in advance. Joe Yahoo! Toolbar is now powered with Search Assist.Download it now! http://sg.toolbar.yahoo.com/ ---------------------------------------------------------------------------- "The information transmitted is intended only for the person or entity to which it is addressed and contains confidential and/or privileged material. If you received this in error, please contact the sender immediately and then destroy this transmission, including all attachments, without copying, distributing or disclosing same. Thank you." From robert at tellurian.com Fri Jun 13 11:40:48 2008 From: robert at tellurian.com (Robert Boyle) Date: Fri, 13 Jun 2008 12:40:48 -0400 Subject: Best utilizing fat long pipes and large file transfer In-Reply-To: <20080613160112.9F8B545047@ptavv.es.net> References: <20080613160112.9F8B545047@ptavv.es.net> Message-ID: <1213375252_14636@mail1.tellurian.net> At 12:01 PM 6/13/2008, Kevin Oberman wrote: >Clearly you have failed to try very hard or to check into what others >have done. We routinely move data at MUCH higher rates over TCP at >latencies over 50 ms. one way (>100 ms. RTT). We find it fairly easy to >move data at over 4 Gbps continuously. That's impressive. >If you can't fill a GE to 80% (800 Mbps) at 30 ms, you really are not >tying very hard. Note: I am talking about a single TCP stream running >for over 5 minutes at a time on tuned systems. Tuning for most modern >network stacks is pretty trivial. Some older stacks (e.g. FreeBSD V6) >are hopeless. I can't speak to how Windows does as I make no use of it >for high-speed bulk transfers. Let me refine my post then... In our experience, you can't get to line speed with over 20-30ms of latency using TCP on _Windows_ regardless of how much you tweak it. >99% of the servers in our facilities are Windows based. I should have been more specific. -Robert Tellurian Networks - Global Hosting Solutions Since 1995 http://www.tellurian.com | 888-TELLURIAN | 973-300-9211 "Well done is better than well said." - Benjamin Franklin From deepak at ai.net Fri Jun 13 12:37:39 2008 From: deepak at ai.net (Deepak Jain) Date: Fri, 13 Jun 2008 13:37:39 -0400 Subject: Best utilizing fat long pipes and large file transfer In-Reply-To: <1213375252_14636@mail1.tellurian.net> References: <20080613160112.9F8B545047@ptavv.es.net> <1213375252_14636@mail1.tellurian.net> Message-ID: <4852B063.2060405@ai.net> Robert Boyle wrote: > At 12:01 PM 6/13/2008, Kevin Oberman wrote: >> Clearly you have failed to try very hard or to check into what others >> have done. We routinely move data at MUCH higher rates over TCP at >> latencies over 50 ms. one way (>100 ms. RTT). We find it fairly easy to >> move data at over 4 Gbps continuously. > > That's impressive. > >> If you can't fill a GE to 80% (800 Mbps) at 30 ms, you really are not >> tying very hard. Note: I am talking about a single TCP stream running >> for over 5 minutes at a time on tuned systems. Tuning for most modern >> network stacks is pretty trivial. Some older stacks (e.g. FreeBSD V6) >> are hopeless. I can't speak to how Windows does as I make no use of it >> for high-speed bulk transfers. > > Let me refine my post then... > In our experience, you can't get to line speed with over 20-30ms of > latency using TCP on _Windows_ regardless of how much you tweak it. >99% > of the servers in our facilities are Windows based. I should have been > more specific. > I'll stipulate that I haven't looked too deeply into this problem for Windows systems. But I can't imagine it would be too hard to put a firewall/proxy (think Socks) and set the FW/proxy to adjust (or use an always on, tuned, tunnel) the TCP settings between the two FW/proxies on either side of the link. It has reasonably little invasion or reconfiguration and is probably reasonably solid. DJ From sean at craigslist.org Fri Jun 13 12:43:23 2008 From: sean at craigslist.org (Sean Knox) Date: Fri, 13 Jun 2008 10:43:23 -0700 Subject: Best utilizing fat long pipes and large file transfer In-Reply-To: <4851A53B.4010400@craigslist.org> References: <4851A53B.4010400@craigslist.org> Message-ID: <4852B1BB.6030903@craigslist.org> Many thanks for great replies on and off-list. The suggestions basically ranged from these options: 1. tune TCP on all hosts you wish to transfer between 2. create tuned TCP proxies and transfer through those hosts 3. setup a socat (netcat++) proxy and send through this host 4. use an alternative to plain netcat/scp for large file transfers My needs are pretty simple: occasionally I need to push large database files (300Gb+) around linux hosts. #4 seems like the best option for me. People suggested a slew of methods to do this: RBUDP, gridftp, bbcp, and many others, with programs either sending with reliable UDP or breaking large transfers into multiple streams. Because it was easy to use right away, I tried RBUDP and was able to copy a tarball at about 700Mb/s over a 20ms delay link, and when factoring in destination disk write speed, isn't too bad a starting point. GridFTP and bbcp look very useful too; I'll be exploring them as well. The presentation links Kevin O. sent were very interesting. I've looked at HPN-SSH before but haven't played with it much. I'll definitely try it out based on the feedback from this thread. Thanks again. sk Sean Knox wrote: > Hi, > > I'm looking for input on the best practices for sending large files over > a long fat pipe between facilities (gigabit private circuit, ~20ms RTT). > I'd like to avoid modifying TCP windows and options on end hosts where > possible (I have a lot of them). I've seen products that work as > "transfer stations" using "reliable UDP" to get around the windowing > problem. > > I'm thinking of setting up servers with optimized TCP settings to push > big files around data centers but I'm curious to know how others deal > with LFN+large transfers. > > thanks, > Sean From goemon at anime.net Fri Jun 13 13:07:08 2008 From: goemon at anime.net (goemon at anime.net) Date: Fri, 13 Jun 2008 11:07:08 -0700 (PDT) Subject: Best utilizing fat long pipes and large file transfer In-Reply-To: <1213375252_14636@mail1.tellurian.net> References: <20080613160112.9F8B545047@ptavv.es.net> <1213375252_14636@mail1.tellurian.net> Message-ID: On Fri, 13 Jun 2008, Robert Boyle wrote: > Let me refine my post then... > In our experience, you can't get to line speed with over 20-30ms of latency > using TCP on _Windows_ regardless of how much you tweak it. >99% of the > servers in our facilities are Windows based. I should have been more > specific. Its actually not that hard on windows. -Dan From cscora at apnic.net Fri Jun 13 13:08:03 2008 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 14 Jun 2008 04:08:03 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <200806131808.m5DI83YH004907@thyme.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 14 Jun, 2008 Report Website: http://thyme.apnic.net Detailed Analysis: http://thyme.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 259901 Prefixes after maximum aggregation: 128080 Deaggregation factor: 2.03 Unique aggregates announced to Internet: 126786 Total ASes present in the Internet Routing Table: 28442 Prefixes per ASN: 9.14 Origin-only ASes present in the Internet Routing Table: 24790 Origin ASes announcing only one prefix: 11978 Transit ASes present in the Internet Routing Table: 3652 Transit-only ASes present in the Internet Routing Table: 78 Average AS path length visible in the Internet Routing Table: 3.6 Max AS path length visible: 18 Max AS path prepend of ASN (43380) 13 Prefixes from unregistered ASNs in the Routing Table: 623 Unregistered ASNs in the Routing Table: 229 Number of 32-bit ASNs allocated by the RIRs: 48 Prefixes from 32-bit ASNs in the Routing Table: 8 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 780 Number of addresses announced to Internet: 1858706912 Equivalent to 110 /8s, 201 /16s and 157 /24s Percentage of available address space announced: 50.1 Percentage of allocated address space announced: 60.9 Percentage of available address space allocated: 82.3 Percentage of address space in use by end-sites: 72.2 Total number of prefixes smaller than registry allocations: 126226 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 59132 Total APNIC prefixes after maximum aggregation: 22129 APNIC Deaggregation factor: 2.67 Prefixes being announced from the APNIC address blocks: 56160 Unique aggregates announced from the APNIC address blocks: 25128 APNIC Region origin ASes present in the Internet Routing Table: 3275 APNIC Prefixes per ASN: 17.15 APNIC Region origin ASes announcing only one prefix: 869 APNIC Region transit ASes present in the Internet Routing Table: 508 Average APNIC Region AS path length visible: 3.5 Max APNIC Region AS path length visible: 17 Number of APNIC addresses announced to Internet: 352137632 Equivalent to 20 /8s, 253 /16s and 49 /24s Percentage of available APNIC address space announced: 75.0 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079 APNIC Address Blocks 58/8, 59/8, 60/8, 61/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 120109 Total ARIN prefixes after maximum aggregation: 65072 ARIN Deaggregation factor: 1.85 Prefixes being announced from the ARIN address blocks: 89906 Unique aggregates announced from the ARIN address blocks: 34679 ARIN Region origin ASes present in the Internet Routing Table: 12213 ARIN Prefixes per ASN: 7.36 ARIN Region origin ASes announcing only one prefix: 4736 ARIN Region transit ASes present in the Internet Routing Table: 1147 Average ARIN Region AS path length visible: 3.3 Max ARIN Region AS path length visible: 15 Number of ARIN addresses announced to Internet: 356411552 Equivalent to 21 /8s, 62 /16s and 104 /24s Percentage of available ARIN address space announced: 73.3 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 ARIN Address Blocks 24/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 173/8, 174/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 55926 Total RIPE prefixes after maximum aggregation: 34008 RIPE Deaggregation factor: 1.64 Prefixes being announced from the RIPE address blocks: 51103 Unique aggregates announced from the RIPE address blocks: 34277 RIPE Region origin ASes present in the Internet Routing Table: 11456 RIPE Prefixes per ASN: 4.46 RIPE Region origin ASes announcing only one prefix: 5988 RIPE Region transit ASes present in the Internet Routing Table: 1725 Average RIPE Region AS path length visible: 4.0 Max RIPE Region AS path length visible: 18 Number of RIPE addresses announced to Internet: 360988032 Equivalent to 21 /8s, 132 /16s and 61 /24s Percentage of available RIPE address space announced: 82.8 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-48127 RIPE Address Blocks 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 20218 Total LACNIC prefixes after maximum aggregation: 5155 LACNIC Deaggregation factor: 3.92 Prefixes being announced from the LACNIC address blocks: 18456 Unique aggregates announced from the LACNIC address blocks: 10363 LACNIC Region origin ASes present in the Internet Routing Table: 954 LACNIC Prefixes per ASN: 19.35 LACNIC Region origin ASes announcing only one prefix: 305 LACNIC Region transit ASes present in the Internet Routing Table: 160 Average LACNIC Region AS path length visible: 4.1 Max LACNIC Region AS path length visible: 15 Number of LACNIC addresses announced to Internet: 52287232 Equivalent to 3 /8s, 29 /16s and 215 /24s Percentage of available LACNIC address space announced: 51.9 LACNIC AS Blocks 26592-26623, 27648-28671, plus ERX transfers LACNIC Address Blocks 186/8, 187/8, 189/8, 190/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 3895 Total AfriNIC prefixes after maximum aggregation: 1200 AfriNIC Deaggregation factor: 3.25 Prefixes being announced from the AfriNIC address blocks: 4168 Unique aggregates announced from the AfriNIC address blocks: 1875 AfriNIC Region origin ASes present in the Internet Routing Table: 243 AfriNIC Prefixes per ASN: 17.15 AfriNIC Region origin ASes announcing only one prefix: 80 AfriNIC Region transit ASes present in the Internet Routing Table: 47 Average AfriNIC Region AS path length visible: 3.9 Max AfriNIC Region AS path length visible: 14 Number of AfriNIC addresses announced to Internet: 12316160 Equivalent to 0 /8s, 187 /16s and 238 /24s Percentage of available AfriNIC address space announced: 36.7 AfriNIC AS Blocks 36864-37887 & ERX transfers AfriNIC Address Blocks 41/8, 196/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4755 1618 387 89 Videsh Sanchar Nigam Ltd. Aut 9498 1181 550 62 BHARTI BT INTERNET LTD. 17488 1120 78 76 Hathway IP Over Cable Interne 9583 1116 110 450 Sify Limited 4766 850 6006 343 Korea Telecom (KIX) 4134 824 12915 321 CHINANET-BACKBONE 23577 820 34 702 Korea Telecom (ATM-MPLS) 18101 693 167 36 Reliance Infocom Ltd Internet 9829 598 450 12 BSNL National Internet Backbo 1221 550 1919 423 Telstra Pty Ltd Complete listing at http://thyme.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 209 3009 3874 620 Qwest 6389 2355 3138 188 bellsouth.net, inc. 4323 1469 1045 378 Time Warner Telecom 2386 1453 660 875 AT&T Data Communications Serv 7018 1370 5810 980 AT&T WorldNet Services 11492 1228 148 12 Cable One 1785 1066 510 105 AppliedTheory Corporation 18566 1044 296 10 Covad Communications 20115 1040 1062 564 Charter Communications 7011 1034 289 569 Citizens Utilities Complete listing at http://thyme.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 3292 412 1772 371 TDC Tele Danmark 8452 347 188 7 TEDATA 3301 338 1460 308 TeliaNet Sweden 8866 319 77 21 Bulgarian Telecommunication C 3320 315 7045 265 Deutsche Telekom AG 3215 285 2742 89 France Telecom Transpac 8551 283 269 38 Bezeq International 5462 275 666 27 Telewest Broadband 680 274 2047 264 DFN-IP service G-WiN 9155 268 45 10 QualityNet AS number Complete listing at http://thyme.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8151 1245 2464 227 UniNet S.A. de C.V. 11830 603 299 9 Instituto Costarricense de El 22047 566 270 14 VTR PUNTO NET S.A. 7303 468 229 66 Telecom Argentina Stet-France 16814 426 27 10 NSS, S.A. 6471 413 85 46 ENTEL CHILE S.A. 11172 411 118 69 Servicios Alestra S.A de C.V 10620 392 100 71 TVCABLE BOGOTA 14117 375 23 9 Telefonica del Sur S.A. 20299 340 24 92 NEWCOM AMERICAS Complete listing at http://thyme.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 24863 475 61 30 LINKdotNET AS number 3741 282 853 223 The Internet Solution 20858 220 34 3 EgyNet 2018 192 189 82 Tertiary Education Network 5713 163 558 99 Telkom SA Ltd 6713 143 135 11 Itissalat Al-MAGHRIB 33783 134 10 12 EEPAD TISP TELECOM & INTERNET 5536 121 8 16 Internet Egypt Network 29571 103 13 8 Ci Telecom Autonomous system 33776 100 6 3 Starcomms Nigeria Limited Complete listing at http://thyme.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 209 3009 3874 620 Qwest 6389 2355 3138 188 bellsouth.net, inc. 4755 1618 387 89 Videsh Sanchar Nigam Ltd. Aut 4323 1469 1045 378 Time Warner Telecom 2386 1453 660 875 AT&T Data Communications Serv 7018 1370 5810 980 AT&T WorldNet Services 8151 1245 2464 227 UniNet S.A. de C.V. 11492 1228 148 12 Cable One 9498 1181 550 62 BHARTI BT INTERNET LTD. 17488 1120 78 76 Hathway IP Over Cable Interne Complete listing at http://thyme.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 6389 2355 2167 bellsouth.net, inc. 4755 1618 1529 Videsh Sanchar Nigam Ltd. Aut 11492 1228 1216 Cable One 9498 1181 1119 BHARTI BT INTERNET LTD. 4323 1469 1091 Time Warner Telecom 17488 1120 1044 Hathway IP Over Cable Interne 18566 1044 1034 Covad Communications 8151 1245 1018 UniNet S.A. de C.V. 1785 1066 961 AppliedTheory Corporation 22773 957 895 Cox Communications, Inc. Complete listing at http://thyme.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 16927 UNALLOCATED 12.0.252.0/23 701 UUNET Technologies, 22492 UNALLOCATED 12.2.46.0/24 7018 AT&T WorldNet Servic 15132 UNALLOCATED 12.9.150.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.14.170.0/24 7018 AT&T WorldNet Servic 13632 UNALLOCATED 12.20.55.0/24 6517 Yipes Communications 13746 UNALLOCATED 12.24.56.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.25.107.0/24 7018 AT&T WorldNet Servic 13632 UNALLOCATED 12.31.25.0/24 6517 Yipes Communications 27220 UNALLOCATED 12.35.204.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.152.0/24 7018 AT&T WorldNet Servic Complete listing at http://thyme.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 24.51.159.0/24 7843 Adelphia Corp. 24.54.224.0/19 20001 HoldCo LLC - Road Runner 24.75.160.0/19 7843 Adelphia Corp. 24.75.192.0/18 7843 Adelphia Corp. 24.142.40.0/21 7018 AT&T WorldNet Services 24.142.160.0/19 7018 AT&T WorldNet Services 24.246.0.0/17 7018 AT&T WorldNet Services 24.246.128.0/18 7018 AT&T WorldNet Services 62.61.220.0/24 24974 Tachyon Europe BV - Wireless 63.140.213.0/24 22555 Universal Talkware Corporatio Complete listing at http://thyme.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:18 /9:9 /10:16 /11:42 /12:142 /13:279 /14:514 /15:1028 /16:9958 /17:4337 /18:7359 /19:15676 /20:18305 /21:17924 /22:22319 /23:23253 /24:135965 /25:841 /26:1035 /27:782 /28:81 /29:10 /30:1 /31:0 /32:7 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 209 1764 3009 Qwest 6389 1452 2355 bellsouth.net, inc. 11492 1210 1228 Cable One 2386 1150 1453 AT&T Data Communications Serv 18566 1025 1044 Covad Communications 4755 973 1618 Videsh Sanchar Nigam Ltd. Aut 9583 971 1116 Sify Limited 6298 946 961 Cox Communicatons 6478 941 942 AT&T Worldnet Services 17488 932 1120 Hathway IP Over Cable Interne Complete listing at http://thyme.apnic.net/current/data/sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 4:9 8:114 12:2049 13:1 15:22 16:3 17:5 18:13 20:35 24:1075 25:1 32:61 33:3 38:440 40:92 41:645 43:1 44:2 47:12 52:3 55:4 56:3 57:23 58:458 59:475 60:443 61:991 62:1100 63:2030 64:3275 65:2419 66:3636 67:1211 68:695 69:2273 70:679 71:126 72:1815 73:5 74:1002 75:220 76:299 77:727 78:706 79:194 80:914 81:849 82:563 83:392 84:565 85:1011 86:422 87:694 88:313 89:1257 90:12 91:1267 92:186 93:574 94:16 96:34 97:23 98:200 99:3 100:1 111:1 112:1 113:1 114:34 116:695 117:326 118:143 119:460 120:59 121:525 122:781 123:346 124:850 125:1137 128:331 129:204 130:130 131:401 132:67 133:9 134:177 135:33 136:218 137:91 138:151 139:78 140:498 141:99 142:403 143:335 144:356 145:51 146:363 147:154 148:505 149:191 150:130 151:193 152:143 153:136 154:10 155:273 156:174 157:273 158:168 159:239 160:266 161:105 162:232 163:184 164:530 165:447 166:316 167:328 168:615 169:138 170:429 171:29 172:10 189:196 190:2103 192:5792 193:4094 194:3200 195:2488 196:1065 198:3740 199:3273 200:5541 201:1441 202:7631 203:7925 204:3986 205:2122 206:2412 207:2795 208:3365 209:3477 210:2520 211:1018 212:1399 213:1662 214:163 215:48 216:4426 217:1196 218:348 219:416 220:1083 221:469 222:308 End of report From mprice at tqhosting.com Fri Jun 13 13:11:11 2008 From: mprice at tqhosting.com (Mark Price) Date: Fri, 13 Jun 2008 14:11:11 -0400 Subject: DNS problems to RoadRunner - tcp vs udp Message-ID: <61b6fbec0806131111u77606e1bu90bcd102c3217fb4@mail.gmail.com> I have seen intermittent problems on some client windows servers sending to rr.com recently. For example, the MX hosts for triad.rr.com are: # dig -t mx triad.rr.com ;; QUESTION SECTION: ;triad.rr.com. IN MX ;; ANSWER SECTION: triad.rr.com. 1609 IN MX 10 hrndva-smtpin01.mail.rr.com. triad.rr.com. 1609 IN MX 20 hrndva-smtpin02.mail.rr.com. The authoritative nameservers for mail.rr.com: # dig -t ns mail.rr.com ;; QUESTION SECTION: ;mail.rr.com. IN NS ;; ANSWER SECTION: mail.rr.com. 14204 IN NS cdptpa-admin02.mail.rr.com. mail.rr.com. 14204 IN NS hrndva-admin01.mail.rr.com. mail.rr.com. 14204 IN NS hrndva-admin02.mail.rr.com. mail.rr.com. 14204 IN NS cdptpa-admin01.mail.rr.com. All 4 of those queries will answer a UDP DNS query for host record hrndva-smtpin01.mail.rr.com. However, the hrndva-admin01.mail.rr.com and hrndva-admin02.mail.rr.com servers do not respond to TCP queries at all. Example: # dig hrndva-smtpin01.mail.rr.com @hrndva-admin01.mail.rr.com +tcp ; <<>> DiG 9.3.3rc2 <<>> hrndva-smtpin01.mail.rr.com @hrndva-admin01.mail.rr.com +tcp ; (1 server found) ;; global options: printcmd ;; connection timed out; no servers could be reached >From what I have read, public DNS servers should support both UDP and TCP queries. TCP queries are often used when a UDP query fails, or if the answer is over a certain length. Any clues would be appreciated. Mark -- Mark Price Tranquil Hosting www.tqhosting.com From Jon.Kibler at aset.com Fri Jun 13 13:14:55 2008 From: Jon.Kibler at aset.com (Jon Kibler) Date: Fri, 13 Jun 2008 14:14:55 -0400 Subject: DNS problems to RoadRunner - tcp vs udp In-Reply-To: <61b6fbec0806131111u77606e1bu90bcd102c3217fb4@mail.gmail.com> References: <61b6fbec0806131111u77606e1bu90bcd102c3217fb4@mail.gmail.com> Message-ID: <4852B91F.8090205@aset.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Mark Price wrote: >>From what I have read, public DNS servers should support both UDP and > TCP queries. TCP queries are often used when a UDP query fails, or if > the answer is over a certain length. > UDP is used for queries. TCP is used for zone transfers. If my server responded to TCP queries from anyone other than a secondary server, I would be VERY concerned. Jon Kibler - -- Jon R. Kibler Chief Technical Officer Advanced Systems Engineering Technology, Inc. Charleston, SC USA o: 843-849-8214 c: 843-224-2494 s: 843-564-4224 My PGP Fingerprint is: BAA2 1F2C 5543 5D25 4636 A392 515C 5045 CF39 4253 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkhSuR8ACgkQUVxQRc85QlNWGwCfUQFP7oNInCRZ72S2V2OSlE7Q IN4An3Ej+M3jsHFvHNHzl6UMYnczpv0v =GiEh -----END PGP SIGNATURE----- ================================================== Filtered by: TRUSTEM.COM's Email Filtering Service http://www.trustem.com/ No Spam. No Viruses. Just Good Clean Email. From Valdis.Kletnieks at vt.edu Fri Jun 13 13:19:09 2008 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 13 Jun 2008 14:19:09 -0400 Subject: DNS problems to RoadRunner - tcp vs udp In-Reply-To: Your message of "Fri, 13 Jun 2008 14:14:55 EDT." <4852B91F.8090205@aset.com> References: <61b6fbec0806131111u77606e1bu90bcd102c3217fb4@mail.gmail.com> <4852B91F.8090205@aset.com> Message-ID: <20393.1213381149@turing-police.cc.vt.edu> On Fri, 13 Jun 2008 14:14:55 EDT, Jon Kibler said: > UDP is used for queries. > > TCP is used for zone transfers. It's also sometimes used if a reply doesn't fit in the 512 bytes for a UDP answer and EDNS0 isn't in effect. You get a truncated UDP packet back and re-ask the query over TCP. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From mike at rockynet.com Fri Jun 13 13:22:07 2008 From: mike at rockynet.com (Mike Lewinski) Date: Fri, 13 Jun 2008 12:22:07 -0600 Subject: DNS problems to RoadRunner - tcp vs udp In-Reply-To: <4852B91F.8090205@aset.com> References: <61b6fbec0806131111u77606e1bu90bcd102c3217fb4@mail.gmail.com> <4852B91F.8090205@aset.com> Message-ID: <4852BACF.5060604@rockynet.com> Jon Kibler wrote: > UDP is used for queries. > > TCP is used for zone transfers. > > If my server responded to TCP queries from anyone other than a secondary > server, I would be VERY concerned. That is a common, but incorrect, assumption. DNS responses that are larger than the MTU of a single UDP packet are sent as TCP. Back in the day (c. 1998) Microsoft had some arpa zones that they felt it necessary to create hundreds of PTRs per entry. Of course, they denied TCP to their nameservers. The end result is that our BIND8 server was crashing on the lookups (it was a crappy port to NT). From sethm at rollernet.us Fri Jun 13 13:24:27 2008 From: sethm at rollernet.us (Seth Mattinen) Date: Fri, 13 Jun 2008 11:24:27 -0700 Subject: DNS problems to RoadRunner - tcp vs udp In-Reply-To: <4852B91F.8090205@aset.com> References: <61b6fbec0806131111u77606e1bu90bcd102c3217fb4@mail.gmail.com> <4852B91F.8090205@aset.com> Message-ID: <4852BB5B.9010708@rollernet.us> Jon Kibler wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Mark Price wrote: > >> >From what I have read, public DNS servers should support both UDP and >> TCP queries. TCP queries are often used when a UDP query fails, or if >> the answer is over a certain length. >> > > UDP is used for queries. > > TCP is used for zone transfers. > > If my server responded to TCP queries from anyone other than a secondary > server, I would be VERY concerned. > I see long TXT records from some DNSBLs that won't fit in a UDP packet on a daily basis. Certainly nothing to be concerned about. ~Seth From oberman at es.net Fri Jun 13 13:26:28 2008 From: oberman at es.net (Kevin Oberman) Date: Fri, 13 Jun 2008 11:26:28 -0700 Subject: DNS problems to RoadRunner - tcp vs udp In-Reply-To: Your message of "Fri, 13 Jun 2008 14:14:55 EDT." <4852B91F.8090205@aset.com> Message-ID: <20080613182628.CBCB345048@ptavv.es.net> > Date: Fri, 13 Jun 2008 14:14:55 -0400 > From: Jon Kibler > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Mark Price wrote: > > >>From what I have read, public DNS servers should support both UDP and > > TCP queries. TCP queries are often used when a UDP query fails, or if > > the answer is over a certain length. > > > > UDP is used for queries. Sometimes. > TCP is used for zone transfers. Yes. > If my server responded to TCP queries from anyone other than a secondary > server, I would be VERY concerned. If it does not, you should be very concerned. The RFCs (several, but I'll point first to good old 1122) allow either TCP or UDP to be used for any operation that will fit in a 512 byte transfer. (EDNS0 allows larger UDP.) TCP is to be used any time a truncated bit is set in a replay. If you ever send a large reply that won't fit in 512 bytes, the request will be repeated using a TCP connection. If you ignore these, your DNS is broken. It is even allowed under the spec to start out with TCP, as AXFR queries typically do. Yes, I realize that this is fairly common and it does not break much, but, should DNSSEC catch on, you might just find the breakage a bit worse than it is today and there is no reason to have even the slight breakage that is there now. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman at es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 224 bytes Desc: not available URL: From oberman at es.net Fri Jun 13 13:28:37 2008 From: oberman at es.net (Kevin Oberman) Date: Fri, 13 Jun 2008 11:28:37 -0700 Subject: Best utilizing fat long pipes and large file transfer In-Reply-To: Your message of "Fri, 13 Jun 2008 12:40:48 EDT." <1213375252_14636@mail1.tellurian.net> Message-ID: <20080613182837.78D804500E@ptavv.es.net> > Date: Fri, 13 Jun 2008 12:40:48 -0400 > From: Robert Boyle > > At 12:01 PM 6/13/2008, Kevin Oberman wrote: > >Clearly you have failed to try very hard or to check into what others > >have done. We routinely move data at MUCH higher rates over TCP at > >latencies over 50 ms. one way (>100 ms. RTT). We find it fairly easy to > >move data at over 4 Gbps continuously. > > That's impressive. > > >If you can't fill a GE to 80% (800 Mbps) at 30 ms, you really are not > >tying very hard. Note: I am talking about a single TCP stream running > >for over 5 minutes at a time on tuned systems. Tuning for most modern > >network stacks is pretty trivial. Some older stacks (e.g. FreeBSD V6) > >are hopeless. I can't speak to how Windows does as I make no use of it > >for high-speed bulk transfers. > > Let me refine my post then... > In our experience, you can't get to line speed with over 20-30ms of > latency using TCP on _Windows_ regardless of how much you tweak > it. >99% of the servers in our facilities are Windows based. I should > have been more specific. Sorry, but I don't do Windows, but my friends who do claim that this is not true. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman at es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 224 bytes Desc: not available URL: From owens at nysernet.org Fri Jun 13 13:33:57 2008 From: owens at nysernet.org (Bill Owens) Date: Fri, 13 Jun 2008 14:33:57 -0400 Subject: DNS problems to RoadRunner - tcp vs udp In-Reply-To: <4852B91F.8090205@aset.com> References: <61b6fbec0806131111u77606e1bu90bcd102c3217fb4@mail.gmail.com> <4852B91F.8090205@aset.com> Message-ID: <20080613183357.GA77065@nysernet.org> On Fri, Jun 13, 2008 at 02:14:55PM -0400, Jon Kibler wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Mark Price wrote: > > >>From what I have read, public DNS servers should support both UDP and > > TCP queries. TCP queries are often used when a UDP query fails, or if > > the answer is over a certain length. > > > > UDP is used for queries. > > TCP is used for zone transfers. > > If my server responded to TCP queries from anyone other than a secondary > server, I would be VERY concerned. Red alert: [cookiemonster:~] owens% dig +tcp aset.com @209.190.93.130 soa ; <<>> DiG 9.4.2 <<>> +tcp aset.com @209.190.93.130 soa ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5864 ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 5, ADDITIONAL: 2 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;aset.com. IN SOA ;; ANSWER SECTION: aset.com. 14400 IN SOA ns1.sims.net. hostmaster.aset.com. 2006111001 10800 3600 3600000 86400 ;; AUTHORITY SECTION: aset.com. 14400 IN NS ns3.trustns.net. aset.com. 14400 IN NS ns1.sims.net. aset.com. 14400 IN NS ns1.trustns.net. aset.com. 14400 IN NS ns2.sims.net. aset.com. 14400 IN NS ns2.trustns.net. ;; ADDITIONAL SECTION: ns1.sims.net. 86400 IN A 209.190.93.130 ns2.sims.net. 86400 IN A 209.190.93.132 ;; Query time: 31 msec ;; SERVER: 209.190.93.130#53(209.190.93.130) ;; WHEN: Fri Jun 13 14:31:13 2008 ;; MSG SIZE rcvd: 211 Bill. From Valdis.Kletnieks at vt.edu Fri Jun 13 13:52:38 2008 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 13 Jun 2008 14:52:38 -0400 Subject: DNS problems to RoadRunner - tcp vs udp In-Reply-To: Your message of "Fri, 13 Jun 2008 14:19:09 EDT." <20393.1213381149@turing-police.cc.vt.edu> References: <61b6fbec0806131111u77606e1bu90bcd102c3217fb4@mail.gmail.com> <4852B91F.8090205@aset.com> <20393.1213381149@turing-police.cc.vt.edu> Message-ID: <22593.1213383158@turing-police.cc.vt.edu> Sorry to abuse the list, but aset.com seems to have some mail blocking issues: (reason: 551 5.7.1 Message undeliverable. Please see: http://bounce.trustem.net/edu.php?id=m5DIJA6U012003.0.1... not accept email from DHCP connections with an academic institution supplied hostname (you.VT.EDU).) Jon? It's not a DHCP connection. It's a dedicated fixed IP address that hasn't moved in at least 6 years, it's in the DNS as such, and I'm curious what you based the "it's a DHCP" on? Incidentally, you may want to clean up your message, as the URL http://bounce.trustem.net/edu.php?id=m5DIJA6U012003.0.1... is unclear as to whether it has 0, 1, 2, or 3 trailing dots, and whether any trailing dots are an ellipsis rather than a part of the URL. Actually visiting that with all of 0..3 dots *all* fail with a "Oops link not found" screen, so it isn't like I can sort it out based on info your message provides. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From Jon.Kibler at aset.com Fri Jun 13 13:51:58 2008 From: Jon.Kibler at aset.com (Jon Kibler) Date: Fri, 13 Jun 2008 14:51:58 -0400 Subject: DNS problems to RoadRunner - tcp vs udp In-Reply-To: <20080613182628.CBCB345048@ptavv.es.net> References: <20080613182628.CBCB345048@ptavv.es.net> Message-ID: <4852C1CE.2020804@aset.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Kevin Oberman wrote: > > If it does not, you should be very concerned. The RFCs (several, but > I'll point first to good old 1122) allow either TCP or UDP to be used > for any operation that will fit in a 512 byte transfer. (EDNS0 allows > larger UDP.) > > TCP is to be used any time a truncated bit is set in a replay. If you > ever send a large reply that won't fit in 512 bytes, the request will > be repeated using a TCP connection. If you ignore these, your DNS is > broken. It is even allowed under the spec to start out with TCP, as AXFR > queries typically do. > > Yes, I realize that this is fairly common and it does not break much, > but, should DNSSEC catch on, you might just find the breakage a bit > worse than it is today and there is no reason to have even the slight > breakage that is there now. Okay, I stand corrected. I was approaching this from a security perspective only, and apparently based on incorrect information. But this leaves me with a couple of questions: Various hardening documents for Cisco routers specify the best practices are to only allow 53/tcp connections to/from secondary name servers. Plus, from all I can tell, Cisco's 'ip inspect dns' CBAC appears to only handle UDP data connections and anything TCP would be denied. From what you are saying, the hardening recommendations are wrong and that CBAC may break some DNS responses. Is this correct? Also, other than "That's what the RFCs call for," why use TCP for data exchange instead of larger UDP packets? Jon Kibler - -- Jon R. Kibler Chief Technical Officer Advanced Systems Engineering Technology, Inc. Charleston, SC USA o: 843-849-8214 c: 843-224-2494 s: 843-564-4224 My PGP Fingerprint is: BAA2 1F2C 5543 5D25 4636 A392 515C 5045 CF39 4253 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkhSwc4ACgkQUVxQRc85QlPzkACeOuKS3ni0uTNrjpcjY2tOZmc5 wbcAn1T85g7sBXkjOsWFENxWAtnT/kny =GlaW -----END PGP SIGNATURE----- ================================================== Filtered by: TRUSTEM.COM's Email Filtering Service http://www.trustem.com/ No Spam. No Viruses. Just Good Clean Email. From Jon.Kibler at aset.com Fri Jun 13 13:57:17 2008 From: Jon.Kibler at aset.com (Jon Kibler) Date: Fri, 13 Jun 2008 14:57:17 -0400 Subject: DNS problems to RoadRunner - tcp vs udp In-Reply-To: <20080613183357.GA77065@nysernet.org> References: <61b6fbec0806131111u77606e1bu90bcd102c3217fb4@mail.gmail.com> <4852B91F.8090205@aset.com> <20080613183357.GA77065@nysernet.org> Message-ID: <4852C30D.6030202@aset.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Bill Owens wrote: > On Fri, Jun 13, 2008 at 02:14:55PM -0400, Jon Kibler wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Mark Price wrote: >> >>> >From what I have read, public DNS servers should support both UDP and >>> TCP queries. TCP queries are often used when a UDP query fails, or if >>> the answer is over a certain length. >>> >> UDP is used for queries. >> >> TCP is used for zone transfers. >> >> If my server responded to TCP queries from anyone other than a secondary >> server, I would be VERY concerned. > > Red alert: > > [cookiemonster:~] owens% dig +tcp aset.com @209.190.93.130 soa > > ; <<>> DiG 9.4.2 <<>> +tcp aset.com @209.190.93.130 soa > ;; global options: printcmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5864 > ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 5, ADDITIONAL: 2 > ;; WARNING: recursion requested but not available > > ;; QUESTION SECTION: > ;aset.com. IN SOA > > ;; ANSWER SECTION: > aset.com. 14400 IN SOA ns1.sims.net. hostmaster.aset.com. 2006111001 10800 3600 3600000 86400 > > ;; AUTHORITY SECTION: > aset.com. 14400 IN NS ns3.trustns.net. > aset.com. 14400 IN NS ns1.sims.net. > aset.com. 14400 IN NS ns1.trustns.net. > aset.com. 14400 IN NS ns2.sims.net. > aset.com. 14400 IN NS ns2.trustns.net. > > ;; ADDITIONAL SECTION: > ns1.sims.net. 86400 IN A 209.190.93.130 > ns2.sims.net. 86400 IN A 209.190.93.132 > > ;; Query time: 31 msec > ;; SERVER: 209.190.93.130#53(209.190.93.130) > ;; WHEN: Fri Jun 13 14:31:13 2008 > ;; MSG SIZE rcvd: 211 UGH. Apparently hosting provider must have messed with IPTABLES on that system. Thanks for the heads up. (Open mouth, insert foot.) Jon Kibler - -- Jon R. Kibler Chief Technical Officer Advanced Systems Engineering Technology, Inc. Charleston, SC USA o: 843-849-8214 c: 843-224-2494 s: 843-564-4224 My PGP Fingerprint is: BAA2 1F2C 5543 5D25 4636 A392 515C 5045 CF39 4253 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkhSww0ACgkQUVxQRc85QlNk5wCfZT8s3CYDjb3lj86xU/k1N2+m 1O8AnAuSLaFthAwmBwUAmNS0MePFo/SF =/Ol5 -----END PGP SIGNATURE----- ================================================== Filtered by: TRUSTEM.COM's Email Filtering Service http://www.trustem.com/ No Spam. No Viruses. Just Good Clean Email. From trall at almaden.ibm.com Fri Jun 13 14:03:55 2008 From: trall at almaden.ibm.com (Tony Rall) Date: Fri, 13 Jun 2008 12:03:55 -0700 Subject: DNS problems to RoadRunner - tcp vs udp In-Reply-To: <4852B91F.8090205@aset.com> Message-ID: On Friday, 2008-06-13 at 14:14 AST, Jon Kibler wrote: > UDP is used for queries. True. But TCP can (and in some cases, has to be) used for queries also. You are misinformed. See RFC 1035 (and others). -- Tony Rall From jtk at ultradns.net Fri Jun 13 14:05:44 2008 From: jtk at ultradns.net (John Kristoff) Date: Fri, 13 Jun 2008 14:05:44 -0500 Subject: DNS problems to RoadRunner - tcp vs udp In-Reply-To: <4852B91F.8090205@aset.com> References: <61b6fbec0806131111u77606e1bu90bcd102c3217fb4@mail.gmail.com> <4852B91F.8090205@aset.com> Message-ID: <200806131905.m5DJ5jpG032683@larry.centergate.com> On Fri, 13 Jun 2008 14:14:55 -0400 Jon Kibler wrote: > TCP is used for zone transfers. > If my server responded to TCP queries from anyone other than a secondary > server, I would be VERY concerned. I wouldn't be unless it looked like a DDoS - and it might for some that are seeing the results of a DNS-based DDoS mitigation device you or an upstream put in for the first time. These boxes force clients to switch over from UDP to TCP for queries when a well formed UDP DNS attack hits. John From dhubbard at dino.hostasaurus.com Fri Jun 13 14:08:47 2008 From: dhubbard at dino.hostasaurus.com (David Hubbard) Date: Fri, 13 Jun 2008 15:08:47 -0400 Subject: .255 addresses still not usable after all these years? Message-ID: I remember back in the day of old hardware and operating systems we'd intentionally avoid using .255 IP addresses for anything even when the netmask on our side would have made it fine, so I just thought I'd try it out for kicks today. From two of four ISP's it worked fine, from Verizon FIOS and Road Runner commercial, it didn't. So I guess that old problem still lingers? David From tomb at byrneit.net Fri Jun 13 14:13:36 2008 From: tomb at byrneit.net (Tomas L. Byrnes) Date: Fri, 13 Jun 2008 12:13:36 -0700 Subject: DNS problems to RoadRunner - tcp vs udp In-Reply-To: <4852C1CE.2020804@aset.com> References: <20080613182628.CBCB345048@ptavv.es.net> <4852C1CE.2020804@aset.com> Message-ID: <70D072392E56884193E3D2DE09C097A9F206@pascal.zaphodb.org> First: if you don't allow TCP queries, then you're going to break lots of recent applications for DNS. Second: unless your server and resolver support EDNS0, there is no way to increase the size of a UDP response, and even then, it's not large enough for many applications (ENUM, TXT, APL, etc.). TCP response to queries has been specified since RFC1035. The maximum message size is limited to 65535 bytes (due to the 16bit message size field before the header). RE the Cisco questions: this would not be the first time Cisco lagged in supporting enhanced services on the network. > -----Original Message----- > From: Jon Kibler [mailto:Jon.Kibler at aset.com] > Sent: Friday, June 13, 2008 11:52 AM > To: Kevin Oberman > Cc: nanog at merit.edu > Subject: Re: DNS problems to RoadRunner - tcp vs udp > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Kevin Oberman wrote: > > > > > If it does not, you should be very concerned. The RFCs > (several, but > > I'll point first to good old 1122) allow either TCP or UDP > to be used > > for any operation that will fit in a 512 byte transfer. > (EDNS0 allows > > larger UDP.) > > > > TCP is to be used any time a truncated bit is set in a > replay. If you > > ever send a large reply that won't fit in 512 bytes, the > request will > > be repeated using a TCP connection. If you ignore these, > your DNS is > > broken. It is even allowed under the spec to start out with TCP, as > > AXFR queries typically do. > > > > Yes, I realize that this is fairly common and it does not > break much, > > but, should DNSSEC catch on, you might just find the breakage a bit > > worse than it is today and there is no reason to have even > the slight > > breakage that is there now. > > Okay, I stand corrected. I was approaching this from a > security perspective only, and apparently based on incorrect > information. > > But this leaves me with a couple of questions: > > Various hardening documents for Cisco routers specify the > best practices are to only allow 53/tcp connections to/from > secondary name servers. > Plus, from all I can tell, Cisco's 'ip inspect dns' CBAC > appears to only handle UDP data connections and anything TCP > would be denied. From what you are saying, the hardening > recommendations are wrong and that CBAC may break some DNS > responses. Is this correct? > > Also, other than "That's what the RFCs call for," why use TCP > for data exchange instead of larger UDP packets? > > Jon Kibler > - -- > Jon R. Kibler > Chief Technical Officer > Advanced Systems Engineering Technology, Inc. > Charleston, SC USA > o: 843-849-8214 > c: 843-224-2494 > s: 843-564-4224 > > My PGP Fingerprint is: > BAA2 1F2C 5543 5D25 4636 A392 515C 5045 CF39 4253 > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.8 (Darwin) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iEYEARECAAYFAkhSwc4ACgkQUVxQRc85QlPzkACeOuKS3ni0uTNrjpcjY2tOZmc5 > wbcAn1T85g7sBXkjOsWFENxWAtnT/kny > =GlaW > -----END PGP SIGNATURE----- > > > > > ================================================== > Filtered by: TRUSTEM.COM's Email Filtering Service > http://www.trustem.com/ No Spam. No Viruses. Just Good Clean Email. > > From Valdis.Kletnieks at vt.edu Fri Jun 13 14:16:42 2008 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 13 Jun 2008 15:16:42 -0400 Subject: .255 addresses still not usable after all these years? In-Reply-To: Your message of "Fri, 13 Jun 2008 15:08:47 EDT." References: Message-ID: <23933.1213384602@turing-police.cc.vt.edu> On Fri, 13 Jun 2008 15:08:47 EDT, David Hubbard said: > I remember back in the day of old hardware and operating > systems we'd intentionally avoid using .255 IP addresses > for anything even when the netmask on our side would have > made it fine, so I just thought I'd try it out for kicks > today. From two of four ISP's it worked fine, from Verizon > FIOS and Road Runner commercial, it didn't. So I guess > that old problem still lingers? RFC1519 is 15 years old now. I *still* heard a trainer (in a Cisco class no less) mention class A/B/C in the last few months. Some evil will obviously take generations to fully stamp out. Anybody from Verizon FIOS or RoadRunner care to explain why David is seeing an issue in 2008? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From justin at justinshore.com Fri Jun 13 14:59:48 2008 From: justin at justinshore.com (Justin Shore) Date: Fri, 13 Jun 2008 14:59:48 -0500 Subject: DNS problems to RoadRunner - tcp vs udp In-Reply-To: <4852C1CE.2020804@aset.com> References: <20080613182628.CBCB345048@ptavv.es.net> <4852C1CE.2020804@aset.com> Message-ID: <4852D1B4.9090409@justinshore.com> Jon Kibler wrote: > Various hardening documents for Cisco routers specify the best practices > are to only allow 53/tcp connections to/from secondary name servers. > Plus, from all I can tell, Cisco's 'ip inspect dns' CBAC appears to only > handle UDP data connections and anything TCP would be denied. From what > you are saying, the hardening recommendations are wrong and that CBAC > may break some DNS responses. Is this correct? A number of Cisco default from years gone by would break DSN, today, in it's current form. Such as how PIXs and ASAs with fixup/DPI would block udp/53 packets larger than 512 bytes, not permitting EDNS packets through. > Also, other than "That's what the RFCs call for," why use TCP for data > exchange instead of larger UDP packets? From justin at justinshore.com Fri Jun 13 15:08:35 2008 From: justin at justinshore.com (Justin Shore) Date: Fri, 13 Jun 2008 15:08:35 -0500 Subject: DNS problems to RoadRunner - tcp vs udp In-Reply-To: <4852D1B4.9090409@justinshore.com> References: <20080613182628.CBCB345048@ptavv.es.net> <4852C1CE.2020804@aset.com> <4852D1B4.9090409@justinshore.com> Message-ID: <4852D3C3.2000100@justinshore.com> Justin Shore wrote: > Jon Kibler wrote: >> Various hardening documents for Cisco routers specify the best practices >> are to only allow 53/tcp connections to/from secondary name servers. >> Plus, from all I can tell, Cisco's 'ip inspect dns' CBAC appears to only >> handle UDP data connections and anything TCP would be denied. From what >> you are saying, the hardening recommendations are wrong and that CBAC >> may break some DNS responses. Is this correct? > > A number of Cisco default from years gone by would break DSN, today, in > it's current form. Such as how PIXs and ASAs with fixup/DPI would block > udp/53 packets larger than 512 bytes, not permitting EDNS packets through. Thunderbird apparently thought that I was ready to send my message before I did. I was going to add some ASA config as an example. policy-map type inspect dns migrated_dns_map_1 parameters message-length maximum 2048 I don't have an IOS CBAC example but there's surely something similar. Justin From morrowc.lists at gmail.com Fri Jun 13 15:11:13 2008 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 13 Jun 2008 16:11:13 -0400 Subject: .255 addresses still not usable after all these years? In-Reply-To: <23933.1213384602@turing-police.cc.vt.edu> References: <23933.1213384602@turing-police.cc.vt.edu> Message-ID: <75cb24520806131311u4cb71284xf1ad2036d195bdd9@mail.gmail.com> On Fri, Jun 13, 2008 at 3:16 PM, wrote: > On Fri, 13 Jun 2008 15:08:47 EDT, David Hubbard said: >> I remember back in the day of old hardware and operating >> systems we'd intentionally avoid using .255 IP addresses >> for anything even when the netmask on our side would have >> made it fine, so I just thought I'd try it out for kicks >> today. From two of four ISP's it worked fine, from Verizon >> FIOS and Road Runner commercial, it didn't. So I guess >> that old problem still lingers? > > RFC1519 is 15 years old now. I *still* heard a trainer (in a Cisco > class no less) mention class A/B/C in the last few months. Some evil > will obviously take generations to fully stamp out. > > Anybody from Verizon FIOS or RoadRunner care to explain why David is seeing > an issue in 2008? not from either, and hopefully david will follow back up with some of his findings, but.. I'd bet dollars to donuts it's the ultra-crappy CPE both vendors ship :( go-go-actiontec (vol sends those out, god do they suck...) -Chris From dga at cs.cmu.edu Fri Jun 13 15:39:37 2008 From: dga at cs.cmu.edu (David Andersen) Date: Fri, 13 Jun 2008 16:39:37 -0400 Subject: .255 addresses still not usable after all these years? In-Reply-To: <75cb24520806131311u4cb71284xf1ad2036d195bdd9@mail.gmail.com> References: <23933.1213384602@turing-police.cc.vt.edu> <75cb24520806131311u4cb71284xf1ad2036d195bdd9@mail.gmail.com> Message-ID: On Jun 13, 2008, at 4:11 PM, Christopher Morrow wrote: > On Fri, Jun 13, 2008 at 3:16 PM, wrote: >> On Fri, 13 Jun 2008 15:08:47 EDT, David Hubbard said: >>> I remember back in the day of old hardware and operating >>> systems we'd intentionally avoid using .255 IP addresses >>> for anything even when the netmask on our side would have >>> made it fine, so I just thought I'd try it out for kicks >>> today. From two of four ISP's it worked fine, from Verizon >>> FIOS and Road Runner commercial, it didn't. So I guess >>> that old problem still lingers? >> >> RFC1519 is 15 years old now. I *still* heard a trainer (in a Cisco >> class no less) mention class A/B/C in the last few months. Some evil >> will obviously take generations to fully stamp out. >> >> Anybody from Verizon FIOS or RoadRunner care to explain why David >> is seeing >> an issue in 2008? > > not from either, and hopefully david will follow back up with some of > his findings, but.. I'd bet dollars to donuts it's the ultra-crappy > CPE both vendors ship :( > > go-go-actiontec (vol sends those out, god do they suck...) Or leftover filters from before 'no ip directed-broadcast' in the days of Smurf attacks. -Dave From kgasso-lists at visp.net Fri Jun 13 15:43:36 2008 From: kgasso-lists at visp.net (Kameron Gasso) Date: Fri, 13 Jun 2008 13:43:36 -0700 Subject: .255 addresses still not usable after all these years? In-Reply-To: <75cb24520806131311u4cb71284xf1ad2036d195bdd9@mail.gmail.com> References: <23933.1213384602@turing-police.cc.vt.edu> <75cb24520806131311u4cb71284xf1ad2036d195bdd9@mail.gmail.com> Message-ID: <4852DBF8.4040804@visp.net> Christopher Morrow wrote: > go-go-actiontec (vol sends those out, god do they suck...) Crappy CPE's are exactly why we don't hand out .0 and .255 addresses in our DHCP pools. :( -- Kameron Gasso | Senior Systems Administrator | visp.net Direct: 541-955-6903 | Fax: 541-471-0821 From stu at spacehopper.org Fri Jun 13 16:40:43 2008 From: stu at spacehopper.org (Stuart Henderson) Date: Fri, 13 Jun 2008 21:40:43 +0000 (UTC) Subject: Best utilizing fat long pipes and large file transfer References: <4851A53B.4010400@craigslist.org> <20080612230550.18AE44500E@ptavv.es.net> Message-ID: On 2008-06-12, Kevin Oberman wrote: > The idea is to use tuned proxies that are close to the source and > destination and are optimized for the delay. OpenBSD has relayd(8), a versatile tool which can be used here. There is support for proxying TCP connections. These can be modified in a few ways - socket options (nodelay, sack, socket buffer) can be adjusted on the relayed connection, also SSL can be offloaded. It works with the firewall state table and can retain the original addresses. Parts of this are only in development snapshots at present but will be in the 4.4 release. From peter at peter-dambier.de Fri Jun 13 17:09:10 2008 From: peter at peter-dambier.de (Peter Dambier) Date: Sat, 14 Jun 2008 00:09:10 +0200 Subject: .255 addresses still not usable after all these years? In-Reply-To: References: <23933.1213384602@turing-police.cc.vt.edu> <75cb24520806131311u4cb71284xf1ad2036d195bdd9@mail.gmail.com> Message-ID: <4852F006.8050803@peter-dambier.de> I have had a look into the manuals of my ISP's routers. Those boxes can think in /24 only. The split whatever you have down to several /24 and reserve both .0 and .255 in each of them. I have seen both .0 and .255 in the WLAN behind NAT working but you have to ifconfig the interface via telnet. The html configuration wont allow to do it. Kind regards Peter David Andersen wrote: > > On Jun 13, 2008, at 4:11 PM, Christopher Morrow wrote: > >> On Fri, Jun 13, 2008 at 3:16 PM, wrote: >>> On Fri, 13 Jun 2008 15:08:47 EDT, David Hubbard said: >>>> I remember back in the day of old hardware and operating >>>> systems we'd intentionally avoid using .255 IP addresses >>>> for anything even when the netmask on our side would have >>>> made it fine, so I just thought I'd try it out for kicks >>>> today. From two of four ISP's it worked fine, from Verizon >>>> FIOS and Road Runner commercial, it didn't. So I guess >>>> that old problem still lingers? >>> >>> RFC1519 is 15 years old now. I *still* heard a trainer (in a Cisco >>> class no less) mention class A/B/C in the last few months. Some evil >>> will obviously take generations to fully stamp out. >>> >>> Anybody from Verizon FIOS or RoadRunner care to explain why David is >>> seeing >>> an issue in 2008? >> >> not from either, and hopefully david will follow back up with some of >> his findings, but.. I'd bet dollars to donuts it's the ultra-crappy >> CPE both vendors ship :( >> >> go-go-actiontec (vol sends those out, god do they suck...) > > Or leftover filters from before 'no ip directed-broadcast' > in the days of Smurf attacks. > > -Dave > -- Peter and Karin Dambier Cesidian Root - Radice Cesidiana Rimbacher Strasse 16 D-69509 Moerlenbach-Bonsweiher +49(6209)795-816 (Telekom) +49(6252)750-308 (VoIP: sipgate.de) mail: peter at peter-dambier.de http://www.peter-dambier.de/ http://iason.site.voila.fr/ https://sourceforge.net/projects/iason/ From randy at psg.com Fri Jun 13 17:25:45 2008 From: randy at psg.com (Randy Bush) Date: Sat, 14 Jun 2008 07:25:45 +0900 Subject: DNS problems to RoadRunner - tcp vs udp In-Reply-To: <4852B91F.8090205@aset.com> References: <61b6fbec0806131111u77606e1bu90bcd102c3217fb4@mail.gmail.com> <4852B91F.8090205@aset.com> Message-ID: <4852F3E9.3060707@psg.com> > If my server responded to TCP queries from anyone other than a secondary > server, I would be VERY concerned. you may want to read the specs randy From mike at rockynet.com Fri Jun 13 17:26:57 2008 From: mike at rockynet.com (Mike Lewinski) Date: Fri, 13 Jun 2008 16:26:57 -0600 Subject: .255 addresses still not usable after all these years? In-Reply-To: References: Message-ID: <4852F431.8060209@rockynet.com> David Hubbard wrote: > I remember back in the day of old hardware and operating > systems we'd intentionally avoid using .255 IP addresses > for anything even when the netmask on our side would have > made it fine, so I just thought I'd try it out for kicks > today. From two of four ISP's it worked fine, from Verizon > FIOS and Road Runner commercial, it didn't. So I guess > that old problem still lingers? The TCP/IP stack in Windows XP is broken in this regard, possibly in Vista as well, though I've yet to have the displeasure of finding out. I have a router with a .255 loopback IP on it. My Windows XP hosts cannot SSH to it. The specific error that Putty throws is "Network error: Cannot assign requested address". At least if I ever need to completely protect a device from access by Windows users, I have a good option :) Mike From mike at rockynet.com Fri Jun 13 17:34:27 2008 From: mike at rockynet.com (Mike Lewinski) Date: Fri, 13 Jun 2008 16:34:27 -0600 Subject: .255 addresses still not usable after all these years? In-Reply-To: <4852F431.8060209@rockynet.com> References: <4852F431.8060209@rockynet.com> Message-ID: <4852F5F3.1000108@rockynet.com> Mike Lewinski wrote: > The TCP/IP stack in Windows XP is broken in this regard, possibly in > Vista as well, though I've yet to have the displeasure of finding out. A co-worker confirms that his Vista SP1 can access our .255 router via SSH. From william.allen.simpson at gmail.com Fri Jun 13 17:58:35 2008 From: william.allen.simpson at gmail.com (William Allen Simpson) Date: Fri, 13 Jun 2008 18:58:35 -0400 Subject: .255 addresses still not usable after all these years? In-Reply-To: <4852F5F3.1000108@rockynet.com> References: <4852F431.8060209@rockynet.com> <4852F5F3.1000108@rockynet.com> Message-ID: <4852FB9B.6040007@gmail.com> Mike Lewinski wrote: >> The TCP/IP stack in Windows XP is broken in this regard, possibly in >> Vista as well, though I've yet to have the displeasure of finding out. > > A co-worker confirms that his Vista SP1 can access our .255 router via SSH. > Aww, that's too bad. I've long enjoyed setting loopback and other internal device addresses to .255 -- it drastically reduced some attacks, and made security by obscurity work better. Not that I recommend obscurity as the only security. ;-) From nanog at namor.ca Fri Jun 13 18:01:28 2008 From: nanog at namor.ca (Jared) Date: Fri, 13 Jun 2008 18:01:28 -0500 Subject: .255 addresses still not usable after all these years? In-Reply-To: <4852F431.8060209@rockynet.com> References: <4852F431.8060209@rockynet.com> Message-ID: <4852FC48.3090608@namor.ca> Mike Lewinski wrote: > David Hubbard wrote: >> I remember back in the day of old hardware and operating >> systems we'd intentionally avoid using .255 IP addresses >> for anything even when the netmask on our side would have >> made it fine, so I just thought I'd try it out for kicks >> today. From two of four ISP's it worked fine, from Verizon >> FIOS and Road Runner commercial, it didn't. So I guess >> that old problem still lingers? > > The TCP/IP stack in Windows XP is broken in this regard, possibly in > Vista as well, though I've yet to have the displeasure of finding out. I > have a router with a .255 loopback IP on it. My Windows XP hosts cannot > SSH to it. The specific error that Putty throws is "Network error: > Cannot assign requested address". > > At least if I ever need to completely protect a device from access by > Windows users, I have a good option :) > > Mike We had to split our assigned ranges (PPP/PPPoE) into /24, even if it were assigned to the (NAS, BRAS, etc) in larger chunks. It seems customers who were assigned the .0/.255 could get out there - but certain sites (IIS it seemed) would refuse to talk back. I forget if I tested microsoft.com like this... From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Fri Jun 13 20:51:19 2008 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Sat, 14 Jun 2008 11:21:19 +0930 Subject: .255 addresses still not usable after all these years? In-Reply-To: <4852DBF8.4040804@visp.net> References: <23933.1213384602@turing-police.cc.vt.edu> <75cb24520806131311u4cb71284xf1ad2036d195bdd9@mail.gmail.com> <4852DBF8.4040804@visp.net> Message-ID: <20080614112119.a364bcbe.nanog@85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org> On Fri, 13 Jun 2008 13:43:36 -0700 Kameron Gasso wrote: > Christopher Morrow wrote: > > go-go-actiontec (vol sends those out, god do they suck...) > > Crappy CPE's are exactly why we don't hand out .0 and .255 addresses in > our DHCP pools. :( > -- > Kameron Gasso | Senior Systems Administrator | visp.net > Direct: 541-955-6903 | Fax: 541-471-0821 > We avoid them because in the interest of "security", customers who would be assigned .0 and .255 have trouble accessing their online banking and other financial websites. With IPv4 address space running out, we'll probably inevitably have to start handing them out and then get our customers to complain to their bank etc. Regards, Mark. -- "Sheep are slow and tasty, and therefore must remain constantly alert." - Bruce Schneier, "Beyond Fear" From tdurack at gmail.com Fri Jun 13 22:19:06 2008 From: tdurack at gmail.com (Tim Durack) Date: Fri, 13 Jun 2008 23:19:06 -0400 Subject: .255 addresses still not usable after all these years? In-Reply-To: <20080614112119.a364bcbe.nanog@85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org> References: <23933.1213384602@turing-police.cc.vt.edu> <75cb24520806131311u4cb71284xf1ad2036d195bdd9@mail.gmail.com> <4852DBF8.4040804@visp.net> <20080614112119.a364bcbe.nanog@85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org> Message-ID: <9e246b4d0806132019q6c3098eakea1b8da0facbaf1e@mail.gmail.com> Funny this discussion surfaced now - I got bitten by this recently. Was using .255 for NAT on a secondary firewall. When the primary failed over, parts of the Internet became unreachable... Tim:> On Fri, Jun 13, 2008 at 9:51 PM, Mark Smith wrote: > On Fri, 13 Jun 2008 13:43:36 -0700 > Kameron Gasso wrote: > >> Christopher Morrow wrote: >> > go-go-actiontec (vol sends those out, god do they suck...) >> >> Crappy CPE's are exactly why we don't hand out .0 and .255 addresses in >> our DHCP pools. :( >> -- >> Kameron Gasso | Senior Systems Administrator | visp.net >> Direct: 541-955-6903 | Fax: 541-471-0821 >> > > We avoid them because in the interest of "security", customers who > would be assigned .0 and .255 have trouble accessing their online > banking and other financial websites. With IPv4 address space running > out, we'll probably inevitably have to start handing them out and then > get our customers to complain to their bank etc. > > > Regards, > Mark. > > -- > > "Sheep are slow and tasty, and therefore must remain constantly > alert." > - Bruce Schneier, "Beyond Fear" > > From ianh at chime.net.au Fri Jun 13 22:42:31 2008 From: ianh at chime.net.au (Ian Henderson) Date: Sat, 14 Jun 2008 11:42:31 +0800 Subject: .255 addresses still not usable after all these years? In-Reply-To: <23933.1213384602@turing-police.cc.vt.edu> References: <23933.1213384602@turing-police.cc.vt.edu> Message-ID: <100362309621454DAA534950B17E55DB9E02CAA850@isp-per-exc01.win2k.iinet.net.au> Valdis.Kletnieks at vt.edu wrote on 2008-06-14: > RFC1519 is 15 years old now. I *still* heard a trainer (in a Cisco > class no less) mention class A/B/C in the last few months. Some evil > will obviously take generations to fully stamp out. We've faced two issues with .255 and .0: - Using /31 links Windows tracert * * *'s on .0 addresses. Had many users who thought they knew better complain about it. - Using a .255 loopback on a Cisco 6500 SNMP requests would return from the closest interface IP address. Combined with a specific version of SNMP libraries (which I can't recall right now), this caused queries to fail. Rgds, - I. -- Ian Henderson, CCIE #14721 Senior Network Engineer, iiNet Limited From david at davidcoulson.net Fri Jun 13 22:50:27 2008 From: david at davidcoulson.net (David Coulson) Date: Fri, 13 Jun 2008 23:50:27 -0400 Subject: .255 addresses still not usable after all these years? In-Reply-To: <100362309621454DAA534950B17E55DB9E02CAA850@isp-per-exc01.win2k.iinet.net.au> References: <23933.1213384602@turing-police.cc.vt.edu> <100362309621454DAA534950B17E55DB9E02CAA850@isp-per-exc01.win2k.iinet.net.au> Message-ID: <48534003.30501@davidcoulson.net> Ian Henderson wrote: > - Using a .255 loopback on a Cisco 6500 SNMP requests would return from the closest interface IP address. Combined with a specific version of SNMP libraries (which I can't recall right now), this caused queries to fail I had a weird Cisco problem on 12.2S where it would refuse to establish a BGP peering to a loopback with a .0 IP address. I moved it to something else and it worked fine. I gave up trying to figure it out. David From bmanning at vacation.karoshi.com Sat Jun 14 00:07:15 2008 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Sat, 14 Jun 2008 05:07:15 +0000 Subject: .255 addresses still not usable after all these years? In-Reply-To: References: Message-ID: <20080614050715.GA8401@vacation.karoshi.com.> On Fri, Jun 13, 2008 at 03:08:47PM -0400, David Hubbard wrote: > I remember back in the day of old hardware and operating > systems we'd intentionally avoid using .255 IP addresses > for anything even when the netmask on our side would have > made it fine, so I just thought I'd try it out for kicks > today. From two of four ISP's it worked fine, from Verizon > FIOS and Road Runner commercial, it didn't. So I guess > that old problem still lingers? > > David > well... .0 and .255 are still special in -some- contexts. they still form the all-zeros and all-ones broadcast addresses for the defined block... so: 192.168.16.0/23 192.168.16.0/32 is unusable 192.168.16.255/32 is useable 192.168.17.0/32 is useable 192.168.17.255/32 is unuseable. crapy CPE, vendor instruction, poor software all contribute to VLSM being poorly understood and these "gotchas" still around - years - later. my recommendation... place your caching nameservers and webservers on these addresses... if you want to force the issue. :) --bill From fw at deneb.enyo.de Sat Jun 14 04:35:44 2008 From: fw at deneb.enyo.de (Florian Weimer) Date: Sat, 14 Jun 2008 11:35:44 +0200 Subject: .255 addresses still not usable after all these years? In-Reply-To: <23933.1213384602@turing-police.cc.vt.edu> (Valdis Kletnieks's message of "Fri, 13 Jun 2008 15:16:42 -0400") References: <23933.1213384602@turing-police.cc.vt.edu> Message-ID: <87skvg9x5b.fsf@mid.deneb.enyo.de> * Valdis Kletnieks: > RFC1519 is 15 years old now. I *still* heard a trainer (in a Cisco > class no less) mention class A/B/C in the last few months. Some evil > will obviously take generations to fully stamp out. You need to know something about classes when you deal with Cisco gear because IOS strips prefix lengths on output if they match the length implied by the class. From rs at seastrom.com Sat Jun 14 06:43:34 2008 From: rs at seastrom.com (Robert E. Seastrom) Date: Sat, 14 Jun 2008 07:43:34 -0400 Subject: DNS problems to RoadRunner - tcp vs udp In-Reply-To: <4852C1CE.2020804@aset.com> (Jon Kibler's message of "Fri, 13 Jun 2008 14:51:58 -0400") References: <20080613182628.CBCB345048@ptavv.es.net> <4852C1CE.2020804@aset.com> Message-ID: <86r6b08cnt.fsf@seastrom.com> Jon Kibler writes: > Okay, I stand corrected. I was approaching this from a security > perspective only, and apparently based on incorrect information. It always puzzles me when people say things like that - it's as if they've lost sight of the *whole point* of security being to protect services, data, etc. and ensure that they continue uninterrupted and uncorrupted. If one is approaching problems "from a security perspective only" with no concern to breaking services... wouldn't the even more secure solution involve just reaching for the power switch? > But this leaves me with a couple of questions: > > Various hardening documents for Cisco routers specify the best practices > are to only allow 53/tcp connections to/from secondary name servers. > Plus, from all I can tell, Cisco's 'ip inspect dns' CBAC appears to only > handle UDP data connections and anything TCP would be denied. From what > you are saying, the hardening recommendations are wrong and that CBAC > may break some DNS responses. Is this correct? I bet if you look in these same hardening documents you'll find suggestions for static bogon filters (which become stale over time), filtering all ICMP (breaks PMTUD) and all sorts of other jack moves. > Also, other than "That's what the RFCs call for," why use TCP for data > exchange instead of larger UDP packets? Well, the inheritance is from the "default IP maximum datagram size" of 576 bytes, RFC879, which a host must observe absent specific knowledge that the far end can do better. In the vast majority of cases (assuming your resolver and cacheing nameserver won't puke) I suspect there would be no problem sending a somewhat-bigger-than-this-size DNS reply... right up till you go over 1500 bytes for your datagram, at which point you're back to square one. With cryptologically signed replies containing a lot of AAAA records and other data, bigger than 1500 bytes is certainly not outside the realm of possibility. Trying to fragment and reassemble DNS queries is a step away from goodness. With TCP, you have a virtual stream service rather than a datagram service, and in exchange for the overhead of setting up and tearing down the connection, one gets the ability to do transactions that are much larger. ---Rob From frnkblk at iname.com Sat Jun 14 13:34:53 2008 From: frnkblk at iname.com (Frank Bulk - iNAME) Date: Sat, 14 Jun 2008 13:34:53 -0500 Subject: [NANOG] Introducing latency for testing? In-Reply-To: <1b5c1c150805021312h33ba56dcxd448b2b1bb206d2e@mail.gmail.com> References: <1b5c1c150805021312h33ba56dcxd448b2b1bb206d2e@mail.gmail.com> Message-ID: It's not free, but at a recent trade show I did see what appeared to be an affordable unit from Apposite Technologies (apposite-tech.com). And there's always PacketStorm. Frank -----Original Message----- From: Mike Lyon [mailto:mike.lyon at gmail.com] Sent: Friday, May 02, 2008 3:13 PM To: NANOG Subject: [NANOG] Introducing latency for testing? So I want to mimic some latency in a test network for DB replication. I am wondering what other's have used for this? Obviously, the best way to would be to actually have one box across the US or across the globe to actually test against but what if you don't have that? Are there any GPL software router solutions that would allow you to tweak the latency in between the two test boxes? Thanks in advance. -Mike _______________________________________________ NANOG mailing list NANOG at nanog.org http://mailman.nanog.org/mailman/listinfo/nanog From nanog at grrrrreg.net Sat Jun 14 13:33:21 2008 From: nanog at grrrrreg.net (Greg VILLAIN) Date: Sat, 14 Jun 2008 20:33:21 +0200 Subject: .255 addresses still not usable after all these years? In-Reply-To: <4852F431.8060209@rockynet.com> References: <4852F431.8060209@rockynet.com> Message-ID: On Jun 14, 2008, at 12:26 AM, Mike Lewinski wrote: > David Hubbard wrote: >> I remember back in the day of old hardware and operating >> systems we'd intentionally avoid using .255 IP addresses >> for anything even when the netmask on our side would have >> made it fine, so I just thought I'd try it out for kicks >> today. From two of four ISP's it worked fine, from Verizon >> FIOS and Road Runner commercial, it didn't. So I guess >> that old problem still lingers? > > The TCP/IP stack in Windows XP is broken in this regard, possibly in > Vista as well, though I've yet to have the displeasure of finding > out. I have a router with a .255 loopback IP on it. My Windows XP > hosts cannot SSH to it. The specific error that Putty throws is > "Network error: Cannot assign requested address". > > At least if I ever need to completely protect a device from access > by Windows users, I have a good option :) > > Mike From what I recall, Microsoft's stack was based on the only free one they could afford back in the Trumpet/Winsock days, namely BSD's. It is either dependent on how the stack is integrated, or it simply implies that BSD's stack is(was) also broken (I'd tend to doubt that). Also, Vista's stack was supposed to have been re-developed from scratch, never checked it. Greg VILLAIN From mcgrath at fas.harvard.edu Sat Jun 14 15:40:10 2008 From: mcgrath at fas.harvard.edu (Scott McGrath) Date: Sat, 14 Jun 2008 16:40:10 -0400 Subject: DNS problems to RoadRunner - tcp vs udp In-Reply-To: <4852F3E9.3060707@psg.com> References: <61b6fbec0806131111u77606e1bu90bcd102c3217fb4@mail.gmail.com> <4852B91F.8090205@aset.com> <4852F3E9.3060707@psg.com> Message-ID: <48542CAA.5010503@fas.harvard.edu> Not to toss flammables onto the pyre. BUT there is a large difference from what the RFC's allow and common practice. In our shop TCP is blocked to all but authoratative secondaries as TCP is sinply too easy to DoS a DNS server with. We simply don't need a few thousand drones clogging the TCP connection table all trying to do zone transfers ( yes it happened and logs show drones are still trying ) For a long time there has been a effective practice of UDP == resolution requests TCP == zone transfers It would have been better if a separate port had been defined for zone transfers as that would obviate the need for a application layer gateway to allow TCP transfers so that zone transfers can be blocked and resolution requests allowed for now all TCP is blocked. Now just because someone has a bright idea they drag out a 20 y/o RFC and say SEE, SEE you must allow this because the RFC says so all the while ignoring the 20 years of operational discipline that RFC was written when the internet was like the quad at college everyone knew one and other and we were all working towards a common goal of interoperability and open systems , These days the net is more like a seedy waterfront after midnight where criminal gangs are waiting to ambush the unwary and consequently networks need to be operated from that standpoint. At the University networking level it is extremely difficult as we need to maintain a open network as much as possible but protect our infrastructure services so that they have 5 nines of availability back in the day a few small hosts would serve DNS nicely and we did not have people trying to take them down and/or infecting local hosts and attempting DHCP starvation attacks. And no we are not at the 5 nines level but we are working on it. - Scott Randy Bush wrote: >> If my server responded to TCP queries from anyone other than a secondary >> server, I would be VERY concerned. >> > > you may want to read the specs > > randy > From jeroen at unfix.org Sat Jun 14 15:47:47 2008 From: jeroen at unfix.org (Jeroen Massar) Date: Sat, 14 Jun 2008 22:47:47 +0200 Subject: DNS problems to RoadRunner - tcp vs udp In-Reply-To: <48542CAA.5010503@fas.harvard.edu> References: <61b6fbec0806131111u77606e1bu90bcd102c3217fb4@mail.gmail.com> <4852B91F.8090205@aset.com> <4852F3E9.3060707@psg.com> <48542CAA.5010503@fas.harvard.edu> Message-ID: <48542E73.9070109@spaghetti.zurich.ibm.com> Scott McGrath wrote: [..] > For a long time there has been a effective practice of > > UDP == resolution requests > TCP == zone transfers WRONG. TCP is there as a fallback when the answer of the question is too large. Zone transfer you can limit in your software. If you can't configure your dns servers properly then don't run DNS. Also note that botnets have much more effective ways of taking you out. And sometimes domains actually require TCP because there are too many records for a label eg http://stupid.domain.name/node/651 If you are thus blocking TCP for DNS resolution you suddenly where blocking google and thus for some people "The Internet". Also see: http://homepages.tesco.net/J.deBoynePollard/FGA/dns-edns0-and-firewalls.html (Which was the second hit for google(EDNS0) after a link to RFC2671) Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 187 bytes Desc: OpenPGP digital signature URL: From cmarlatt at rxsec.com Sat Jun 14 15:47:32 2008 From: cmarlatt at rxsec.com (Chris Marlatt) Date: Sat, 14 Jun 2008 16:47:32 -0400 Subject: [NANOG] Introducing latency for testing? In-Reply-To: References: <1b5c1c150805021312h33ba56dcxd448b2b1bb206d2e@mail.gmail.com> Message-ID: <48542E64.3000704@rxsec.com> Frank Bulk - iNAME wrote: > It's not free, but at a recent trade show I did see what appeared to be an > affordable unit from Apposite Technologies (apposite-tech.com). And there's > always PacketStorm. > > Frank > > -----Original Message----- > From: Mike Lyon [mailto:mike.lyon at gmail.com] > Sent: Friday, May 02, 2008 3:13 PM > To: NANOG > Subject: [NANOG] Introducing latency for testing? > > So I want to mimic some latency in a test network for DB replication. > I am wondering what other's have used for this? Obviously, the best > way to would be to actually have one box across the US or across the > globe to actually test against but what if you don't have that? Are > there any GPL software router solutions that would allow you to tweak > the latency in between the two test boxes? > > Thanks in advance. > > -Mike > > _______________________________________________ > NANOG mailing list > NANOG at nanog.org > http://mailman.nanog.org/mailman/listinfo/nanog > > IIRC ipfw can do this using dummynet and the delay directive. Regards, Chris From joelja at bogus.com Sat Jun 14 16:08:25 2008 From: joelja at bogus.com (Joel Jaeggli) Date: Sat, 14 Jun 2008 14:08:25 -0700 Subject: [NANOG] Introducing latency for testing? In-Reply-To: <48542E64.3000704@rxsec.com> References: <1b5c1c150805021312h33ba56dcxd448b2b1bb206d2e@mail.gmail.com> <48542E64.3000704@rxsec.com> Message-ID: <48543349.7060400@bogus.com> Chris Marlatt wrote: > Frank Bulk - iNAME wrote: >> It's not free, but at a recent trade show I did see what appeared to >> be an >> affordable unit from Apposite Technologies (apposite-tech.com). And >> there's >> always PacketStorm. >> >> Frank >> >> -----Original Message----- >> From: Mike Lyon [mailto:mike.lyon at gmail.com] Sent: Friday, May 02, >> 2008 3:13 PM >> To: NANOG >> Subject: [NANOG] Introducing latency for testing? >> >> So I want to mimic some latency in a test network for DB replication. >> I am wondering what other's have used for this? Obviously, the best >> way to would be to actually have one box across the US or across the >> globe to actually test against but what if you don't have that? > boxes across the globe have the property of being somewhat less deterministic than you'd like if you need repeatability. > IIRC ipfw can do this using dummynet and the delay directive. it will also do jitter and drop rate... to wit, it's exactly what is need here. there are analogous tools for iptables based platforms. From mcgrath at fas.harvard.edu Sat Jun 14 16:18:38 2008 From: mcgrath at fas.harvard.edu (Scott McGrath) Date: Sat, 14 Jun 2008 17:18:38 -0400 Subject: DNS problems to RoadRunner - tcp vs udp In-Reply-To: <48542E73.9070109@spaghetti.zurich.ibm.com> References: <61b6fbec0806131111u77606e1bu90bcd102c3217fb4@mail.gmail.com> <4852B91F.8090205@aset.com> <4852F3E9.3060707@psg.com> <48542CAA.5010503@fas.harvard.edu> <48542E73.9070109@spaghetti.zurich.ibm.com> Message-ID: <485435AE.8060609@fas.harvard.edu> There is no call for insults on this list - Rather thought this list was about techincal discussions affecting all of us and keeping DNS alive for the majority of our customers certainly qualifies. We/I am more than aware of the DNS mechanisms and WHY there are there trouble is NO DNS server can handle directed TCP attacks even the root servers crumbled under directed botnet activity and we have taken the decision to accept some collateral damage in order to keep services available. We are a well connected university network with multi-gigabit ingress and egress with 10G on Abilene so we try to protect the internet from attacks originating within our borders AND we really feel the full wrath of botnets as we do not have a relatively slow WAN link to buffer the effects. Yes - we are blocking TCP too many problems with drone armies and we started about a year ago when our DNS servers became unresponsive for no apparent reason. Investigation showed TCP flows of hundreds of megabits/sec and connection table overflows from tens of thousands of bots all trying to simultaneously do zone transfers and failing tried active denial systems and shunning with limited effectiveness. We are well aware of the host based mechanisms to control zone information, Trouble is with TCP if you can open the connection you can DoS so we don't allow the connection to be opened and this is enforced at the network level where we can drop at wire speed. Open to better ideas but if you look at the domain in my email address you will see we are a target for hostile activity just so someone can 'make their bones'. Also recall we have a comittment to openess so we would like to make TCP services available but until we have effective DNS DoS mitigation which can work with 10Gb links It's not going to happen. - Scott Jeroen Massar wrote: > Scott McGrath wrote: > [..] >> For a long time there has been a effective practice of >> >> UDP == resolution requests >> TCP == zone transfers > > WRONG. TCP is there as a fallback when the answer of the question is > too large. Zone transfer you can limit in your software. If you can't > configure your dns servers properly then don't run DNS. > Also note that botnets have much more effective ways of taking you out. > > And sometimes domains actually require TCP because there are too many > records for a label eg http://stupid.domain.name/node/651 > If you are thus blocking TCP for DNS resolution you suddenly where > blocking google and thus for some people "The Internet". > > Also see: > http://homepages.tesco.net/J.deBoynePollard/FGA/dns-edns0-and-firewalls.html > > > (Which was the second hit for google(EDNS0) after a link to RFC2671) > > Greets, > Jeroen > From simon.leinen at switch.ch Sat Jun 14 16:23:44 2008 From: simon.leinen at switch.ch (Simon Leinen) Date: Sat, 14 Jun 2008 23:23:44 +0200 Subject: DNS problems to RoadRunner - tcp vs udp In-Reply-To: <4852C1CE.2020804@aset.com> (Jon Kibler's message of "Fri, 13 Jun 2008 14:51:58 -0400") References: <20080613182628.CBCB345048@ptavv.es.net> <4852C1CE.2020804@aset.com> Message-ID: Jon Kibler writes: > Also, other than "That's what the RFCs call for," why use TCP for > data exchange instead of larger UDP packets? TCP is more robust for large (>Path MTU) data transfers, and less prone to spoofing. A few months ago I sent a message to SwiNOG (like NANOG only less North American and more Swiss) about this topic, trying to explain some of the tradeoffs: http://www.mail-archive.com/swinog at lists.swinog.ch/msg02612.html Mostly I think that people "approaching this from a security perspective only" often forget that by fencing in the(ir idea of the) current status quo, they often prevent beneficial evolution of protocols as well, contributing to the Internet's "ossification". -- Simon. From jeroen at unfix.org Sat Jun 14 16:54:49 2008 From: jeroen at unfix.org (Jeroen Massar) Date: Sat, 14 Jun 2008 23:54:49 +0200 Subject: DNS problems to RoadRunner - tcp vs udp In-Reply-To: <485435AE.8060609@fas.harvard.edu> References: <61b6fbec0806131111u77606e1bu90bcd102c3217fb4@mail.gmail.com> <4852B91F.8090205@aset.com> <4852F3E9.3060707@psg.com> <48542CAA.5010503@fas.harvard.edu> <48542E73.9070109@spaghetti.zurich.ibm.com> <485435AE.8060609@fas.harvard.edu> Message-ID: <48543E29.70809@spaghetti.zurich.ibm.com> Scott McGrath wrote: > > There is no call for insults on this list Insults? Where? If you feel insulted by any of the comments made on this list by people, then you probably are indeed on the wrong list. But that is just me. > - Rather thought this list was > about techincal discussions affecting all of us and keeping DNS alive > for the majority of our customers certainly qualifies. [..blabber about DNS attacks over TCP..] If I where a botnet herder and I had to take out your site and I was going to pick TCP for some magical reason then I would not care about your DNS servers, I would just hit your webservers, hard. I mean just the 'index.html' (http://www.harvard.edu/) is 24Kb, that is excluding pictures and there is bound to be larger data there which you are going to send and the bots only have to say "ACK" to once in a while. Multiply that by say a small botnet of 1M hosts, each just requests that 24Kb file. You will have a million flows and won't have any way to rate limit that or control it. Your link was already full trying to send it back to the clients and next to that your server was probably not able to process it in the first place. Simple, effective, nothing you can do about it, except get way and way more hardware. If somebody wants to take you out, they will take you out. Just get one other box with 10GE (not too hard to do) or just get a million of them with a little bit of connectivity (which is quite easy apparently)... > We/I am more than aware of the DNS mechanisms and WHY there are there > trouble is NO DNS server can handle directed TCP attacks even the root > servers crumbled under directed botnet activity and we have taken the > decision to accept some collateral damage in order to keep services > available. "The root servers crumbled" wow, I must have missed somebody taking out all the 13 separate and then individually anycasted root servers. Which btw only do UDP as currently '.' is still small enough. $ dig @a.root-servers.net. . NS +tcp [..] ;; Query time: 95 msec ;; SERVER: 2001:503:ba3e::2:30#53(2001:503:ba3e::2:30) ;; WHEN: Sat Jun 14 23:45:52 2008 ;; MSG SIZE rcvd: 604 That is only 1 packet to 1 packet, still only 500 bytes. While your little webserver would generate 24kb for that same sequence. > We are a well connected university network with > multi-gigabit ingress and egress with 10G on Abilene so we try to > protect the internet from attacks originating within our borders AND we > really feel the full wrath of botnets as we do not have a relatively > slow WAN link to buffer the effects. The whole point generally of botnets is just the Denial of Service (DoS), if that is because your link is full or the upstreams link is full or because the service can't service clients anymore. But clearly, as you are blocking TCP-DNS you are DoSing yourself already, so the botherders win. Also note that Abilene internally might be 10G and in quite some places even 40G, but you still have to hand it off to the rest of the world and those will count as those 'slow WAN' links that you think everybody else on this planet is behind. (Hint: 10GE is kinda the minimum for most reasonably sized ISP's) > Yes - we are blocking TCP too many problems with drone armies and we > started about a year ago when our DNS servers became unresponsive for no > apparent reason. Investigation showed TCP flows of hundreds of > megabits/sec and connection table overflows from tens of thousands of > bots all trying to simultaneously do zone transfers and failing tried > active denial systems and shunning with limited effectiveness. How is a failed AXFR going to generate a lot of traffic, unless they are repeating themselves over and over and over again? Thus effectively just packeting you? Also, are you talking about Recursive or Authoritive DNS servers here? Where those bots on your network, or where they remote? > We are well aware of the host based mechanisms to control zone > information, Trouble is with TCP if you can open the connection you can > DoS so we don't allow the connection to be opened and this is enforced > at the network level where we can drop at wire speed. Do you mean that the hosts which do TCP are allowed to do transfers or not? As in the latter case they can't generate big answers, they just get 1 packet back and then end then FIN. Note also, that if they are simply trying to overload your hosts, UDP is much more effective in doing that already and you have that hole wide open apparently otherwise you wouldn't have DNS. > Open to better > ideas but if you look at the domain in my email address you will see we > are a target for hostile activity just so someone can 'make their bones'. It probably has nothing to do with the domain name, it more likely has something to do with certain services that are available or provided on your network. > Also recall we have a comittment to openess so we would like to make TCP > services available but until we have effective DNS DoS mitigation which > can work with 10Gb links It's not going to happen. You think that 10Gb is a 'fat link', amusing ;) There are various vendors, most likely also reading on this list, who can be more than helpful in providing you with all kinds of bad, but also a couple of good solutions to most networking issues that you are apparently having. But the biggest issue you seem to have is not knowing what the DoS kiddies want to take out and why they want to take it out. Greets, Jeroen PS: You do know that an "NS" record is not allowed to point to a CNAME I hope? (NS3.harvard.edu CNAME ns3.br.harvard.edu. RFC1912 2.4 ;) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 187 bytes Desc: OpenPGP digital signature URL: From randy at psg.com Sat Jun 14 16:58:25 2008 From: randy at psg.com (Randy Bush) Date: Sun, 15 Jun 2008 06:58:25 +0900 Subject: DNS problems to RoadRunner - tcp vs udp In-Reply-To: References: <20080613182628.CBCB345048@ptavv.es.net> <4852C1CE.2020804@aset.com> Message-ID: <48543F01.5060501@psg.com> > Mostly I think that people "approaching this from a security > perspective only" often forget that by fencing in the(ir idea of the) > current status quo, they often prevent beneficial evolution of > protocols as well, contributing to the Internet's "ossification". folk do not always get the implications of the internet being a 'disruptive technology,' and that this is a good thing which needs to be preserved and even enhanced. they use skype and want to block ports. it's rampant. the old siliness of blocking tcp/53 is just one of the corner cases that keeps popping up publicly. try using this year's crop of innovative apps from behind some corporate firewall. packet/port xenophobia overrides the users' desire to be productive every time. it departments are paid to minimize cost and risk, not maximize workers' productivity. randy From christian at visr.org Sat Jun 14 17:20:05 2008 From: christian at visr.org (Christian) Date: Sat, 14 Jun 2008 18:20:05 -0400 Subject: Bandcon Transport Services.. Message-ID: <9b62cf2f0806141520j643d40dftd5d12af9f22bf47a@mail.gmail.com> Anyone here use Bandcon's transport services? Positive/Negative experiences, any feedback would be helpful.. Thanks ck From sean at donelan.com Sat Jun 14 18:43:46 2008 From: sean at donelan.com (Sean Donelan) Date: Sat, 14 Jun 2008 19:43:46 -0400 (EDT) Subject: DNS problems to RoadRunner - tcp vs udp In-Reply-To: <485435AE.8060609@fas.harvard.edu> References: <61b6fbec0806131111u77606e1bu90bcd102c3217fb4@mail.gmail.com> <4852B91F.8090205@aset.com> <4852F3E9.3060707@psg.com> <48542CAA.5010503@fas.harvard.edu> <48542E73.9070109@spaghetti.zurich.ibm.com> <485435AE.8060609@fas.harvard.edu> Message-ID: On Sat, 14 Jun 2008, Scott McGrath wrote: > Also recall we have a comittment to openess so we would like to make TCP > services available but until we have effective DNS DoS mitigation which can > work with 10Gb links It's not going to happen. I feel your pain, but I think there may be a slight mis-analysis of the situation. However I may be mistaken, given the lack of details. The 10Gb really doesn't have much to do with tcp-state-table problems. Any network with a large user population probably should have separate DNS servers for their authoritative zones answering the Internet at-large and their recursive resolvers serving their user population. DNS recursive resolvers may not need to answer unsolicited queries from the Internet at large. It may make sense to keep those servers behind stateful packet gateways, and only allow both UDP and TCP responses from the Internet to UDP and TCP queries made by the local, authorized users. Because you don't know what Answer all the other DNS servers may give, including a Truncated answer, recursive resolvers must be able to use TCP to send queries to the Internet at large, and receive TCP queries from its local, authorized user population. If your own local users are DOSing your own DNS recursive resolvers, hopefully that's your own problem. A DNS authoritative server may only need to answer unsolicited UDP queries from the Internet at large. Because DNS clients (stub, resolvers) must send a query as UDP first, and may use TCP if the Answer has the truncated bit set, an authoritative name server which knows all its answers will always fit in the minimum DNS Answer and never sets the truncated bit shouldn't get a TCP DNS query. RFC1112 says DNS servers should answer unsolicited TCP DNS queries anyway, but its not a MUST and it may rate limit its TCP answers. Given those constraints, it may make sense for DNS authoritative servers to limit TCP, either with an ACL or rate-limit the TCP/SYNs. But its only a medium term solution. DNS answers are growing. Someday those DNS authoritative servers probaly will need to send a large DNS Answer. But that is under the control of the local DNS administrator. So hopefully he or she will know when the DNS server breaks, and will fix it then. Also, modern TCP/IP stacks and modern name server implementations don't have as many tcp-state-table issues as they did at the beginning of the decade. Any DOS attack based on TCP would disrupt HTTP/Web servers just as much as TCP/DNS servers. So many of the same mitigation techniques (and attacks) for Web servers may be applicable to DNS servers. So briefly 1. Separate your authoritative and recursive name servers 2. Recursive name servers should only get replies to their own DNS queries from the Internet, they can use both UDP and TCP 3. Recursive name servers should only get queries from their own user population, they can use both UDP and TCP 4. Authoritative servers may only need to answer UDP queries from the Internet, if they never truncates its Answers. But the DNS administrator should plan what to do when its Answers get too large. Most DNS servers don't provide good alerts to DNS administrators doing stupid things, like sending big DNS answers while blocking TCP. I tried to capture some of these ideas in some ACLs From mike at rockynet.com Sat Jun 14 19:45:25 2008 From: mike at rockynet.com (Mike Lewinski) Date: Sat, 14 Jun 2008 18:45:25 -0600 Subject: DNS problems to RoadRunner - tcp vs udp In-Reply-To: References: <61b6fbec0806131111u77606e1bu90bcd102c3217fb4@mail.gmail.com> <4852B91F.8090205@aset.com> <4852F3E9.3060707@psg.com> <48542CAA.5010503@fas.harvard.edu> <48542E73.9070109@spaghetti.zurich.ibm.com> <485435AE.8060609@fas.harvard.edu> Message-ID: <48546625.6040301@rockynet.com> Sean Donelan wrote: > 1. Separate your authoritative and recursive name servers > 2. Recursive name servers should only get replies to their own DNS > queries from the Internet, they can use both UDP and TCP We've just completed a project to separate our authoritative and recursive servers and I have a couple notes... 1) For the recursive-only, we're using a combination of BIND's "query-source address a.b.c.d" and "listen-on e.f.g.h" in the hopes of providing some additional measure of protection against cache poisoning. The "listen-on" IPs are ACL'd at the borders so non-clients cannot get ANY packets to them. The "query-source address" itself doesn't appear in the "listen-on" list either and won't respond to queries. I know this isn't foolproof, but it probably raises the bar slightly against off-net poisoning attempts. 2) The biggest drawback to separation after years of service is that customers have come to expect their DNS changes are propagated instantly when they are on-net. This turns out to be more of an annoyance to us than our customers, since our zone is probably the most frequently updated. 3) I've gone so far as to remove the root hint zone from our auth-only boxes, again out of paranoia ("recursion no" does the trick, this is just an extra bit of insurance against someone flipping that bit due to a lack of understanding of the architecture). There is one third party we have to use an 'also-notify' by IP address in this case for their zone. Mike From nanog at daork.net Sat Jun 14 20:12:39 2008 From: nanog at daork.net (Nathan Ward) Date: Sun, 15 Jun 2008 13:12:39 +1200 Subject: DNS problems to RoadRunner - tcp vs udp In-Reply-To: <48546625.6040301@rockynet.com> References: <61b6fbec0806131111u77606e1bu90bcd102c3217fb4@mail.gmail.com> <4852B91F.8090205@aset.com> <4852F3E9.3060707@psg.com> <48542CAA.5010503@fas.harvard.edu> <48542E73.9070109@spaghetti.zurich.ibm.com> <485435AE.8060609@fas.harvard.edu> <48546625.6040301@rockynet.com> Message-ID: <0683A4A6-5AD2-4E7B-ABC8-F3A394B51696@daork.net> On 15/06/2008, at 12:45 PM, Mike Lewinski wrote: > 2) The biggest drawback to separation after years of service is that > customers have come to expect their DNS changes are propagated > instantly when they are on-net. This turns out to be more of an > annoyance to us than our customers, since our zone is probably the > most frequently updated. If you're running bind for your recursive boxes, `rndc -s flushname ' run against each recursive box should do the trick for bind 9.3.0 upwards. It will flush the cache for that zone only. There was a bug where it wouldn't flush negative caches, but that might be fixed. YMMV, etc. Usual common sense warnings apply. -- Nathan Ward From nanog at daork.net Sat Jun 14 20:33:59 2008 From: nanog at daork.net (Nathan Ward) Date: Sun, 15 Jun 2008 13:33:59 +1200 Subject: DNS problems to RoadRunner - tcp vs udp In-Reply-To: <485435AE.8060609@fas.harvard.edu> References: <61b6fbec0806131111u77606e1bu90bcd102c3217fb4@mail.gmail.com> <4852B91F.8090205@aset.com> <4852F3E9.3060707@psg.com> <48542CAA.5010503@fas.harvard.edu> <48542E73.9070109@spaghetti.zurich.ibm.com> <485435AE.8060609@fas.harvard.edu> Message-ID: <6C1C1472-DC4A-4F2E-A106-0E4EE8544C6F@daork.net> On 15/06/2008, at 9:18 AM, Scott McGrath wrote: > Yes - we are blocking TCP too many problems with drone armies and we > started about a year ago when our DNS servers became unresponsive > for no apparent reason. Investigation showed TCP flows of hundreds > of megabits/sec and connection table overflows from tens of > thousands of bots all trying to simultaneously do zone transfers and > failing tried active denial systems and shunning with limited > effectiveness. > > We are well aware of the host based mechanisms to control zone > information, Trouble is with TCP if you can open the connection you > can DoS so we don't allow the connection to be opened and this is > enforced at the network level where we can drop at wire speed. > Open to better ideas but if you look at the domain in my email > address you will see we are a target for hostile activity just so > someone can 'make their bones'. There's really two problems here - one is packet/bit rate causing problems for your network, that's not necessarily an end system thing. Not really DNS specific, and blocking 53/TCP doesn't really help here as people could just send 53/UDP your way and get the same effect. Connection table overflowing is a bit of a different issue, obvious way to overcome that is to whack a load balancer in there to share the load around. It's not immediately obvious to me why your connection table would be filling up - what state were connections stuck in? Anyway, one thought that comes to me would be to split off UDP and TCP services to different servers - if some TCP attack kills your TCP DNS server you: a) don't have to worry about UDP services failing. b) can turn it off for the duration of the attack, and are no worse off than you are right now, then turn it back on when you see the high volume of SYN messages disappear. c) as TCP DNS service recovery isn't super time critical (I'm assuming this, because you're not running it at all right now) you have time to look at the anatomy of the attack and figure out how to filter it more precisely if possible, instead of simply dropping all TCP. Obviously, you'd want to make sure TCP from your other name servers always goes to the UDP one, etc. etc. -- Nathan Ward From jared at puck.nether.net Sat Jun 14 21:50:11 2008 From: jared at puck.nether.net (Jared Mauch) Date: Sat, 14 Jun 2008 22:50:11 -0400 Subject: [NANOG] Introducing latency for testing? In-Reply-To: References: <1b5c1c150805021312h33ba56dcxd448b2b1bb206d2e@mail.gmail.com> Message-ID: <20080615025011.GJ28147@puck.nether.net> On Sat, Jun 14, 2008 at 01:34:53PM -0500, Frank Bulk - iNAME wrote: > It's not free, but at a recent trade show I did see what appeared to be an > affordable unit from Apposite Technologies (apposite-tech.com). And there's > always PacketStorm. > > Frank > > -----Original Message----- > From: Mike Lyon [mailto:mike.lyon at gmail.com] > Sent: Friday, May 02, 2008 3:13 PM > To: NANOG > Subject: [NANOG] Introducing latency for testing? > > So I want to mimic some latency in a test network for DB replication. > I am wondering what other's have used for this? Obviously, the best > way to would be to actually have one box across the US or across the > globe to actually test against but what if you don't have that? Are > there any GPL software router solutions that would allow you to tweak > the latency in between the two test boxes? There is one interesting box that you can use to simulate the delay at 10GE and do a few other things. http://projects.gtrc.aist.go.jp/gnet/gnet10p3e.html - Jared -- Jared Mauch | pgp key available via finger from jared at puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine. From surfer at mauigateway.com Sat Jun 14 23:13:46 2008 From: surfer at mauigateway.com (Scott Weeks) Date: Sat, 14 Jun 2008 21:13:46 -0700 Subject: .255 addresses still not usable after all these years? Message-ID: <20080614211346.7ACF7DD1@resin15.mta.everyone.net> I don't get it. As I mentioned about a year ago, when we last had this discussion, I have been handing out /23s to DHCP customers for years. No problems. .0 and .255 are not on WAN circuits or anything else, but zero problems for dynamically assigned customers. scott From pdowles at cogentco.com Sun Jun 15 03:12:32 2008 From: pdowles at cogentco.com (Paul Dowles) Date: Sun, 15 Jun 2008 08:12:32 +0000 Subject: NANOG Digest, Vol 5, Issue 33 In-Reply-To: References: Message-ID: <1971309983-1213517558-cardhu_decombobulator_blackberry.rim.net-393915228-@bxe057.bisx.produk.on.blackberry> -----Original Message----- From: nanog-request at nanog.org Date: Sat, 14 Jun 2008 21:54:35 To: Subject: NANOG Digest, Vol 5, Issue 33 Send NANOG mailing list submissions to nanog at nanog.org To subscribe or unsubscribe via the World Wide Web, visit http://mailman.nanog.org/mailman/listinfo/nanog or, via email, send a message with subject or body 'help' to nanog-request at nanog.org You can reach the person managing the list at nanog-owner at nanog.org When replying, please edit your Subject line so it is more specific than "Re: Contents of NANOG digest..." Today's Topics: 1. RE: [NANOG] Introducing latency for testing? (Frank Bulk - iNAME) 2. Re: .255 addresses still not usable after all these years? (Greg VILLAIN) 3. Re: DNS problems to RoadRunner - tcp vs udp (Scott McGrath) 4. Re: DNS problems to RoadRunner - tcp vs udp (Jeroen Massar) 5. Re: [NANOG] Introducing latency for testing? (Chris Marlatt) 6. Re: [NANOG] Introducing latency for testing? (Joel Jaeggli) 7. Re: DNS problems to RoadRunner - tcp vs udp (Scott McGrath) 8. Re: DNS problems to RoadRunner - tcp vs udp (Simon Leinen) 9. Re: DNS problems to RoadRunner - tcp vs udp (Jeroen Massar) ---------------------------------------------------------------------- Message: 1 Date: Sat, 14 Jun 2008 13:34:53 -0500 From: "Frank Bulk - iNAME" Subject: RE: [NANOG] Introducing latency for testing? To: "'Mike Lyon'" , "NANOG" Message-ID: Content-Type: text/plain; charset="us-ascii" It's not free, but at a recent trade show I did see what appeared to be an affordable unit from Apposite Technologies (apposite-tech.com). And there's always PacketStorm. Frank -----Original Message----- From: Mike Lyon [mailto:mike.lyon at gmail.com] Sent: Friday, May 02, 2008 3:13 PM To: NANOG Subject: [NANOG] Introducing latency for testing? So I want to mimic some latency in a test network for DB replication. I am wondering what other's have used for this? Obviously, the best way to would be to actually have one box across the US or across the globe to actually test against but what if you don't have that? Are there any GPL software router solutions that would allow you to tweak the latency in between the two test boxes? Thanks in advance. -Mike _______________________________________________ NANOG mailing list NANOG at nanog.org http://mailman.nanog.org/mailman/listinfo/nanog ------------------------------ Message: 2 Date: Sat, 14 Jun 2008 20:33:21 +0200 From: Greg VILLAIN Subject: Re: .255 addresses still not usable after all these years? To: nanog at nanog.org Message-ID: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes On Jun 14, 2008, at 12:26 AM, Mike Lewinski wrote: > David Hubbard wrote: >> I remember back in the day of old hardware and operating >> systems we'd intentionally avoid using .255 IP addresses >> for anything even when the netmask on our side would have >> made it fine, so I just thought I'd try it out for kicks >> today. From two of four ISP's it worked fine, from Verizon >> FIOS and Road Runner commercial, it didn't. So I guess >> that old problem still lingers? > > The TCP/IP stack in Windows XP is broken in this regard, possibly in > Vista as well, though I've yet to have the displeasure of finding > out. I have a router with a .255 loopback IP on it. My Windows XP > hosts cannot SSH to it. The specific error that Putty throws is > "Network error: Cannot assign requested address". > > At least if I ever need to completely protect a device from access > by Windows users, I have a good option :) > > Mike From what I recall, Microsoft's stack was based on the only free one they could afford back in the Trumpet/Winsock days, namely BSD's. It is either dependent on how the stack is integrated, or it simply implies that BSD's stack is(was) also broken (I'd tend to doubt that). Also, Vista's stack was supposed to have been re-developed from scratch, never checked it. Greg VILLAIN ------------------------------ Message: 3 Date: Sat, 14 Jun 2008 16:40:10 -0400 From: Scott McGrath Subject: Re: DNS problems to RoadRunner - tcp vs udp To: Randy Bush Cc: nanog at merit.edu Message-ID: <48542CAA.5010503 at fas.harvard.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Not to toss flammables onto the pyre. BUT there is a large difference from what the RFC's allow and common practice. In our shop TCP is blocked to all but authoratative secondaries as TCP is sinply too easy to DoS a DNS server with. We simply don't need a few thousand drones clogging the TCP connection table all trying to do zone transfers ( yes it happened and logs show drones are still trying ) For a long time there has been a effective practice of UDP == resolution requests TCP == zone transfers It would have been better if a separate port had been defined for zone transfers as that would obviate the need for a application layer gateway to allow TCP transfers so that zone transfers can be blocked and resolution requests allowed for now all TCP is blocked. Now just because someone has a bright idea they drag out a 20 y/o RFC and say SEE, SEE you must allow this because the RFC says so all the while ignoring the 20 years of operational discipline that RFC was written when the internet was like the quad at college everyone knew one and other and we were all working towards a common goal of interoperability and open systems , These days the net is more like a seedy waterfront after midnight where criminal gangs are waiting to ambush the unwary and consequently networks need to be operated from that standpoint. At the University networking level it is extremely difficult as we need to maintain a open network as much as possible but protect our infrastructure services so that they have 5 nines of availability back in the day a few small hosts would serve DNS nicely and we did not have people trying to take them down and/or infecting local hosts and attempting DHCP starvation attacks. And no we are not at the 5 nines level but we are working on it. - Scott Randy Bush wrote: >> If my server responded to TCP queries from anyone other than a secondary >> server, I would be VERY concerned. >> > > you may want to read the specs > > randy > ------------------------------ Message: 4 Date: Sat, 14 Jun 2008 22:47:47 +0200 From: Jeroen Massar Subject: Re: DNS problems to RoadRunner - tcp vs udp To: Scott McGrath Cc: nanog at merit.edu Message-ID: <48542E73.9070109 at spaghetti.zurich.ibm.com> Content-Type: text/plain; charset="iso-8859-1" Scott McGrath wrote: [..] > For a long time there has been a effective practice of > > UDP == resolution requests > TCP == zone transfers WRONG. TCP is there as a fallback when the answer of the question is too large. Zone transfer you can limit in your software. If you can't configure your dns servers properly then don't run DNS. Also note that botnets have much more effective ways of taking you out. And sometimes domains actually require TCP because there are too many records for a label eg http://stupid.domain.name/node/651 If you are thus blocking TCP for DNS resolution you suddenly where blocking google and thus for some people "The Internet". Also see: http://homepages.tesco.net/J.deBoynePollard/FGA/dns-edns0-and-firewalls.html (Which was the second hit for google(EDNS0) after a link to RFC2671) Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 187 bytes Desc: OpenPGP digital signature Url : http://mailman.nanog.org/pipermail/nanog/attachments/20080614/8dc85bfe/attachment-0001.pgp ------------------------------ Message: 5 Date: Sat, 14 Jun 2008 16:47:32 -0400 From: Chris Marlatt Subject: Re: [NANOG] Introducing latency for testing? To: frnkblk at iname.com Cc: NANOG Message-ID: <48542E64.3000704 at rxsec.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Frank Bulk - iNAME wrote: > It's not free, but at a recent trade show I did see what appeared to be an > affordable unit from Apposite Technologies (apposite-tech.com). And there's > always PacketStorm. > > Frank > > -----Original Message----- > From: Mike Lyon [mailto:mike.lyon at gmail.com] > Sent: Friday, May 02, 2008 3:13 PM > To: NANOG > Subject: [NANOG] Introducing latency for testing? > > So I want to mimic some latency in a test network for DB replication. > I am wondering what other's have used for this? Obviously, the best > way to would be to actually have one box across the US or across the > globe to actually test against but what if you don't have that? Are > there any GPL software router solutions that would allow you to tweak > the latency in between the two test boxes? > > Thanks in advance. > > -Mike > > _______________________________________________ > NANOG mailing list > NANOG at nanog.org > http://mailman.nanog.org/mailman/listinfo/nanog > > IIRC ipfw can do this using dummynet and the delay directive. Regards, Chris ------------------------------ Message: 6 Date: Sat, 14 Jun 2008 14:08:25 -0700 From: Joel Jaeggli Subject: Re: [NANOG] Introducing latency for testing? To: Chris Marlatt Cc: NANOG Message-ID: <48543349.7060400 at bogus.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Chris Marlatt wrote: > Frank Bulk - iNAME wrote: >> It's not free, but at a recent trade show I did see what appeared to >> be an >> affordable unit from Apposite Technologies (apposite-tech.com). And >> there's >> always PacketStorm. >> >> Frank >> >> -----Original Message----- >> From: Mike Lyon [mailto:mike.lyon at gmail.com] Sent: Friday, May 02, >> 2008 3:13 PM >> To: NANOG >> Subject: [NANOG] Introducing latency for testing? >> >> So I want to mimic some latency in a test network for DB replication. >> I am wondering what other's have used for this? Obviously, the best >> way to would be to actually have one box across the US or across the >> globe to actually test against but what if you don't have that? > boxes across the globe have the property of being somewhat less deterministic than you'd like if you need repeatability. > IIRC ipfw can do this using dummynet and the delay directive. it will also do jitter and drop rate... to wit, it's exactly what is need here. there are analogous tools for iptables based platforms. ------------------------------ Message: 7 Date: Sat, 14 Jun 2008 17:18:38 -0400 From: Scott McGrath Subject: Re: DNS problems to RoadRunner - tcp vs udp To: Jeroen Massar Cc: nanog at merit.edu Message-ID: <485435AE.8060609 at fas.harvard.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed There is no call for insults on this list - Rather thought this list was about techincal discussions affecting all of us and keeping DNS alive for the majority of our customers certainly qualifies. We/I am more than aware of the DNS mechanisms and WHY there are there trouble is NO DNS server can handle directed TCP attacks even the root servers crumbled under directed botnet activity and we have taken the decision to accept some collateral damage in order to keep services available. We are a well connected university network with multi-gigabit ingress and egress with 10G on Abilene so we try to protect the internet from attacks originating within our borders AND we really feel the full wrath of botnets as we do not have a relatively slow WAN link to buffer the effects. Yes - we are blocking TCP too many problems with drone armies and we started about a year ago when our DNS servers became unresponsive for no apparent reason. Investigation showed TCP flows of hundreds of megabits/sec and connection table overflows from tens of thousands of bots all trying to simultaneously do zone transfers and failing tried active denial systems and shunning with limited effectiveness. We are well aware of the host based mechanisms to control zone information, Trouble is with TCP if you can open the connection you can DoS so we don't allow the connection to be opened and this is enforced at the network level where we can drop at wire speed. Open to better ideas but if you look at the domain in my email address you will see we are a target for hostile activity just so someone can 'make their bones'. Also recall we have a comittment to openess so we would like to make TCP services available but until we have effective DNS DoS mitigation which can work with 10Gb links It's not going to happen. - Scott Jeroen Massar wrote: > Scott McGrath wrote: > [..] >> For a long time there has been a effective practice of >> >> UDP == resolution requests >> TCP == zone transfers > > WRONG. TCP is there as a fallback when the answer of the question is > too large. Zone transfer you can limit in your software. If you can't > configure your dns servers properly then don't run DNS. > Also note that botnets have much more effective ways of taking you out. > > And sometimes domains actually require TCP because there are too many > records for a label eg http://stupid.domain.name/node/651 > If you are thus blocking TCP for DNS resolution you suddenly where > blocking google and thus for some people "The Internet". > > Also see: > http://homepages.tesco.net/J.deBoynePollard/FGA/dns-edns0-and-firewalls.html > > > (Which was the second hit for google(EDNS0) after a link to RFC2671) > > Greets, > Jeroen > ------------------------------ Message: 8 Date: Sat, 14 Jun 2008 23:23:44 +0200 From: Simon Leinen Subject: Re: DNS problems to RoadRunner - tcp vs udp To: Jon.Kibler at aset.com Cc: nanog at merit.edu Message-ID: Content-Type: text/plain; charset=us-ascii Jon Kibler writes: > Also, other than "That's what the RFCs call for," why use TCP for > data exchange instead of larger UDP packets? TCP is more robust for large (>Path MTU) data transfers, and less prone to spoofing. A few months ago I sent a message to SwiNOG (like NANOG only less North American and more Swiss) about this topic, trying to explain some of the tradeoffs: http://www.mail-archive.com/swinog at lists.swinog.ch/msg02612.html Mostly I think that people "approaching this from a security perspective only" often forget that by fencing in the(ir idea of the) current status quo, they often prevent beneficial evolution of protocols as well, contributing to the Internet's "ossification". -- Simon. ------------------------------ Message: 9 Date: Sat, 14 Jun 2008 23:54:49 +0200 From: Jeroen Massar Subject: Re: DNS problems to RoadRunner - tcp vs udp To: Scott McGrath Cc: nanog at merit.edu Message-ID: <48543E29.70809 at spaghetti.zurich.ibm.com> Content-Type: text/plain; charset="iso-8859-1" Scott McGrath wrote: > > There is no call for insults on this list Insults? Where? If you feel insulted by any of the comments made on this list by people, then you probably are indeed on the wrong list. But that is just me. > - Rather thought this list was > about techincal discussions affecting all of us and keeping DNS alive > for the majority of our customers certainly qualifies. [..blabber about DNS attacks over TCP..] If I where a botnet herder and I had to take out your site and I was going to pick TCP for some magical reason then I would not care about your DNS servers, I would just hit your webservers, hard. I mean just the 'index.html' (http://www.harvard.edu/) is 24Kb, that is excluding pictures and there is bound to be larger data there which you are going to send and the bots only have to say "ACK" to once in a while. Multiply that by say a small botnet of 1M hosts, each just requests that 24Kb file. You will have a million flows and won't have any way to rate limit that or control it. Your link was already full trying to send it back to the clients and next to that your server was probably not able to process it in the first place. Simple, effective, nothing you can do about it, except get way and way more hardware. If somebody wants to take you out, they will take you out. Just get one other box with 10GE (not too hard to do) or just get a million of them with a little bit of connectivity (which is quite easy apparently)... > We/I am more than aware of the DNS mechanisms and WHY there are there > trouble is NO DNS server can handle directed TCP attacks even the root > servers crumbled under directed botnet activity and we have taken the > decision to accept some collateral damage in order to keep services > available. "The root servers crumbled" wow, I must have missed somebody taking out all the 13 separate and then individually anycasted root servers. Which btw only do UDP as currently '.' is still small enough. $ dig @a.root-servers.net. . NS +tcp [..] ;; Query time: 95 msec ;; SERVER: 2001:503:ba3e::2:30#53(2001:503:ba3e::2:30) ;; WHEN: Sat Jun 14 23:45:52 2008 ;; MSG SIZE rcvd: 604 That is only 1 packet to 1 packet, still only 500 bytes. While your little webserver would generate 24kb for that same sequence. > We are a well connected university network with > multi-gigabit ingress and egress with 10G on Abilene so we try to > protect the internet from attacks originating within our borders AND we > really feel the full wrath of botnets as we do not have a relatively > slow WAN link to buffer the effects. The whole point generally of botnets is just the Denial of Service (DoS), if that is because your link is full or the upstreams link is full or because the service can't service clients anymore. But clearly, as you are blocking TCP-DNS you are DoSing yourself already, so the botherders win. Also note that Abilene internally might be 10G and in quite some places even 40G, but you still have to hand it off to the rest of the world and those will count as those 'slow WAN' links that you think everybody else on this planet is behind. (Hint: 10GE is kinda the minimum for most reasonably sized ISP's) > Yes - we are blocking TCP too many problems with drone armies and we > started about a year ago when our DNS servers became unresponsive for no > apparent reason. Investigation showed TCP flows of hundreds of > megabits/sec and connection table overflows from tens of thousands of > bots all trying to simultaneously do zone transfers and failing tried > active denial systems and shunning with limited effectiveness. How is a failed AXFR going to generate a lot of traffic, unless they are repeating themselves over and over and over again? Thus effectively just packeting you? Also, are you talking about Recursive or Authoritive DNS servers here? Where those bots on your network, or where they remote? > We are well aware of the host based mechanisms to control zone > information, Trouble is with TCP if you can open the connection you can > DoS so we don't allow the connection to be opened and this is enforced > at the network level where we can drop at wire speed. Do you mean that the hosts which do TCP are allowed to do transfers or not? As in the latter case they can't generate big answers, they just get 1 packet back and then end then FIN. Note also, that if they are simply trying to overload your hosts, UDP is much more effective in doing that already and you have that hole wide open apparently otherwise you wouldn't have DNS. > Open to better > ideas but if you look at the domain in my email address you will see we > are a target for hostile activity just so someone can 'make their bones'. It probably has nothing to do with the domain name, it more likely has something to do with certain services that are available or provided on your network. > Also recall we have a comittment to openess so we would like to make TCP > services available but until we have effective DNS DoS mitigation which > can work with 10Gb links It's not going to happen. You think that 10Gb is a 'fat link', amusing ;) There are various vendors, most likely also reading on this list, who can be more than helpful in providing you with all kinds of bad, but also a couple of good solutions to most networking issues that you are apparently having. But the biggest issue you seem to have is not knowing what the DoS kiddies want to take out and why they want to take it out. Greets, Jeroen PS: You do know that an "NS" record is not allowed to point to a CNAME I hope? (NS3.harvard.edu CNAME ns3.br.harvard.edu. RFC1912 2.4 ;) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 187 bytes Desc: OpenPGP digital signature Url : http://mailman.nanog.org/pipermail/nanog/attachments/20080614/29473ad3/attachment.pgp ------------------------------ _______________________________________________ NANOG mailing list NANOG at nanog.org http://mailman.nanog.org/mailman/listinfo/nanog End of NANOG Digest, Vol 5, Issue 33 ************************************ From fw at deneb.enyo.de Sun Jun 15 03:12:48 2008 From: fw at deneb.enyo.de (Florian Weimer) Date: Sun, 15 Jun 2008 10:12:48 +0200 Subject: DNS problems to RoadRunner - tcp vs udp In-Reply-To: <4852B91F.8090205@aset.com> (Jon Kibler's message of "Fri, 13 Jun 2008 14:14:55 -0400") References: <61b6fbec0806131111u77606e1bu90bcd102c3217fb4@mail.gmail.com> <4852B91F.8090205@aset.com> Message-ID: <87tzfvce0v.fsf@mid.deneb.enyo.de> * Jon Kibler: >>>From what I have read, public DNS servers should support both UDP and >> TCP queries. TCP queries are often used when a UDP query fails, or if >> the answer is over a certain length. >> > > UDP is used for queries. > > TCP is used for zone transfers. I've seen such claims countless times. 8-( However, you can perform zone file transfers over UFP in some cases (using IXFR), and TCP fallback may happen even if you never respond with packets with the TC bit set. From fw at deneb.enyo.de Sun Jun 15 03:19:56 2008 From: fw at deneb.enyo.de (Florian Weimer) Date: Sun, 15 Jun 2008 10:19:56 +0200 Subject: DNS problems to RoadRunner - tcp vs udp In-Reply-To: (Sean Donelan's message of "Sat, 14 Jun 2008 19:43:46 -0400 (EDT)") References: <61b6fbec0806131111u77606e1bu90bcd102c3217fb4@mail.gmail.com> <4852B91F.8090205@aset.com> <4852F3E9.3060707@psg.com> <48542CAA.5010503@fas.harvard.edu> <48542E73.9070109@spaghetti.zurich.ibm.com> <485435AE.8060609@fas.harvard.edu> Message-ID: <87ej6zcdoz.fsf@mid.deneb.enyo.de> * Sean Donelan: > Any network with a large user population probably should have separate > DNS servers for their authoritative zones answering the Internet > at-large and their recursive resolvers serving their user population. It's not so much a question of network size. You absolutely must use different views if you host DNS for customer domains because there is a race conidtion in the delegation provisioning protocol used by most TLDs (you need to add the domain before you receive the delegation). From jgreco at ns.sol.net Sun Jun 15 08:02:49 2008 From: jgreco at ns.sol.net (Joe Greco) Date: Sun, 15 Jun 2008 08:02:49 -0500 (CDT) Subject: DNS problems to RoadRunner - tcp vs udp In-Reply-To: <485435AE.8060609@fas.harvard.edu> from "Scott McGrath" at Jun 14, 2008 05:18:38 PM Message-ID: <200806151302.m5FD2ngA046141@aurora.sol.net> > There is no call for insults on this list - Rather thought this list was > about techincal discussions affecting all of us and keeping DNS alive > for the majority of our customers certainly qualifies. > > We/I am more than aware of the DNS mechanisms and WHY there are there > trouble is NO DNS server can handle directed TCP attacks even the root > servers crumbled under directed botnet activity and we have taken the > decision to accept some collateral damage in order to keep services > available. We are a well connected university network with > multi-gigabit ingress and egress with 10G on Abilene so we try to > protect the internet from attacks originating within our borders AND we > really feel the full wrath of botnets as we do not have a relatively > slow WAN link to buffer the effects. > > Yes - we are blocking TCP too many problems with drone armies and we > started about a year ago when our DNS servers became unresponsive for no > apparent reason. Investigation showed TCP flows of hundreds of > megabits/sec and connection table overflows from tens of thousands of > bots all trying to simultaneously do zone transfers and failing tried > active denial systems and shunning with limited effectiveness. > > We are well aware of the host based mechanisms to control zone > information, Trouble is with TCP if you can open the connection you can > DoS so we don't allow the connection to be opened and this is enforced > at the network level where we can drop at wire speed. Open to better > ideas but if you look at the domain in my email address you will see we > are a target for hostile activity just so someone can 'make their bones'. > > Also recall we have a comittment to openess so we would like to make TCP > services available but until we have effective DNS DoS mitigation which > can work with 10Gb links It's not going to happen. This could be a real problem. Of course, one solution is to take a shotgun, point it at your foot, and pull the trigger. As you noted, a long history of operational experience suggests that most resolver traffic is UDP, which means that you won't have that many problems from doing this. However, you can kiss that "5 nines of availability" you claim to be interested in goodbye. Nathan Ward and Sean Donelan have covered most of the points I would have made had I written this message earlier. I will also point out, however, that you don't even necessarily need a load balancer to do the tcp/53 screening, but there are a lot of neat and clever things that you could do (some depending on with or without). Given the relatively low level of usage for TCP DNS lookups, plus the fact that it ought to be trivial to automatically identify hosts that are doing TCP things that they shouldn't be doing (one zone transfer request might be a reasonable thing, as many old-timers might do that sort of thing, but won't try repeatedly if the server refuses), it kind of mystifies me as to why you seem to imply that this is so difficult. For example, it only took a few minutes to come up with this, for FreeBSD, which takes advantage of the radix table support in ipfw. #! /bin/sh - grep -i axfr /var/log/messages | grep "zone transfer .* denied" | ( while read a b c d e f g h i j k l m n; do g=`echo "${g}" | sed 's:#.*::'` # Maybe do some other processing ... a bad example: log it # echo noticed "${g}" "${j}" | logger -p info -t protector # Put out the IP's we want to consider filtering echo "${g}" done ) | sort | uniq -c | ( while read a b; do if [ "${a}" -gt 3 ]; then 2> /dev/null ipfw table 1 add "${b}"/32 && (echo banned "${b}" "${a}" | logger -p warning -t protector) fi done ) Needs to have a rule like this installed in the system firewall table: % ipfw add [nnn] deny tcp from table\(1\) to me 53 I think a real solution would be more sophisticated than this, but it's a starting point. This sort of thing limits "collateral damage" to hosts that have attempted an unreasonable number of zone transfers, which is still unpleasant, but is less likely to break legitimate uses. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From mpalmer at hezmatt.org Sun Jun 15 09:01:21 2008 From: mpalmer at hezmatt.org (Matt Palmer) Date: Mon, 16 Jun 2008 00:01:21 +1000 Subject: Single IP routing problems through Level3 Message-ID: <20080615140121.GM9702@hezmatt.org> We're seeing some really weird issues with connections that go through / to Level3 IP space. Basically, certain "pairs" of IPs (particular L3 IPs coupled with particular IPs of ours) have dodgy/nonexistent connectivity, but if you change the IP at either end everything's hunky dory. I've sniffed (from both ends) pings going from a host in L3 space to our end and seen the pings arrive at our end and head back in the direction of L3, but they never get to their destination. Traceroutes from L3 stop at the next-to-last hop, while traceroutes back get to the hop before L3 space and stop. All of this behaviour is source/dest *pair* specific -- if I ping/traceroute from another address (in the same netblock as the problematic IP, so all the same equipment is involved) at either end, or to another address (again, same netblock) at either end, it all works again. I've got two questions: 1) Has anyone else seen similar behaviour from L3 (or other providers, even), so I know I'm not going mad? 2) What sort of configuration problem or software bug would cause this sort of problem to occur? If it was an IP blacklist (or even a block routing issue) anywhere along the line, surely it wouldn't be sensitive to changing the other end's address to another one in the same /24? Any insight/anecdotes/etc would be greatly appreciated, as it's starting to do my head in. Just knowing I'm not alone with this insanity would be nice at this point. If it makes any difference, the blocks I'm working from at my end are Internap, in 74.201.254.0/23 (we don't have all of it, just most of it), while the far end is 8.12.35.0/24. - Matt From rubensk at gmail.com Sun Jun 15 09:12:25 2008 From: rubensk at gmail.com (Rubens Kuhl Jr.) Date: Sun, 15 Jun 2008 11:12:25 -0300 Subject: Single IP routing problems through Level3 In-Reply-To: <20080615140121.GM9702@hezmatt.org> References: <20080615140121.GM9702@hezmatt.org> Message-ID: <6bb5f5b10806150712v3bfa4b55ofcff27c14075ae9f@mail.gmail.com> 1) I've seen this behavior before; you are not alone in the universe. 2) Most likely there is a balanced channel on the path, either L3 or L2, and one of the links in the bundle is dead but has not been detected as such. Rubens On Sun, Jun 15, 2008 at 11:01 AM, Matt Palmer wrote: > We're seeing some really weird issues with connections that go through / to > Level3 IP space. Basically, certain "pairs" of IPs (particular L3 IPs > coupled with particular IPs of ours) have dodgy/nonexistent connectivity, > but if you change the IP at either end everything's hunky dory. > > I've sniffed (from both ends) pings going from a host in L3 space to our end > and seen the pings arrive at our end and head back in the direction of L3, > but they never get to their destination. Traceroutes from L3 stop at the > next-to-last hop, while traceroutes back get to the hop before L3 space and > stop. > > All of this behaviour is source/dest *pair* specific -- if I ping/traceroute > from another address (in the same netblock as the problematic IP, so all the > same equipment is involved) at either end, or to another address (again, > same netblock) at either end, it all works again. > > I've got two questions: > > 1) Has anyone else seen similar behaviour from L3 (or other providers, > even), so I know I'm not going mad? > > 2) What sort of configuration problem or software bug would cause this sort > of problem to occur? If it was an IP blacklist (or even a block routing > issue) anywhere along the line, surely it wouldn't be sensitive to > changing the other end's address to another one in the same /24? > > Any insight/anecdotes/etc would be greatly appreciated, as it's starting to > do my head in. Just knowing I'm not alone with this insanity would be nice > at this point. > > If it makes any difference, the blocks I'm working from at my end are > Internap, in 74.201.254.0/23 (we don't have all of it, just most of it), > while the far end is 8.12.35.0/24. > > - Matt > > From mpalmer at hezmatt.org Sun Jun 15 09:39:56 2008 From: mpalmer at hezmatt.org (Matt Palmer) Date: Mon, 16 Jun 2008 00:39:56 +1000 Subject: Single IP routing problems through Level3 In-Reply-To: <6bb5f5b10806150712v3bfa4b55ofcff27c14075ae9f@mail.gmail.com> References: <20080615140121.GM9702@hezmatt.org> <6bb5f5b10806150712v3bfa4b55ofcff27c14075ae9f@mail.gmail.com> Message-ID: <20080615143956.GN9702@hezmatt.org> On Sun, Jun 15, 2008 at 11:12:25AM -0300, Rubens Kuhl Jr. wrote: > 1) I've seen this behavior before; you are not alone in the universe. Thank $DEITY for that. > 2) Most likely there is a balanced channel on the path, either L3 or > L2, and one of the links in the bundle is dead but has not been > detected as such. A multiple-link bundle which is load balanced by source/destination pair with an undetected dud link? I hadn't thought of that, but it does make an *awful* lot of sense. (Although, not being a big-network transit kinda person, I don't know if such a thing actually exists ) I'll mention it (or ask about it) as a possibility next time I talk to the relevant people, though. Thanks, - Matt > On Sun, Jun 15, 2008 at 11:01 AM, Matt Palmer wrote: > > We're seeing some really weird issues with connections that go through / to > > Level3 IP space. Basically, certain "pairs" of IPs (particular L3 IPs > > coupled with particular IPs of ours) have dodgy/nonexistent connectivity, > > but if you change the IP at either end everything's hunky dory. > > > > I've sniffed (from both ends) pings going from a host in L3 space to our end > > and seen the pings arrive at our end and head back in the direction of L3, > > but they never get to their destination. Traceroutes from L3 stop at the > > next-to-last hop, while traceroutes back get to the hop before L3 space and > > stop. > > > > All of this behaviour is source/dest *pair* specific -- if I ping/traceroute > > from another address (in the same netblock as the problematic IP, so all the > > same equipment is involved) at either end, or to another address (again, > > same netblock) at either end, it all works again. > > > > I've got two questions: > > > > 1) Has anyone else seen similar behaviour from L3 (or other providers, > > even), so I know I'm not going mad? > > > > 2) What sort of configuration problem or software bug would cause this sort > > of problem to occur? If it was an IP blacklist (or even a block routing > > issue) anywhere along the line, surely it wouldn't be sensitive to > > changing the other end's address to another one in the same /24? > > > > Any insight/anecdotes/etc would be greatly appreciated, as it's starting to > > do my head in. Just knowing I'm not alone with this insanity would be nice > > at this point. > > > > If it makes any difference, the blocks I'm working from at my end are > > Internap, in 74.201.254.0/23 (we don't have all of it, just most of it), > > while the far end is 8.12.35.0/24. From jon at defenderhosting.com Sun Jun 15 10:56:24 2008 From: jon at defenderhosting.com (Jon Wolberg) Date: Sun, 15 Jun 2008 11:56:24 -0400 (EDT) Subject: Single IP routing problems through Level3 In-Reply-To: <2100190981.236031213545268186.JavaMail.root@mail.dtgmail.com> Message-ID: <1128524857.236071213545384470.JavaMail.root@mail.dtgmail.com> I've seen the exact same symptoms before with another provider and it was a L3 Port-Channel that was not balanced properly due to a link being down which wasn't detected as such. It was also causing very sporadic latency spikes and dropped packets. Jon ----- Original Message ----- From: "Matt Palmer" To: nanog at nanog.org Sent: Sunday, June 15, 2008 10:39:56 AM GMT -05:00 US/Canada Eastern Subject: Re: Single IP routing problems through Level3 On Sun, Jun 15, 2008 at 11:12:25AM -0300, Rubens Kuhl Jr. wrote: > 1) I've seen this behavior before; you are not alone in the universe. Thank $DEITY for that. > 2) Most likely there is a balanced channel on the path, either L3 or > L2, and one of the links in the bundle is dead but has not been > detected as such. A multiple-link bundle which is load balanced by source/destination pair with an undetected dud link? I hadn't thought of that, but it does make an *awful* lot of sense. (Although, not being a big-network transit kinda person, I don't know if such a thing actually exists ) I'll mention it (or ask about it) as a possibility next time I talk to the relevant people, though. Thanks, - Matt > On Sun, Jun 15, 2008 at 11:01 AM, Matt Palmer wrote: > > We're seeing some really weird issues with connections that go through / to > > Level3 IP space. Basically, certain "pairs" of IPs (particular L3 IPs > > coupled with particular IPs of ours) have dodgy/nonexistent connectivity, > > but if you change the IP at either end everything's hunky dory. > > > > I've sniffed (from both ends) pings going from a host in L3 space to our end > > and seen the pings arrive at our end and head back in the direction of L3, > > but they never get to their destination. Traceroutes from L3 stop at the > > next-to-last hop, while traceroutes back get to the hop before L3 space and > > stop. > > > > All of this behaviour is source/dest *pair* specific -- if I ping/traceroute > > from another address (in the same netblock as the problematic IP, so all the > > same equipment is involved) at either end, or to another address (again, > > same netblock) at either end, it all works again. > > > > I've got two questions: > > > > 1) Has anyone else seen similar behaviour from L3 (or other providers, > > even), so I know I'm not going mad? > > > > 2) What sort of configuration problem or software bug would cause this sort > > of problem to occur? If it was an IP blacklist (or even a block routing > > issue) anywhere along the line, surely it wouldn't be sensitive to > > changing the other end's address to another one in the same /24? > > > > Any insight/anecdotes/etc would be greatly appreciated, as it's starting to > > do my head in. Just knowing I'm not alone with this insanity would be nice > > at this point. > > > > If it makes any difference, the blocks I'm working from at my end are > > Internap, in 74.201.254.0/23 (we don't have all of it, just most of it), > > while the far end is 8.12.35.0/24. From peiffer at umn.edu Sun Jun 15 11:34:31 2008 From: peiffer at umn.edu (Tim Peiffer) Date: Sun, 15 Jun 2008 11:34:31 -0500 Subject: Single IP routing problems through Level3 In-Reply-To: <20080615140121.GM9702@hezmatt.org> References: <20080615140121.GM9702@hezmatt.org> Message-ID: <48554497.7070301@umn.edu> Matt Palmer wrote: > We're seeing some really weird issues with connections that go through / to > Level3 IP space. Basically, certain "pairs" of IPs (particular L3 IPs > coupled with particular IPs of ours) have dodgy/nonexistent connectivity, > but if you change the IP at either end everything's hunky dory. > > I've sniffed (from both ends) pings going from a host in L3 space to our end > and seen the pings arrive at our end and head back in the direction of L3, > but they never get to their destination. Traceroutes from L3 stop at the > next-to-last hop, while traceroutes back get to the hop before L3 space and > stop. > > All of this behaviour is source/dest *pair* specific -- if I ping/traceroute > from another address (in the same netblock as the problematic IP, so all the > same equipment is involved) at either end, or to another address (again, > same netblock) at either end, it all works again. > > I've got two questions: > > 1) Has anyone else seen similar behaviour from L3 (or other providers, > even), so I know I'm not going mad? > > 2) What sort of configuration problem or software bug would cause this sort > of problem to occur? If it was an IP blacklist (or even a block routing > issue) anywhere along the line, surely it wouldn't be sensitive to > changing the other end's address to another one in the same /24? > > Any insight/anecdotes/etc would be greatly appreciated, as it's starting to > do my head in. Just knowing I'm not alone with this insanity would be nice > at this point. > > If it makes any difference, the blocks I'm working from at my end are > Internap, in 74.201.254.0/23 (we don't have all of it, just most of it), > while the far end is 8.12.35.0/24. > > - Matt > We commonly see this sort of problem with Layer2 or Layer3 bonded etherchannel (LACP also). One member of the channel is failing for one reason or another and dropping traffic. The channel is really not a load balance mechanism, but is a frame distribution mechanism. The distribution of frames uses the source and destination IP addresses to hash out to a particular channel member, and that distribution provides a rough balance. The problems noted affect traffic in one direction differently as it is likely assymetric across the channel. Only traffic across the ailing member will be impacted. The above can present itself anywhere in the path if channeling is used. Regards, Tim Peiffer Networking and Telecommunications Services University of Minnesota/NorthernLights GigaPOP From rdobbins at cisco.com Sun Jun 15 14:11:20 2008 From: rdobbins at cisco.com (Roland Dobbins) Date: Mon, 16 Jun 2008 02:11:20 +0700 Subject: DNS problems to RoadRunner - tcp vs udp In-Reply-To: <200806151302.m5FD2ngA046141@aurora.sol.net> References: <200806151302.m5FD2ngA046141@aurora.sol.net> Message-ID: On Jun 15, 2008, at 8:02 PM, Joe Greco wrote: > I think a real solution would be more sophisticated than this, but > it's a starting point. In addition to the BCPs already mentioned by Sean and Nathan, a good detection/classification/traceback system plus S/RTBH can be helpful, and there are commercial DDoS mitigation services/scrubbers available from various SPs/vendors which have DNS-specific functionality, as well. Blocking TCP/53 is definitely not an optimal solution, as many have already pointed out. ----------------------------------------------------------------------- Roland Dobbins // +66.83.266.6344 mobile History is a great teacher, but it also lies with impunity. -- John Robb From matthew at eeph.com Sun Jun 15 17:07:21 2008 From: matthew at eeph.com (Matthew Kaufman) Date: Sun, 15 Jun 2008 15:07:21 -0700 Subject: Single IP routing problems through Level3 In-Reply-To: <20080615143956.GN9702@hezmatt.org> References: <20080615140121.GM9702@hezmatt.org> <6bb5f5b10806150712v3bfa4b55ofcff27c14075ae9f@mail.gmail.com> <20080615143956.GN9702@hezmatt.org> Message-ID: <48559299.1010409@eeph.com> Matt Palmer wrote: > A multiple-link bundle which is load balanced by source/destination pair > with an undetected dud link? I hadn't thought of that, but it does make an > *awful* lot of sense.... I've also seen interesting OSPF misconfigurations that resulted in a router doing path-wise load balancing between the live link and an unroutable destination address that went into the bit bucket. On the Cisco boxes I was using at the time, the hallmark of load-balancing into a dead path was that every other IP address worked, but then every some number of addresses (12, as I remember, but I'm not 100% sure) the polarity flipped, so that whichever of odd vs even had worked before was now the one that didn't for the next N addresses. Artifact of the hash algorithm in use, no doubt. Matthew Kaufman matthew at eeph.com http://www.matthew.at From marka at isc.org Sun Jun 15 20:09:24 2008 From: marka at isc.org (Mark Andrews) Date: Mon, 16 Jun 2008 11:09:24 +1000 (EST) Subject: DNS problems to RoadRunner - tcp vs udp In-Reply-To: <48546625.6040301@rockynet.com> References: Message-ID: <200806160109.m5G19OXb015007@drugs.dv.isc.org> In article <48546625.6040301 at rockynet.com> you write: >Sean Donelan wrote: > >> 1. Separate your authoritative and recursive name servers >> 2. Recursive name servers should only get replies to their own DNS >> queries from the Internet, they can use both UDP and TCP > >We've just completed a project to separate our authoritative and >recursive servers and I have a couple notes... > >1) For the recursive-only, we're using a combination of BIND's >"query-source address a.b.c.d" and "listen-on e.f.g.h" in the hopes of >providing some additional measure of protection against cache poisoning. >The "listen-on" IPs are ACL'd at the borders so non-clients cannot get >ANY packets to them. The "query-source address" itself doesn't appear in >the "listen-on" list either and won't respond to queries. I know this >isn't foolproof, but it probably raises the bar slightly against off-net >poisoning attempts. Named will reject queries on the *-source sockets. It will also drop responses on the listening sockets provided you havn't set the query-souce port to port 53. >2) The biggest drawback to separation after years of service is that >customers have come to expect their DNS changes are propagated instantly >when they are on-net. This turns out to be more of an annoyance to us >than our customers, since our zone is probably the most frequently updated. Querying for type SOA at the name will prevent named caching negative responses and still allow existance tests to be made. nsupdate makes SOA queries to workout which zone needs to be updated and to also determine which server to send the updates to. We realised a long time ago that we needed to have a way to find the containing zone that didn't result in caches being filled with the side effects of that discover mechanism. Named, by default, sets the ttl to zero on negative responses to SOA queries. >3) I've gone so far as to remove the root hint zone from our auth-only >boxes, again out of paranoia ("recursion no" does the trick, this is >just an extra bit of insurance against someone flipping that bit due to >a lack of understanding of the architecture). There is one third party >we have to use an 'also-notify' by IP address in this case for their zone. Authoritative only servers need hints so that NOTIFY will work in the general case. Eventually, they will also need them so we can get rid of IP addresses in masters clauses on slave/stub zones. This will help reduce the costs in renumbering. >Mike Mark From gdt at gdt.id.au Sun Jun 15 21:48:06 2008 From: gdt at gdt.id.au (Glen Turner) Date: Mon, 16 Jun 2008 12:18:06 +0930 Subject: Best utilizing fat long pipes and large file transfer In-Reply-To: <86od66t9ru.fsf@seastrom.com> References: <20080612230550.18AE44500E@ptavv.es.net> <4851B917.50306@psg.com> <86od66t9ru.fsf@seastrom.com> Message-ID: <4855D466.5060600@gdt.id.au> Robert E. Seastrom wrote: > As a user of hpn-ssh for years, I have to wonder if there is any > reason (aside from the sheer cussedness for which Theo is infamous) > that the window improvements at least from hpn-ssh haven't been > backported into mainline openssh? I suppose there might be > portability concerns with the multithreaded ciphers, and there's > certainly a good argument for not supporting NONE as a cipher type out > of the box without a recompile, but there's not much excuse for the > fixed size tiny buffers - I mean, it's 2008 already... Fedora 8 and 9 and Ubuntu 8.04 include the upstream OpenSSH which include large window patches. OpenSSH 4.7 ChangeLog contains: > Other changes, new functionality and fixes in this release: ... > * The SSH channel window size has been increased, and both ssh(1) > sshd(8) now send window updates more aggressively. These improves > performance on high-BDP (Bandwidth Delay Product) networks. Cheers, Glen -- Glen Turner From gdt at gdt.id.au Sun Jun 15 22:10:47 2008 From: gdt at gdt.id.au (Glen Turner) Date: Mon, 16 Jun 2008 12:40:47 +0930 Subject: Best utilizing fat long pipes and large file transfer In-Reply-To: References: <20080613160112.9F8B545047@ptavv.es.net> <1213375252_14636@mail1.tellurian.net> Message-ID: <4855D9B7.6040907@gdt.id.au> goemon at anime.net wrote: > Its actually not that hard on windows. Don't make me laugh. Instructions that start "Enable TCP window scaling and time stamps by using the Registry Editor to browse to location [HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters] and add the key Tcp1323Opts with value 3" are "hard". If you think otherwise, pick up the phone, pretend to work for an ISP Help Desk, and walk someone who doesn't work in IT through the changes. Microsoft scatter the tuning information for Windows Xp all across their website. Some of it is undocumented by Microsoft (and thus may change without notice). The only saving grace is DrTCP, a third party application which hides all of the registry detail (and potential for disaster) under a nice GUI. Then there's the deliberate nobbling of the TCP implementation, such as the restriction to ten of connections to Windows Xp SP3. Apparently you're meant to buy Windows Server if you are running P2P applications :-) Windows Vista is a vast improvement over Windows Xp (and I bet that isn't said of many components of Vista). It has a autotuning TCP with a 16MB buffer, which makes the defaults fine for ADSL and cable, but still requires machines at universities to be altered. Vista offers an alternative TCP congestion control algorithm -- Compound TCP. Not much is known of the performance attributes of this algorithm, mainly because I.P claims prevented its incorporation into Linux, the corral where most TCP algorithm shoot-outs take place. -- Glen Turner From michael at rancid.berkeley.edu Mon Jun 16 01:56:31 2008 From: michael at rancid.berkeley.edu (Michael Sinatra) Date: Sun, 15 Jun 2008 23:56:31 -0700 Subject: DNS problems to RoadRunner - tcp vs udp In-Reply-To: <200806160109.m5G19OXb015007@drugs.dv.isc.org> References: <200806160109.m5G19OXb015007@drugs.dv.isc.org> Message-ID: <48560E9F.1010906@rancid.berkeley.edu> Mark Andrews wrote: > Authoritative only servers need hints so that NOTIFY will > work in the general case. Presumably that's because the authoritative server will want to look up the RDATA (hostname) of each NS record that serves a zone for which it is authoritative. Could you avoid this if you used something like 'notify explicit' and specified all slave servers by IP address in an also-notify clause? > Eventually, they will also need > them so we can get rid of IP addresses in masters clauses > on slave/stub zones. This will help reduce the costs in > renumbering. Would an administrator still have the option of specifying masters by IP address if they desire, and therefore remove the need for the hints file? It seems that this would at least give the option of not only forcing recursion off, even if someone turns it on by accident (as Mike notes), but it also should help reduce the potential for reflection attacks from authoritative servers giving upward referrals for out-of-zone queries, no? michael From ops.lists at gmail.com Mon Jun 16 02:53:27 2008 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Mon, 16 Jun 2008 13:23:27 +0530 Subject: If bandwidth wasnt already cheap (!) enough .. Message-ID: http://telephonyonline.com/ethernet/news/Cogent_price_cuts_06112008/ > "Cogent this morning is announcing new discounts for customers who commit to > three-year contracts and for higher volume service provider customers. The > new three-year price for Ethernet service is a flat $7 a megabit, a dollar > less than the previous rate for contracts of two years or more. For service > providers who buy Ethernet services at volumes between 100 megabits per > second and a Gigabit, rates are as low as $6 per megabit for a three-year > contract. > > Service providers who buy between one Gigabit and 10 gigabits will enjoy a > three-year contract rate of $5 a meg, and those that consume a full 10 > gigabit port can pay as little as $4 a meg on a three-year contract." From james.blessing at entagroup.com Mon Jun 16 04:04:50 2008 From: james.blessing at entagroup.com (James Blessing) Date: Mon, 16 Jun 2008 10:04:50 +0100 Subject: If bandwidth wasnt already cheap (!) enough .. In-Reply-To: References: Message-ID: <48562CB2.6090200@entagroup.com> Suresh Ramasubramanian wrote: >> Service providers who buy between one Gigabit and 10 gigabits will enjoy a >> three-year contract rate of $5 a meg, and those that consume a full 10 >> gigabit port can pay as little as $4 a meg on a three-year contract." A cynic would say that they are trying to book the revenues to raise some finance... J -- COO Entanet International T: 0870 770 9580 W: http://www.enta.net/ From rs at seastrom.com Mon Jun 16 06:22:02 2008 From: rs at seastrom.com (Robert E. Seastrom) Date: Mon, 16 Jun 2008 07:22:02 -0400 Subject: Best utilizing fat long pipes and large file transfer In-Reply-To: <4855D466.5060600@gdt.id.au> (Glen Turner's message of "Mon, 16 Jun 2008 12:18:06 +0930") References: <20080612230550.18AE44500E@ptavv.es.net> <4851B917.50306@psg.com> <86od66t9ru.fsf@seastrom.com> <4855D466.5060600@gdt.id.au> Message-ID: <86r6axfwv9.fsf@seastrom.com> Glen Turner writes: > Fedora 8 and 9 and Ubuntu 8.04 include the upstream OpenSSH which include > large window patches. OpenSSH 4.7 ChangeLog contains: > >> Other changes, new functionality and fixes in this release: > ... >> * The SSH channel window size has been increased, and both ssh(1) >> sshd(8) now send window updates more aggressively. These improves >> performance on high-BDP (Bandwidth Delay Product) networks. Turns out that the Mac does too. Haven't checked FreeBSD 7 yet, but 6.x is definitely lagging. Thanks for the clue, -r From netfortius at gmail.com Mon Jun 16 08:53:20 2008 From: netfortius at gmail.com (Netfortius) Date: Mon, 16 Jun 2008 08:53:20 -0500 Subject: P2P agents for software distribution - saving the WAN from meltdown?!? Message-ID: <200806160853.20416.netfortius@gmail.com> Has anybody used (and been successful at) a bit-torrent-like agent for fast distribution of LEGAL software (install programs of large-DVD size), across multiple sites, all over the globe, with bad WAN connectivity? I have read a couple of references online (e.g. http://torrentfreak.com/university-uses-utorrent-080306/) about such, but I am a little reluctant to do it in a corporate environment, especially in the light of potential misuse of such ... unless finding a way to install, use and remove the P2P agent, all in one shot ... catch 22, sort of (distributing the P2P agent, that is :)) ... Stefan P.S. If inappropriate for this mailing list, I apologize - but the "long fat pipe" thread gave me the idea to ask here, vs. sysadmin-like lists, as the potential for network impact is my primary concern. From mcgrath at fas.harvard.edu Mon Jun 16 11:51:54 2008 From: mcgrath at fas.harvard.edu (Scott C. McGrath) Date: Mon, 16 Jun 2008 12:51:54 -0400 Subject: DNS problems to RoadRunner - tcp vs udp In-Reply-To: <6C1C1472-DC4A-4F2E-A106-0E4EE8544C6F@daork.net> References: <61b6fbec0806131111u77606e1bu90bcd102c3217fb4@mail.gmail.com> <4852B91F.8090205@aset.com> <4852F3E9.3060707@psg.com> <48542CAA.5010503@fas.harvard.edu> <48542E73.9070109@spaghetti.zurich.ibm.com> <485435AE.8060609@fas.harvard.edu> <6C1C1472-DC4A-4F2E-A106-0E4EE8544C6F@daork.net> Message-ID: <48569A2A.3030104@fas.harvard.edu> All, Thanks for the helpful suggestions. For what it's worth we use Cisco's CNR as we operate a MAC registration system which controls access to our network. We allow customers to select hostnames which are pushed into DDNS when the the system acquires a lease. CNR has internal limits (user configurable) which control the TCP state machine and these are easy to overwhelm as once you hit the high limit the server process stops accepting new connection requests for any reason until the connections go below the max limit once again. We have been in constant contact with the development group on defending these machines from DDoS activity. UDP is somewhat easier due to our network structure than TCP to rate limit and we do operate microflow policers to limit UDP activity from any given host. We once used BIND but bind could not handle the DDNS updates in a reasonable fashion as we have many short lived connections as students access the wireless network between classes hence the move to CNR which handles DDNS effectively but does not like TCP based attacks Unlike MIT over the river Harvard only has 2 Class B's available and we have many more registered clients than we have IP space for and a community which requires fixed hostnames for academic reasons and since we cannot assign static IP assignments except to well known and fixed services this becomes problematic hence DDNS which as many have pointed out here is painful from a operational standpoint but in our environment it is a lifesaver. Unfortunately we have needed to insert some controlled breakage into the network to keep the services our customers require alive as TCP SYN attacks are unfortunately still effective in this day and age we have tried many things our latest foray into TCP control is creating a Snort infrastructure which is sufficient to monitor all flows ingressing and egressing our network and from there based on analysis of the data applying rules to limit traffic in real time from ill behaved TCP hosts as our long term goal is not to operate a corporate network locked into stupid mode with no understanding of protocol needs - Scott Nathan Ward wrote: > On 15/06/2008, at 9:18 AM, Scott McGrath wrote: > >> Yes - we are blocking TCP too many problems with drone armies and we >> started about a year ago when our DNS servers became unresponsive for >> no apparent reason. Investigation showed TCP flows of hundreds of >> megabits/sec and connection table overflows from tens of thousands of >> bots all trying to simultaneously do zone transfers and failing tried >> active denial systems and shunning with limited effectiveness. >> >> We are well aware of the host based mechanisms to control zone >> information, Trouble is with TCP if you can open the connection you >> can DoS so we don't allow the connection to be opened and this is >> enforced at the network level where we can drop at wire speed. >> Open to better ideas but if you look at the domain in my email >> address you will see we are a target for hostile activity just so >> someone can 'make their bones'. > > > There's really two problems here - one is packet/bit rate causing > problems for your network, that's not necessarily an end system thing. > Not really DNS specific, and blocking 53/TCP doesn't really help here > as people could just send 53/UDP your way and get the same effect. > > Connection table overflowing is a bit of a different issue, obvious > way to overcome that is to whack a load balancer in there to share the > load around. It's not immediately obvious to me why your connection > table would be filling up - what state were connections stuck in? > > Anyway, one thought that comes to me would be to split off UDP and TCP > services to different servers - if some TCP attack kills your TCP DNS > server you: > a) don't have to worry about UDP services failing. > b) can turn it off for the duration of the attack, and are no worse > off than you are right now, then turn it back on when you see the high > volume of SYN messages disappear. > c) as TCP DNS service recovery isn't super time critical (I'm assuming > this, because you're not running it at all right now) you have time to > look at the anatomy of the attack and figure out how to filter it more > precisely if possible, instead of simply dropping all TCP. > > Obviously, you'd want to make sure TCP from your other name servers > always goes to the UDP one, etc. etc. > > -- > Nathan Ward > > > > From goemon at anime.net Mon Jun 16 12:25:18 2008 From: goemon at anime.net (goemon at anime.net) Date: Mon, 16 Jun 2008 10:25:18 -0700 (PDT) Subject: Best utilizing fat long pipes and large file transfer In-Reply-To: <4855D9B7.6040907@gdt.id.au> References: <20080613160112.9F8B545047@ptavv.es.net> <1213375252_14636@mail1.tellurian.net> <4855D9B7.6040907@gdt.id.au> Message-ID: On Mon, 16 Jun 2008, Glen Turner wrote: > Then there's the deliberate nobbling of the TCP implementation, > such as the restriction to ten of connections to Windows Xp SP3. > Apparently you're meant to buy Windows Server if you are running > P2P applications :-) are you quite sure it is *10 tcp connections*? have you tested this? -Dan From Skywing at valhallalegends.com Mon Jun 16 12:43:10 2008 From: Skywing at valhallalegends.com (Skywing) Date: Mon, 16 Jun 2008 12:43:10 -0500 Subject: Best utilizing fat long pipes and large file transfer Message-ID: <982D8D05B6407A49AD506E6C3AC8E7D661479402FE@caralain.haven.nynaeve.net> It's 10 half-open (SYN_SENT) outbound TCP connections as I recall. - S -----Original Message----- From: goemon at anime.net Sent: Monday, June 16, 2008 12:26 To: Glen Turner Cc: nanog at merit.edu Subject: Re: Best utilizing fat long pipes and large file transfer On Mon, 16 Jun 2008, Glen Turner wrote: > Then there's the deliberate nobbling of the TCP implementation, > such as the restriction to ten of connections to Windows Xp SP3. > Apparently you're meant to buy Windows Server if you are running > P2P applications :-) are you quite sure it is *10 tcp connections*? have you tested this? -Dan From deepak at ai.net Mon Jun 16 13:37:46 2008 From: deepak at ai.net (Deepak Jain) Date: Mon, 16 Jun 2008 14:37:46 -0400 Subject: If bandwidth wasnt already cheap (!) enough .. In-Reply-To: <48562CB2.6090200@entagroup.com> References: <48562CB2.6090200@entagroup.com> Message-ID: <4856B2FA.2080802@ai.net> IIRC, doesn't a three-year contract of this sort involve actually adding *liabilities* to the books until the revenue is captured? I think this may have more to do with run-rates or cutting attrition since so many "allegedly" better networks are offering pricing at or below Cogent's old/original pricing. Disclaimer: Not a Cogent customer/investor. DJ James Blessing wrote: > Suresh Ramasubramanian wrote: > >>> Service providers who buy between one Gigabit and 10 gigabits will >>> enjoy a >>> three-year contract rate of $5 a meg, and those that consume a full 10 >>> gigabit port can pay as little as $4 a meg on a three-year contract." > > A cynic would say that they are trying to book the revenues to raise > some finance... > > J From nate at seekio.com Mon Jun 16 13:44:41 2008 From: nate at seekio.com (Nate) Date: Mon, 16 Jun 2008 11:44:41 -0700 Subject: Bandcon Transport Services.. In-Reply-To: <9b62cf2f0806141520j643d40dftd5d12af9f22bf47a@mail.gmail.com> References: <9b62cf2f0806141520j643d40dftd5d12af9f22bf47a@mail.gmail.com> Message-ID: <4856B499.2060803@seekio.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I don't use them for IP transit, but I do use them for Level3 CDN service, and I've had positive experiences with both my sales rep and the support people. They get stuff done in a timely manner and are also pretty flexible towards meeting our needs. How much of that carries over from CDN to IP, your guess is as good as mine. My rep is Mike Castrogiovani. Nate Christian wrote: | Anyone here use Bandcon's transport services? Positive/Negative experiences, | any feedback would be helpful.. | | Thanks | | ck - -- Nate System Admin Manager System Administration Ext 220 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIVrSYRMRYK1K/wKQRAlkwAJ94XMx7Usv/jgiPvqKTlqrKiKDTPgCgiLt2 PySmWuzFmzInCXMpYn35DVM= =qoqp -----END PGP SIGNATURE----- From Bob at BRADLEE.ORG Mon Jun 16 15:37:38 2008 From: Bob at BRADLEE.ORG (Bob Bradlee) Date: Mon, 16 Jun 2008 16:37:38 -0400 Subject: Best utilizing fat long pipes and large file transfer In-Reply-To: Message-ID: I have tested it with Icecast using audio streams and it is 100 not 10. moved to w2k server and the glass wall at 100 streams went away. Bob On Mon, 16 Jun 2008 10:25:18 -0700 (PDT), goemon at anime.net wrote: >On Mon, 16 Jun 2008, Glen Turner wrote: >> Then there's the deliberate nobbling of the TCP implementation, >> such as the restriction to ten of connections to Windows Xp SP3. >> Apparently you're meant to buy Windows Server if you are running >> P2P applications :-) >are you quite sure it is *10 tcp connections*? >have you tested this? >-Dan From etrdina at claytonkendall.com Mon Jun 16 15:50:05 2008 From: etrdina at claytonkendall.com (Edward A. Trdina III) Date: Mon, 16 Jun 2008 16:50:05 -0400 Subject: Google Contact Message-ID: <21D39E119A720E42BA4A11ABF884D769B39BBD@Exchange1.CK1.DMN> Can someone from Google please ping me off list please? From joesox at gmail.com Mon Jun 16 17:32:21 2008 From: joesox at gmail.com (JoeSox) Date: Mon, 16 Jun 2008 15:32:21 -0700 Subject: Cable Colors Message-ID: <785694cd0806161532s4a205b3ey19d2aef1eb12285e@mail.gmail.com> Hello Newbie here (hopefully I have the correct list), I was just wondering if anyone knows of a website with recommended colors for cables for a new datacenter? I have written some things down but I don't want to get stuck saying 'darn, I wish I would have bought this color for this type, now I am stuck'. What standard color to use if voice and data on same interface etc. Thanks. -- Thank You, Joe From ges at wingfoot.org Mon Jun 16 17:41:22 2008 From: ges at wingfoot.org (Glenn Sieb) Date: Mon, 16 Jun 2008 18:41:22 -0400 Subject: Cable Colors In-Reply-To: <785694cd0806161532s4a205b3ey19d2aef1eb12285e@mail.gmail.com> References: <785694cd0806161532s4a205b3ey19d2aef1eb12285e@mail.gmail.com> Message-ID: <4856EC12.30500@wingfoot.org> JoeSox wrote: > Hello Newbie here (hopefully I have the correct list), > > I was just wondering if anyone knows of a website with recommended > colors for cables for a new datacenter? > I have written some things down but I don't want to get stuck saying > 'darn, I wish I would have bought this color for this type, now I am > stuck'. > What standard color to use if voice and data on same interface etc. Thanks. > Hmm. I've always done blue for "safe" or "internal" connections, red for machines on the DMZ or outside. Perhaps Blue for internal data, Yellow for internal voice, Green for data/voice? Don't know if there's a website on this, but you can definitely read about it in Tom Limoncelli's The Practice of System and Network Administration book. Best, --Glenn -- ...destination is merely a byproduct of the journey --Eric Hansen From deballing at vassar.edu Mon Jun 16 17:48:46 2008 From: deballing at vassar.edu (Derek J. Balling) Date: Mon, 16 Jun 2008 18:48:46 -0400 Subject: Cable Colors In-Reply-To: <4856EC12.30500@wingfoot.org> References: <785694cd0806161532s4a205b3ey19d2aef1eb12285e@mail.gmail.com> <4856EC12.30500@wingfoot.org> Message-ID: <0218AF7A-5D44-40C0-9676-E254C436B195@vassar.edu> On Jun 16, 2008, at 6:41 PM, Glenn Sieb wrote: > Hmm. I've always done blue for "safe" or "internal" connections, red > for machines on the DMZ or outside. I think this varies a lot based on the environment... I've seen : - Red for external ("hot"), Blue for internal ("cold") - Red for external ("stop this"), green for internal ("go/trusted") - Red for internal ("stop this from leaving") and green for external ("go go go to the outside world") - A combination of the either of the last two with "Yellow" for a cautionary DMZ area And then there's the environment I'm in right now, where there are a LOT of different cable colors for different reasons. The reality is, from my experience, to find a color combination that makes sense to you and is intuitive to you and the people who'll be working with the cables. Amusing cautionary tale: confirm that you don't have any color-blind staff, and if you do, make sure they can differentiate all your cable colors before you set them in stone and deploy them. :-) cheers, D -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2478 bytes Desc: not available URL: From scott at heberts.net Mon Jun 16 17:50:40 2008 From: scott at heberts.net (Scott Hebert) Date: Mon, 16 Jun 2008 17:50:40 -0500 Subject: Cable Colors In-Reply-To: <4856EC12.30500@wingfoot.org> References: <785694cd0806161532s4a205b3ey19d2aef1eb12285e@mail.gmail.com> <4856EC12.30500@wingfoot.org> Message-ID: > > Perhaps Blue for internal data, Yellow for internal voice, Green for > data/voice? Some people reserve yellow for cross-over cables. -- Scott Hebert http://slaptijack.com From ml at t-b-o-h.net Mon Jun 16 17:52:36 2008 From: ml at t-b-o-h.net (Tuc at T-B-O-H) Date: Mon, 16 Jun 2008 18:52:36 -0400 (EDT) Subject: Cable Colors In-Reply-To: <785694cd0806161532s4a205b3ey19d2aef1eb12285e@mail.gmail.com> from "JoeSox" at Jun 16, 2008 03:32:21 PM Message-ID: <200806162252.m5GMqajD066399@vjofn.tucs-beachin-obx-house.com> > > Hello Newbie here (hopefully I have the correct list), > > I was just wondering if anyone knows of a website with recommended > colors for cables for a new datacenter? > I have written some things down but I don't want to get stuck saying > 'darn, I wish I would have bought this color for this type, now I am > stuck'. > What standard color to use if voice and data on same interface etc. Thanks. > Hi, We solved the problem of remembering what color was for what by getting our suppliers to use clear jackets on the wiring. That way we see whats actually going over the copper and can tell that way. It costs us more, we do have a bit of an issue putting plugs on it, but in the long run its definitely worth it. Otherwise, our old system was : Black - Infrastructure/critical Green - Colocation/Customer White - KVM Blue - X-connect (Later changed to Orange when we went full fiber) Yellow- Someone threw a spare patch cord up and didn't custom create/ cut it and if I find them I'm gonna create/cut them something! White+Red spot or stripe - The junior guy was cutting KVM cables again, expect a health benefit claim later in the day. We also used the ID zip ties on each end if it was an X-over with "X-over" written on it. All plugs had boots too. Tuc/TBOH (Insert ;) as needed... ;) ) From telmnstr at 757.org Mon Jun 16 17:55:16 2008 From: telmnstr at 757.org (telmnstr at 757.org) Date: Mon, 16 Jun 2008 18:55:16 -0400 (EDT) Subject: Cable Colors In-Reply-To: References: <785694cd0806161532s4a205b3ey19d2aef1eb12285e@mail.gmail.com> <4856EC12.30500@wingfoot.org> Message-ID: > Some people reserve yellow for cross-over cables. I was going to say yellow for serial consoles... but in this day and age, I guess the crossover cables AND serial console connection are fading fast. - Ethan O'Toole From soren.telfer at gmail.com Mon Jun 16 17:55:14 2008 From: soren.telfer at gmail.com (Soren Telfer) Date: Mon, 16 Jun 2008 18:55:14 -0400 Subject: Cable Colors In-Reply-To: References: <785694cd0806161532s4a205b3ey19d2aef1eb12285e@mail.gmail.com> <4856EC12.30500@wingfoot.org> Message-ID: <4856EF52.5090904@gmail.com> TIA-606A and some of the other TIA docs have cable color recommendations. Scott Hebert wrote: >> Perhaps Blue for internal data, Yellow for internal voice, Green for >> data/voice? >> > > > Some people reserve yellow for cross-over cables. > > -- > Scott Hebert > http://slaptijack.com > > From owen at delong.com Mon Jun 16 17:56:45 2008 From: owen at delong.com (Owen DeLong) Date: Mon, 16 Jun 2008 15:56:45 -0700 Subject: Cable Colors In-Reply-To: <4856EC12.30500@wingfoot.org> References: <785694cd0806161532s4a205b3ey19d2aef1eb12285e@mail.gmail.com> <4856EC12.30500@wingfoot.org> Message-ID: <4388DD56-30A1-4A86-824A-EEAE2F021D21@delong.com> I don't know of any hard standard in use anywhere. I've generally taken to the following: Green == low-bandwidth straigh-through Telephone, T1, Serial, etc. Purple == Roll Cables (almost always serial, sometimes telecom) (8-1 7-2 6-3 5-4 4-5 3-6 2-7 1-8) Orange(C) == EIA-568b cross-over cable (ethernet xover) Orange(F) == Multimode Fiber Yellow(F) == Singlemode Fiber White == Clear (inside VPN concentrator network) Black == Crypt (Outside VPN concentrator network) Blue == Publicly accessible networks Red == Backend (usually OOB management) networks Pink == KVM (KVM switch <-> Dongle) Occasionally I encounter needs for greater specificity, but, these usually do most of what I need. I'm sure others use entirely different choices. Owen From jgreco at ns.sol.net Mon Jun 16 17:59:26 2008 From: jgreco at ns.sol.net (Joe Greco) Date: Mon, 16 Jun 2008 17:59:26 -0500 (CDT) Subject: Cable Colors In-Reply-To: <4856EC12.30500@wingfoot.org> from "Glenn Sieb" at Jun 16, 2008 06:41:22 PM Message-ID: <200806162259.m5GMxQ27058217@aurora.sol.net> > JoeSox wrote: > > Hello Newbie here (hopefully I have the correct list), > > > > I was just wondering if anyone knows of a website with recommended > > colors for cables for a new datacenter? > > I have written some things down but I don't want to get stuck saying > > 'darn, I wish I would have bought this color for this type, now I am > > stuck'. > > What standard color to use if voice and data on same interface etc. Thanks. > > > > Hmm. I've always done blue for "safe" or "internal" connections, red for > machines on the DMZ or outside. > > Perhaps Blue for internal data, Yellow for internal voice, Green for > data/voice? > > Don't know if there's a website on this, but you can definitely read > about it in Tom Limoncelli's The Practice of System and Network > Administration book. What you do is largely going to be dependent on what your situation is. "Data center" is exceedingly vague. An ISP, with telco and data, customer colo and internal network circuits, is going to have very different needs than some company that's running a data processing network behind a firewall and gateway to the Internet along with some minor telco circuits to serve the local user population. Standardizing colors is very helpful, but keep a mind towards not getting excessively complex unless the situation warrants it. One of the most important aspects to color coding is that you're trying to avoid connecting things that might be bad. In most environments, then, you might want to have a "behind the firewall" color and a "DMZ" color. However, consider too that you might have a "management network" color, a "telco data circuit" color, a "KVM-over-cat5-cable" color, a "Yost or Cisco standard Serial" (http://www.sol.net/serial-guide/) color, etc. Those latter are exceedingly useful because you can sometimes toast equipment if you're plugging in something with a very wrong signal type. I happen to like orange for cross-connects, because it resembles multimode fiber (which is what most of our xc's are). Beyond that, mostly you can develop your own thing. We use green for serial console. Yellow might be KVM or might be telecom. There are some standards docs that provide guidance, but I'm not sure that it matters. In the old days, we used to color crossover cables differently too. Thank heavens that all the old non-auto-MDI/MDIX stuff is slowly going away. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From deballing at vassar.edu Mon Jun 16 17:59:53 2008 From: deballing at vassar.edu (Derek J. Balling) Date: Mon, 16 Jun 2008 18:59:53 -0400 Subject: Cable Colors In-Reply-To: References: <785694cd0806161532s4a205b3ey19d2aef1eb12285e@mail.gmail.com> <4856EC12.30500@wingfoot.org> Message-ID: <983976C4-3712-4D2F-96C2-54DB0180B64D@vassar.edu> On Jun 16, 2008, at 6:55 PM, telmnstr at 757.org wrote: > I was going to say yellow for serial consoles... but in this day and > age, I guess the crossover cables AND serial console connection are > fading fast. Crossover cables maybe, but I'm not convinced about serial. I just went through a whole installation of OOB access to all our network equipment "just in case".... Cheers, D -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2478 bytes Desc: not available URL: From randy at psg.com Mon Jun 16 18:00:45 2008 From: randy at psg.com (Randy Bush) Date: Tue, 17 Jun 2008 08:00:45 +0900 Subject: Cable Colors In-Reply-To: References: <785694cd0806161532s4a205b3ey19d2aef1eb12285e@mail.gmail.com> <4856EC12.30500@wingfoot.org> Message-ID: <4856F09D.7030409@psg.com> all you people are just sooooo retro and boring. i like purple, fluorescent lime, ... the colors make no difference as long as you are consistent. labeling, consistent port use (oob port == power port == switch port ==) are what will bail you out at three in the morning. randy From Jon.Kibler at aset.com Mon Jun 16 18:01:16 2008 From: Jon.Kibler at aset.com (Jon Kibler) Date: Mon, 16 Jun 2008 19:01:16 -0400 Subject: Cable Colors In-Reply-To: <785694cd0806161532s4a205b3ey19d2aef1eb12285e@mail.gmail.com> References: <785694cd0806161532s4a205b3ey19d2aef1eb12285e@mail.gmail.com> Message-ID: <4856F0BC.5000607@aset.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 JoeSox wrote: > Hello Newbie here (hopefully I have the correct list), > Not based on any standard, but here is a schema I have used many times: White -- user workstations Black -- telephones Green -- guest users (direct Internet connection) Purple -- RJ11 data cables (modem, faxes, etc.) Yellow -- "never change" network infrastructure (inter-device, servers, printers, etc.) Orange -- serial console cable Red -- telco T1s Blue -- network infrastructure inter-device crossover Jon - -- Jon R. Kibler Chief Technical Officer Advanced Systems Engineering Technology, Inc. Charleston, SC USA o: 843-849-8214 c: 843-224-2494 s: 843-564-4224 My PGP Fingerprint is: BAA2 1F2C 5543 5D25 4636 A392 515C 5045 CF39 4253 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkhW8LwACgkQUVxQRc85QlOlmACggOnLnU7JTcSkHZH8CVlhM9ca u+4AmwRqunjI7kxRqu9VrPkdfbjIQfym =i/38 -----END PGP SIGNATURE----- ================================================== Filtered by: TRUSTEM.COM's Email Filtering Service http://www.trustem.com/ No Spam. No Viruses. Just Good Clean Email. From jgreco at ns.sol.net Mon Jun 16 18:02:40 2008 From: jgreco at ns.sol.net (Joe Greco) Date: Mon, 16 Jun 2008 18:02:40 -0500 (CDT) Subject: Cable Colors In-Reply-To: <4388DD56-30A1-4A86-824A-EEAE2F021D21@delong.com> from "Owen DeLong" at Jun 16, 2008 03:56:45 PM Message-ID: <200806162302.m5GN2eTX058340@aurora.sol.net> > I don't know of any hard standard in use anywhere. I've generally taken > to the following: > > Green == low-bandwidth straigh-through > Telephone, T1, Serial, etc. > Purple == Roll Cables (almost always serial, sometimes telecom) > (8-1 7-2 6-3 5-4 4-5 3-6 2-7 1-8) > Orange(C) == EIA-568b cross-over cable (ethernet xover) > Orange(F) == Multimode Fiber > Yellow(F) == Singlemode Fiber > White == Clear (inside VPN concentrator network) > Black == Crypt (Outside VPN concentrator network) > Blue == Publicly accessible networks > Red == Backend (usually OOB management) networks > Pink == KVM (KVM switch <-> Dongle) > > Occasionally I encounter needs for greater specificity, but, these > usually do most of what I need. Oh. That was the other thing I was going to say. Reserving some colors for "special purposes" is a good idea. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From owen at delong.com Mon Jun 16 18:09:46 2008 From: owen at delong.com (Owen DeLong) Date: Mon, 16 Jun 2008 16:09:46 -0700 Subject: Cable Colors In-Reply-To: <4856F09D.7030409@psg.com> References: <785694cd0806161532s4a205b3ey19d2aef1eb12285e@mail.gmail.com> <4856EC12.30500@wingfoot.org> <4856F09D.7030409@psg.com> Message-ID: <98B604B8-B9EA-47CD-A98B-68B602B7C0BC@delong.com> Very true. Another suggestion I will offer is that it is relatively inexpensive to order cables with pre-printed serial numbers. I get them for about $0.20/cable more than I could buy in bulk and I get them in relatively low quantities. They cost about half of what buying a cable at Fry's would cost. I use a format of XXXXXX-YY.Y where XXXXXX is a unique six digit number for the particular cable and YY.Y is the length of that particular cable. Having these serial numbers triple-printed on self-laminating labels at each end of the cable makes them very easy to read and makes it very easy to be sure before you pull a cable that the A and Z ends are of the same cable, which, can also be a saving factor at 3AM. Owen On Jun 16, 2008, at 4:00 PM, Randy Bush wrote: > all you people are just sooooo retro and boring. i like purple, > fluorescent lime, ... > > the colors make no difference as long as you are consistent. > labeling, > consistent port use (oob port == power port == switch port ==) are > what > will bail you out at three in the morning. > > randy From goemon at anime.net Mon Jun 16 18:21:39 2008 From: goemon at anime.net (goemon at anime.net) Date: Mon, 16 Jun 2008 16:21:39 -0700 (PDT) Subject: Best utilizing fat long pipes and large file transfer In-Reply-To: <200806162241.m5GMfFMO023756@sasami.anime.net> References: <200806162241.m5GMfFMO023756@sasami.anime.net> Message-ID: afaik the limit is 10 *sessions* not 10 *tcp connections*. there should be nothing limiting you from opening 10,000 tcp connections in a single app. eg 10 smb shares, 10 sql sessions, etc. -Dan On Mon, 16 Jun 2008, Bob Bradlee wrote: > I have tested it with Icecast using audio streams and it is 100 not 10. > moved to w2k server and the glass wall at 100 streams went away. > > Bob > > On Mon, 16 Jun 2008 10:25:18 -0700 (PDT), goemon at anime.net wrote: > >> On Mon, 16 Jun 2008, Glen Turner wrote: >>> Then there's the deliberate nobbling of the TCP implementation, >>> such as the restriction to ten of connections to Windows Xp SP3. >>> Apparently you're meant to buy Windows Server if you are running >>> P2P applications :-) > >> are you quite sure it is *10 tcp connections*? >> have you tested this? > >> -Dan > > > From drew.linsalata at gmail.com Mon Jun 16 18:47:46 2008 From: drew.linsalata at gmail.com (Drew Linsalata) Date: Mon, 16 Jun 2008 19:47:46 -0400 Subject: Battle Creek/Kalamazoo/Coldwater (Michigan) datacenters Message-ID: <4E1975F9-6020-400D-901B-4F0FDF230130@gmail.com> Not exactly operational, but I'm trying to help someone grab a fast-e link out of either Battle Creek or Kalamazoo for a wireless shot to Coldwater. Does anyone have any experience with facilities in that neck of the woods? From david at davidcoulson.net Mon Jun 16 18:54:51 2008 From: david at davidcoulson.net (David Coulson) Date: Mon, 16 Jun 2008 19:54:51 -0400 Subject: Cable Colors In-Reply-To: <4856F0BC.5000607@aset.com> References: <785694cd0806161532s4a205b3ey19d2aef1eb12285e@mail.gmail.com> <4856F0BC.5000607@aset.com> Message-ID: <4856FD4B.9010202@davidcoulson.net> Jon Kibler wrote: > Not based on any standard, but here is a schema I have used many times: Where I used to work - ISP. All of the above - Yellow. Where I work now - Enterprise. All of the above - Grey. David From hannigan at verneglobal.com Mon Jun 16 18:57:51 2008 From: hannigan at verneglobal.com (Martin Hannigan) Date: Mon, 16 Jun 2008 23:57:51 -0000 Subject: Cable Colors Message-ID: A little bit of the rainbow might spice up your life, Randy. Staring at all that grey cat3 is making you cranky. Personally, I like orange for console, standard powder blue for in rack termination, and red for backbone dependent. ----- Original Message ----- From: Randy Bush To: nanog at nanog.org Sent: Mon Jun 16 23:00:45 2008 Subject: Re: Cable Colors all you people are just sooooo retro and boring. i like purple, fluorescent lime, ... the colors make no difference as long as you are consistent. labeling, consistent port use (oob port == power port == switch port ==) are what will bail you out at three in the morning. randy From william.allen.simpson at gmail.com Mon Jun 16 18:58:05 2008 From: william.allen.simpson at gmail.com (William Allen Simpson) Date: Mon, 16 Jun 2008 19:58:05 -0400 Subject: Cable Colors In-Reply-To: <4856EC12.30500@wingfoot.org> References: <785694cd0806161532s4a205b3ey19d2aef1eb12285e@mail.gmail.com> <4856EC12.30500@wingfoot.org> Message-ID: <4856FE0D.5080304@gmail.com> Once upon a time, plenum-rated cable only seemed to come in white or blue, so I tried to use white consistently. Always helps to visually identify the correct usage for POPs in existing buildings. And, I've a tendency to use black for "internal network management" (unable to be seen off LAN/VPN). Easy to tell staff "don't touch", and to visually ensure going to the correct switch ports. Yellow was pretty common for crossover cables, but now-a-days it's all auto-sensing anyway. From pedro at whack.org Mon Jun 16 19:09:42 2008 From: pedro at whack.org (Peter Wohlers) Date: Mon, 16 Jun 2008 17:09:42 -0700 Subject: Cable Colors In-Reply-To: <785694cd0806161532s4a205b3ey19d2aef1eb12285e@mail.gmail.com> References: <785694cd0806161532s4a205b3ey19d2aef1eb12285e@mail.gmail.com> Message-ID: <485700C6.2020302@whack.org> JoeSox wrote: > Hello Newbie here (hopefully I have the correct list), > > I was just wondering if anyone knows of a website with recommended > colors for cables for a new datacenter? > I have written some things down but I don't want to get stuck saying > 'darn, I wish I would have bought this color for this type, now I am > stuck'. > What standard color to use if voice and data on same interface etc. Thanks. > As you can see, by and large, people assign colors to functions. What color to what function varies like the wind. Unlike a previous employer whose colo-manager person insisted on using colors to represent cable lengths (Doh!), color -> function mapping seems pretty universal. About 7% of the male population in the US has red-green colorblindness, so keep that in mind. Simpler schemes trump more complex ones (as do most things in networking) and makes cable-purchasing/stocking less of an issue. --Peter From hannigan at verneglobal.com Mon Jun 16 19:15:42 2008 From: hannigan at verneglobal.com (Martin Hannigan) Date: Tue, 17 Jun 2008 00:15:42 -0000 Subject: Cable Colors Message-ID: This seems like a good demarcation for the colors, but two things. Its a bit more expensive, and, it typically makes for a pretty mess. You're talking pre determined cable lengths for the most part. I tend to avoid patch cables like the plague and invest in long term deployments cut to length. Intelligently strapping in mostly permanent wiring should be worth the investment and reduce outages in the long run. The colors don't hurt. Best, Marty ----- Original Message ----- From: Owen DeLong To: Glenn Sieb Cc: nanog at nanog.org Sent: Mon Jun 16 22:56:45 2008 Subject: Re: Cable Colors I don't know of any hard standard in use anywhere. I've generally taken to the following: Green == low-bandwidth straigh-through Telephone, T1, Serial, etc. Purple == Roll Cables (almost always serial, sometimes telecom) (8-1 7-2 6-3 5-4 4-5 3-6 2-7 1-8) Orange(C) == EIA-568b cross-over cable (ethernet xover) Orange(F) == Multimode Fiber Yellow(F) == Singlemode Fiber White == Clear (inside VPN concentrator network) Black == Crypt (Outside VPN concentrator network) Blue == Publicly accessible networks Red == Backend (usually OOB management) networks Pink == KVM (KVM switch <-> Dongle) Occasionally I encounter needs for greater specificity, but, these usually do most of what I need. I'm sure others use entirely different choices. Owen From smb at cs.columbia.edu Mon Jun 16 19:25:57 2008 From: smb at cs.columbia.edu (Steven M. Bellovin) Date: Mon, 16 Jun 2008 20:25:57 -0400 Subject: Cable Colors In-Reply-To: <485700C6.2020302@whack.org> References: <785694cd0806161532s4a205b3ey19d2aef1eb12285e@mail.gmail.com> <485700C6.2020302@whack.org> Message-ID: <20080616202557.43e7e6f2@cs.columbia.edu> On Mon, 16 Jun 2008 17:09:42 -0700 Peter Wohlers wrote: > About 7% of the male population in the US has red-green > colorblindness, so keep that in mind. At least in my son's case, bright colors -- like the typical red and green cables -- are easily distinguishable. Pastels are more of a problem. But for proper cabling, see http://www.amazon.com/gp/product/B000I1X6PM -- and make sure you read the comments... --Steve Bellovin, http://www.cs.columbia.edu/~smb From LarrySheldon at cox.net Mon Jun 16 19:47:07 2008 From: LarrySheldon at cox.net (Laurence F. Sheldon, Jr.) Date: Mon, 16 Jun 2008 19:47:07 -0500 Subject: Cable Colors In-Reply-To: <20080616202557.43e7e6f2@cs.columbia.edu> References: <785694cd0806161532s4a205b3ey19d2aef1eb12285e@mail.gmail.com> <485700C6.2020302@whack.org> <20080616202557.43e7e6f2@cs.columbia.edu> Message-ID: <4857098B.9050704@cox.net> I am seriously old school--"patch cords" for me conjure (in addition to the modern views) 4-wire patches and coax patches (some of which were called "hairpins"). To me far more important that color is tags, one on each end if it is more that a foot long. The tags should have a short (two or three word) description, the authority for the patch (person's name or position, order number, or trouble ticket number) and where the _other_ end of the patch is, followed by where _this_ is. (For short cords "this" will cover both ends, probably. Why "this end"? Make a mistake and pull the wrong one out of a mostly clear jack-field sometime. Clarity will occur. -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs From s.ewing at aussiehq.com.au Mon Jun 16 19:47:47 2008 From: s.ewing at aussiehq.com.au (Shaun Ewing) Date: Tue, 17 Jun 2008 10:47:47 +1000 Subject: Cable Colors In-Reply-To: <4856F09D.7030409@psg.com> Message-ID: On 17/06/08 9:00 AM, "Randy Bush" wrote: > the colors make no difference as long as you are consistent. labeling, > consistent port use (oob port == power port == switch port ==) are what > will bail you out at three in the morning. > > randy And there you have it. Finding the group of backbone cables (as an example) out of a bundle of cables is much easier when they're a different colour. What colours we use depends on what area of the network we're in. For example (for the DC): - Access layer (ie: to servers): Blue - Management network (KVM, power, etc): Green - Private network (internal only): Black - Inter-rack links (don't touch): yellow - Network uplinks (really don't touch): red -Shaun From nanog at daork.net Mon Jun 16 19:57:47 2008 From: nanog at daork.net (Nathan Ward) Date: Tue, 17 Jun 2008 12:57:47 +1200 Subject: Cable Colors In-Reply-To: <4856F09D.7030409@psg.com> References: <785694cd0806161532s4a205b3ey19d2aef1eb12285e@mail.gmail.com> <4856EC12.30500@wingfoot.org> <4856F09D.7030409@psg.com> Message-ID: <78AC7B7A-DB16-483D-8A9D-67A6ADC1E29F@daork.net> On 17/06/2008, at 11:00 AM, Randy Bush wrote: > all you people are just sooooo retro and boring. i like purple, > fluorescent lime, ... > > the colors make no difference as long as you are consistent. > labeling, > consistent port use (oob port == power port == switch port ==) are > what > will bail you out at three in the morning. My cables are all black, and are scented with different citrus fruits. When I have a customer without as keen a sense of smell, I've noticed that my local patch cable vendor only does x-over in purple or beige. That made that decision for me fairly quickly. -- Nathan Ward From shrdlu at deaddrop.org Mon Jun 16 20:00:56 2008 From: shrdlu at deaddrop.org (Lynda) Date: Mon, 16 Jun 2008 18:00:56 -0700 Subject: Cable Colors In-Reply-To: <20080616202557.43e7e6f2@cs.columbia.edu> References: <785694cd0806161532s4a205b3ey19d2aef1eb12285e@mail.gmail.com> <485700C6.2020302@whack.org> <20080616202557.43e7e6f2@cs.columbia.edu> Message-ID: <48570CC8.1090605@deaddrop.org> Steven M. Bellovin wrote: > On Mon, 16 Jun 2008 17:09:42 -0700 Peter Wohlers > wrote: > > >> About 7% of the male population in the US has red-green >> colorblindness, so keep that in mind. > At least in my son's case, bright colors -- like the typical red and > green cables -- are easily distinguishable. Pastels are more of a > problem. More than 50% of males are color challenged, even when they aren't color blind. I have noted that orange and red cables near each other can easily be confused, as can blues and greens that are too similar in hue. However... > But for proper cabling, see > http://www.amazon.com/gp/product/B000I1X6PM -- and make sure you read > the comments... *That* link requires a put-down-your-coffee warning. Most notable is the number of stars in the rating, which goes hand in hand with the comments. Thank you. I still have tears in my eyes. -- In April 1951, Galaxy published C.M. Kornbluth's "The Marching Morons". The intervening years have proven Kornbluth right. --Valdis Kletnieks From jgreco at ns.sol.net Mon Jun 16 19:59:56 2008 From: jgreco at ns.sol.net (Joe Greco) Date: Mon, 16 Jun 2008 19:59:56 -0500 (CDT) Subject: Cable Colors In-Reply-To: <4857098B.9050704@cox.net> from "Laurence F. Sheldon, Jr." at Jun 16, 2008 07:47:07 PM Message-ID: <200806170059.m5H0xuhf061603@aurora.sol.net> > To me far more important that color is tags, one on each end if it is > more that a foot long. > > The tags should have a short (two or three word) description, the > authority for the patch (person's name or position, order number, or > trouble ticket number) and where the _other_ end of the patch is, > followed by where _this_ is. (For short cords "this" will cover both > ends, probably. > > Why "this end"? Make a mistake and pull the wrong one out of a mostly > clear jack-field sometime. Clarity will occur. Ha, I don't see many other people who do that. So is the labeling device of choice still the Dymo Rhino stuff? Preferences for/against heat shrink vs other methods? Always fun to see what others are doing. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From s.ewing at aussiehq.com.au Mon Jun 16 20:07:39 2008 From: s.ewing at aussiehq.com.au (Shaun Ewing) Date: Tue, 17 Jun 2008 11:07:39 +1000 Subject: Cable Colors In-Reply-To: Message-ID: On 17/06/08 10:47 AM, "Shaun Ewing" wrote: > > And there you have it. Finding the group of backbone cables (as an example) > out of a bundle of cables is much easier when they're a different colour. > > What colours we use depends on what area of the network we're in. > > For example (for the DC): > > - Access layer (ie: to servers): Blue > - Management network (KVM, power, etc): Green > - Private network (internal only): Black > - Inter-rack links (don't touch): yellow > - Network uplinks (really don't touch): red And, as I forgot to mention. Crossover cables are the same colours based on their function above with a different colour boot (red, unless the cable itself is red). -Shaun From jgreco at ns.sol.net Mon Jun 16 20:13:49 2008 From: jgreco at ns.sol.net (Joe Greco) Date: Mon, 16 Jun 2008 20:13:49 -0500 (CDT) Subject: Cable Colors In-Reply-To: <48570CC8.1090605@deaddrop.org> from "Lynda" at Jun 16, 2008 06:00:56 PM Message-ID: <200806170113.m5H1Dn7m062054@aurora.sol.net> > > But for proper cabling, see > > http://www.amazon.com/gp/product/B000I1X6PM -- and make sure you read > > the comments... > > *That* link requires a put-down-your-coffee warning. Most notable is the > number of stars in the rating, which goes hand in hand with the > comments. Thank you. I still have tears in my eyes. And it's all relative. One of the comments was: "You can get the exact same connection from a $5 digital cable." And I found myself thinking, "at that price, even that's a rip-off." But that's bulk wholesale pricing I'm thinking of, I guess, or make it yourself. Speaking of cables and veering off towards cable-making, I was wondering what people thought of the so-called "EZ RJ45" stuff. One of the hazards of doing long-term cut-to-length wiring is that if a crimp really goes wrong, you might mess up your artistic work or need to re-cut a new cable. Even having done as many cables as I've done, I occasionally have one go bad. The EZ stuff looks like an interesting compromise, does anyone with a few thousand crimps worth of experience with it have any comments? ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From herrin-nanog at dirtside.com Mon Jun 16 20:26:14 2008 From: herrin-nanog at dirtside.com (William Herrin) Date: Mon, 16 Jun 2008 21:26:14 -0400 Subject: Cable Colors In-Reply-To: <785694cd0806161532s4a205b3ey19d2aef1eb12285e@mail.gmail.com> References: <785694cd0806161532s4a205b3ey19d2aef1eb12285e@mail.gmail.com> Message-ID: <3c3e3fca0806161826y5a0907d5j1f9913e0de12f9e@mail.gmail.com> On Mon, Jun 16, 2008 at 6:32 PM, JoeSox wrote: > I was just wondering if anyone knows of a website with recommended > colors for cables for a new datacenter? > I have written some things down but I don't want to get stuck saying > 'darn, I wish I would have bought this color for this type, now I am > stuck'. > What standard color to use if voice and data on same interface etc. Thanks. Joe, Some tricks I've picked up for colorizing patch cables... Your mileage may vary. For any given cable you can control three different colors: 1. The color of the cable. 2. The color of the strain-relief boot. 3. The color of the electrical tape you wrap around the cable at each end (the same at both ends) as a quick visual ID of which endpoints are the same cable. Also, *IF* your switching matrix is straightforward, consider getting 48-port 1U "virtual chassis" switches instead of a big switch. Then interleave those switches with the 48-port patch panels on the rack and use 1' cables from the switch to the panel. It makes it oh-so-easy to trace which cable goes where and which cables are the exceptions (hint: exceptions are the only cables longer than 1'!) You get bonus points for not having to touch the cables while tracing (since that's how you knock loose other cables while hunting for the current problem). I've never had much luck attaching labels to cables. Even when the labels stay on they're impossible to quickly tell apart. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From joelja at bogus.com Mon Jun 16 20:26:22 2008 From: joelja at bogus.com (Joel Jaeggli) Date: Mon, 16 Jun 2008 18:26:22 -0700 Subject: Cable Colors In-Reply-To: <200806170113.m5H1Dn7m062054@aurora.sol.net> References: <200806170113.m5H1Dn7m062054@aurora.sol.net> Message-ID: <485712BE.3090001@bogus.com> Joe Greco wrote: > Speaking of cables and veering off towards cable-making, I was wondering > what people thought of the so-called "EZ RJ45" stuff. One of the hazards > of doing long-term cut-to-length wiring is that if a crimp really goes > wrong, you might mess up your artistic work or need to re-cut a new cable. > Even having done as many cables as I've done, I occasionally have one go > bad. The EZ stuff looks like an interesting compromise, does anyone with > a few thousand crimps worth of experience with it have any comments? They make a crimper specifically for it, which cuts of the ends. I haven't done a few thousand ends with it but it does make it slightly easier to maintain the twist further into the the plug because you can pull it until snug. I crimp infrequently enough that I occasionally don't get a spec cable when using conventional connectors. > ... JG From ge at linuxbox.org Mon Jun 16 20:32:15 2008 From: ge at linuxbox.org (Gadi Evron) Date: Mon, 16 Jun 2008 20:32:15 -0500 (CDT) Subject: Cable Colors In-Reply-To: <4856EC12.30500@wingfoot.org> References: <785694cd0806161532s4a205b3ey19d2aef1eb12285e@mail.gmail.com> <4856EC12.30500@wingfoot.org> Message-ID: On Mon, 16 Jun 2008, Glenn Sieb wrote: > JoeSox wrote: >> Hello Newbie here (hopefully I have the correct list), >> >> I was just wondering if anyone knows of a website with recommended >> colors for cables for a new datacenter? >> I have written some things down but I don't want to get stuck saying >> 'darn, I wish I would have bought this color for this type, now I am >> stuck'. >> What standard color to use if voice and data on same interface etc. Thanks. >> > > Hmm. I've always done blue for "safe" or "internal" connections, red for > machines on the DMZ or outside. > > Perhaps Blue for internal data, Yellow for internal voice, Green for > data/voice? > > Don't know if there's a website on this, but you can definitely read about it > in Tom Limoncelli's The Practice of System and Network Administration book. Others responded with what colour goes for what. Me? I learned that these colour conventions change drastically from one place to another. Other than which interface or network you may be using, there is the issues of "sensitive"/secret network and white/public network. In one organization red was for the sensitive private network, and in another red meant "danger Will Robinson", public unsafe network. In yet another red was for grounded power. Use what works for you. Warning about colours with a funny anecdote: In a more secure network I ran security for, networks were literally separated and colour coded cables were enforced. One day a cable needed to be replaced but we ran out of the said colour. The engineer was so scared of what the then security director (before my time) would say that he didn't fix the network for .. some time... until someone smacked him on the back of the head (the security director). To be fair the the engineer, he was really concerned about security. Security-minded networks have their own silly downsides. :) Use what is comfortable and/or necessary, no more. Gadi. From joesox at gmail.com Mon Jun 16 20:44:01 2008 From: joesox at gmail.com (JoeSox) Date: Mon, 16 Jun 2008 18:44:01 -0700 Subject: Cable Colors In-Reply-To: References: <785694cd0806161532s4a205b3ey19d2aef1eb12285e@mail.gmail.com> <4856EC12.30500@wingfoot.org> Message-ID: <785694cd0806161844w5a126ebdg146e2fb399f190b1@mail.gmail.com> I'll save the bandwidth and reply to everyone in one email :P Lots of good replies, gave me lots of ideas and confirmed my planning already. I like the idea of reserving some colors and the serial numbers idea. Some people seem were wishing I provided more details so my 'datacenter' basically has a D3 and has a bunch of T1s MPLS and some tunnels running. Got some different VLANs and upper management would like to seperate cable color by device type but I would rather do it by VLAN. We are running VOIP and some workstation are running data thru the phone to the patchpanel to the switch. Got two Juniper firewalls clustered, not sure how to color code those but I'm sure I'll figure it out. I reserve for SPAWAR and have inspected a bunch of Navy networks, luckily I don't have THAT much crypto to worry about. Maybe I'll create a webpage on what I came up with! Thanks again for all the replies. -- Thank You, Joe From deballing at vassar.edu Mon Jun 16 20:49:55 2008 From: deballing at vassar.edu (Derek J. Balling) Date: Mon, 16 Jun 2008 21:49:55 -0400 Subject: Cable Colors In-Reply-To: <200806170059.m5H0xuhf061603@aurora.sol.net> References: <200806170059.m5H0xuhf061603@aurora.sol.net> Message-ID: <77FEF6E3-A1B9-4C19-8648-FDDA6CC47A5A@vassar.edu> On Jun 16, 2008, at 8:59 PM, Joe Greco wrote: > So is the labeling device of choice still the Dymo Rhino stuff? > Preferences for/against heat shrink vs other methods? Always fun to > see > what others are doing. Brady TLS2200. There is no substitute. Self-laminating multiline labels you simply wrap around the cable to form a sleeve. No heat-shrink required, just print, peel and stick. Cheers, D -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2478 bytes Desc: not available URL: From jgreco at ns.sol.net Mon Jun 16 21:07:19 2008 From: jgreco at ns.sol.net (Joe Greco) Date: Mon, 16 Jun 2008 21:07:19 -0500 (CDT) Subject: Cable Colors In-Reply-To: <485712BE.3090001@bogus.com> from "Joel Jaeggli" at Jun 16, 2008 06:26:22 PM Message-ID: <200806170207.m5H27J7t065585@aurora.sol.net> > They make a crimper specifically for it, which cuts of the ends. I > haven't done a few thousand ends with it but it does make it slightly > easier to maintain the twist further into the the plug because you can > pull it until snug. Yeah, I am reluctant to go retooling for that crimper. I had idly ordered some of the crimps one day, just to get a better look, thinking I might be able to get away with a two-step "crimp and then use-a-flush-cutter" on it. Not practical. Bah. So my initial impression is that it might help with the annoyance of having to massage the cable when one of the conductors isn't quite working out, but the need to straighten a greater length of each conductor is completely at odds with my cable-making style, where I'm an old fashioned pinch-n-wiggle straightening all eight conductors at the same time, which is only good for maybe 1/2" of straightening, which DOES not work for these silly things. Other than completely ruining my day with respect to that, I was relatively impressed with the quality of Cat6 cable I was able to throw together, and that the twist could be pulled until snug, as you noted. It also looks like it would be good for avoiding the usual problems you run into with new people who can't for the life of them make a crimp where the jacket doesn't pull out of the crimp at the first brief glance the cable experiences. I was less impressed that the boots are only available for Cat6. Interesting, though. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From petelists at templin.org Mon Jun 16 21:14:07 2008 From: petelists at templin.org (Pete Templin) Date: Mon, 16 Jun 2008 21:14:07 -0500 Subject: Cable Colors In-Reply-To: <200806170207.m5H27J7t065585@aurora.sol.net> References: <200806170207.m5H27J7t065585@aurora.sol.net> Message-ID: <48571DEF.1070207@templin.org> Joe Greco wrote: >> They make a crimper specifically for it, which cuts of the ends. I >> haven't done a few thousand ends with it but it does make it slightly >> easier to maintain the twist further into the the plug because you can >> pull it until snug. > > Yeah, I am reluctant to go retooling for that crimper. I had idly ordered > some of the crimps one day, just to get a better look, thinking I might be > able to get away with a two-step "crimp and then use-a-flush-cutter" on it. > Not practical. Bah. I've had good success (when forced to use those heads) with pulling til snug, cutting with a flush cutter, then backing off ever so slightly so the ends aren't hanging out in short-land. I use the same tools the same number of times as I do for other heads, but I pick them up in a difference sequence, so there's no gain without the custom crimper. I avoid them if at all possible though, and carry plenty of "preferred" heads to any project where I might want them. pt From mksmith at adhost.com Mon Jun 16 21:15:06 2008 From: mksmith at adhost.com (Michael Smith) Date: Mon, 16 Jun 2008 19:15:06 -0700 Subject: Cable Colors In-Reply-To: <785694cd0806161532s4a205b3ey19d2aef1eb12285e@mail.gmail.com> Message-ID: Hi Joe: > > Hello Newbie here (hopefully I have the correct list), > > I was just wondering if anyone knows of a website with recommended > colors for cables for a new datacenter? > I have written some things down but I don't want to get stuck saying > 'darn, I wish I would have bought this color for this type, now I am > stuck'. > What standard color to use if voice and data on same interface etc. Thanks. > -- > Thank You, Joe > I have found that it's better not to standardize on wire color because someone will always use the wrong color in a pinch if it will solve an immediate problem. Instead, come up with a labeling system that clearly defines the physical source and destination of the wire. Mike From christian at broknrobot.com Mon Jun 16 21:20:59 2008 From: christian at broknrobot.com (Christian Koch) Date: Mon, 16 Jun 2008 22:20:59 -0400 Subject: Cable Colors In-Reply-To: References: <785694cd0806161532s4a205b3ey19d2aef1eb12285e@mail.gmail.com> Message-ID: i guess thats what having a good data center manager is all about - being prepared and keeping things uniform and to a standard they define... On Mon, Jun 16, 2008 at 10:15 PM, Michael Smith wrote: > Hi Joe: > > > > Hello Newbie here (hopefully I have the correct list), > > > > I was just wondering if anyone knows of a website with recommended > > colors for cables for a new datacenter? > > I have written some things down but I don't want to get stuck saying > > 'darn, I wish I would have bought this color for this type, now I am > > stuck'. > > What standard color to use if voice and data on same interface etc. > Thanks. > > -- > > Thank You, Joe > > > > I have found that it's better not to standardize on wire color because > someone will always use the wrong color in a pinch if it will solve an > immediate problem. Instead, come up with a labeling system that clearly > defines the physical source and destination of the wire. > > Mike > > > From matthew at eeph.com Mon Jun 16 21:23:31 2008 From: matthew at eeph.com (Matthew Kaufman) Date: Mon, 16 Jun 2008 19:23:31 -0700 Subject: Cable Colors In-Reply-To: <485700C6.2020302@whack.org> References: <785694cd0806161532s4a205b3ey19d2aef1eb12285e@mail.gmail.com> <485700C6.2020302@whack.org> Message-ID: <48572023.1010205@eeph.com> Peter Wohlers wrote: > As you can see, by and large, people assign colors to functions. What > color to what function varies like the wind. Unlike a previous employer > whose colo-manager person insisted on using colors to represent cable > lengths (Doh!), color -> function mapping seems pretty universal. I used to do that too... Until I stood behind a rack trying to figure out which of the 70 or so gray wires from the switch was the one going to the box I was having the problem with. Then I bought as many different colors as I could find, and mixed things up a bit. Matthew Kaufman From blakjak at blakjak.net Mon Jun 16 21:24:57 2008 From: blakjak at blakjak.net (Mark Foster) Date: Tue, 17 Jun 2008 14:24:57 +1200 (NZST) Subject: Cable Colors In-Reply-To: <485712BE.3090001@bogus.com> References: <200806170113.m5H1Dn7m062054@aurora.sol.net> <485712BE.3090001@bogus.com> Message-ID: On Mon, 16 Jun 2008, Joel Jaeggli wrote: > Joe Greco wrote: >> Speaking of cables and veering off towards cable-making, I was wondering >> what people thought of the so-called "EZ RJ45" stuff. One of the hazards >> of doing long-term cut-to-length wiring is that if a crimp really goes >> wrong, you might mess up your artistic work or need to re-cut a new cable. >> Even having done as many cables as I've done, I occasionally have one go >> bad. The EZ stuff looks like an interesting compromise, does anyone with >> a few thousand crimps worth of experience with it have any comments? > > They make a crimper specifically for it, which cuts of the ends. I haven't > done a few thousand ends with it but it does make it slightly easier to > maintain the twist further into the the plug because you can pull it until > snug. > > I crimp infrequently enough that I occasionally don't get a spec cable when > using conventional connectors. > I find this interesting - as lately i've found that keeping a supply of various lengths of commercially-manufactured leads of appropriate colours, etc, has been a better long term solution than home-made leads. Perhaps I just suck at crimping cables, but I prefer to use commercially made (and tested) leads. The drawback, of course, is when you run out of the right length and wind up using longer cables, which in turn makes cable management a bit of a mess... The key of course is Discipline - use the right cable, run the right path... ala 'do it once, do it right'. I've had cause in the past to take down entire cabinets for a matter of hours while all cabling is mapped, removed and re-fitted (using newer cables / of the right colour / of the right length / actually _using_ cable management bars). [Such outages are often a good opportunity to replace switch equipment with newer gear. I assume we're all OK with electronically tagging ports with useful descriptions too??) One labelling option I've seen used: http://www.kableflags.com.au/ Another is of course, Dymo - but after a few years these can look tatty (if they don't fall off entirely)... Mark. From smb at cs.columbia.edu Mon Jun 16 21:28:24 2008 From: smb at cs.columbia.edu (Steven M. Bellovin) Date: Mon, 16 Jun 2008 22:28:24 -0400 Subject: Cable Colors In-Reply-To: References: <785694cd0806161532s4a205b3ey19d2aef1eb12285e@mail.gmail.com> <4856EC12.30500@wingfoot.org> Message-ID: <20080616222824.1f8dc652@cs.columbia.edu> On Mon, 16 Jun 2008 20:32:15 -0500 (CDT) Gadi Evron wrote: > In one organization red was for the sensitive private network, and in > another red meant "danger Will Robinson", public unsafe network. In > yet another red was for grounded power. > Right. The universal convention in NSA-type crypto gear is red==cleartext, black==ciphertext. Designs have to provide proper "red/black separation". But when Bill Cheswick and I put in the Bell Labs firewall in the early 1990s, we used red cables for the dangerous outside net. --Steve Bellovin, http://www.cs.columbia.edu/~smb From christian at broknrobot.com Mon Jun 16 21:40:30 2008 From: christian at broknrobot.com (Christian Koch) Date: Mon, 16 Jun 2008 22:40:30 -0400 Subject: Elanti Inteligent Routing.. Message-ID: anyone with firsthand operational experience with this? pro's, con's? feedback? ck From web at typo.org Mon Jun 16 22:04:55 2008 From: web at typo.org (Wayne E. Bouchard) Date: Mon, 16 Jun 2008 20:04:55 -0700 Subject: Cable Colors In-Reply-To: <4856EC12.30500@wingfoot.org> References: <785694cd0806161532s4a205b3ey19d2aef1eb12285e@mail.gmail.com> <4856EC12.30500@wingfoot.org> Message-ID: <20080617030455.GA69924@typo.org> Oppinions vary. There really is no standard. Most important is picking something meaningful to you. Here, I use: yellow general ethernet green serial connection blue long distance ethernet (ie, going to another row) black crossover red T1s, etc white permenant drops to cabinets, lashed down and brown cat3 for POTs lines Some people use like dark blue for the first ethernet connection to a machine and light blue for the second connection. It really just depends on what you want to accomplish. Just pick something tha tworks for you and stick with it. On Mon, Jun 16, 2008 at 06:41:22PM -0400, Glenn Sieb wrote: > JoeSox wrote: > >Hello Newbie here (hopefully I have the correct list), > > > >I was just wondering if anyone knows of a website with recommended > >colors for cables for a new datacenter? > >I have written some things down but I don't want to get stuck saying > >'darn, I wish I would have bought this color for this type, now I am > >stuck'. > >What standard color to use if voice and data on same interface etc. Thanks. > > > > Hmm. I've always done blue for "safe" or "internal" connections, red for > machines on the DMZ or outside. > > Perhaps Blue for internal data, Yellow for internal voice, Green for > data/voice? > > Don't know if there's a website on this, but you can definitely read > about it in Tom Limoncelli's The Practice of System and Network > Administration book. > > Best, > --Glenn > > -- > ...destination is merely a byproduct of the journey > --Eric Hansen > --- Wayne Bouchard web at typo.org Network Dude http://www.typo.org/~web/ From jgreco at ns.sol.net Mon Jun 16 22:26:41 2008 From: jgreco at ns.sol.net (Joe Greco) Date: Mon, 16 Jun 2008 22:26:41 -0500 (CDT) Subject: Cable Colors In-Reply-To: from "Mark Foster" at Jun 17, 2008 02:24:57 PM Message-ID: <200806170326.m5H3QfwE071681@aurora.sol.net> > I find this interesting - as lately i've found that keeping a supply of > various lengths of commercially-manufactured leads of appropriate colours, > etc, has been a better long term solution than home-made leads. Perhaps I > just suck at crimping cables, but I prefer to use commercially made (and > tested) leads. > > The drawback, of course, is when you run out of the right length and wind > up using longer cables, which in turn makes cable management a bit of a > mess... Maybe we just wire in more tight places, but I find that it's somewhat difficult to deal with more than about three excess inches when doing in-frame wiring. I don't want to have to deal with excess. It is (maybe was? haven't looked in several years) difficult to find someplace that will manufacture quality Cat6 molded cords in arbitrary lengths in relatively small quantities. There's a million places that will be happy to custom-make you Cat6 crimped or crimped+booted cables, but if I wanted that, I could hire a monkey to make them for us at a cheaper price. If I'm going manufactured prefab, I want molded. Given that, and given that the shop (where we could maintain significant stock) is not always convenient (for ex., equipment in Ashburn, shop in Milwaukee) the easier solution has typically been to keep a few 1000' spools and make cables to exact length as needed. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From steve at ibctech.ca Mon Jun 16 22:47:53 2008 From: steve at ibctech.ca (Steve Bertrand) Date: Mon, 16 Jun 2008 23:47:53 -0400 Subject: SMTP no-such-user issues Message-ID: <485733E9.5030008@ibctech.ca> Hi everyone, We are experiencing an issue in regards to SMTP MTA relay responses regarding 'no such user', and it *apparently* appears to be only occurring when a particular site attempts to deliver email to us. Any advice on how to further troubleshoot my issue would be greatly appreciated. I want to keep this as brief as possible...please bear with me. We have a cluster of Barracuda Spam Firewalls operating as an SMTP server/client to a cluster of Qmail MTA/MDA's (with CHKUSR in place). In short, a user from Sympatico (which now delivers via Hotmail) sends an email to a list of addresses at our domain in which only a single one of those addresses is bad, a response is sent back to the Sympatico client advising that ALL the destination addresses were bad, which is not the case. It doesn't matter whether the recipients were listed in the RCPT field, or within the DATA field as Cc: or Bcc:. This is a nightmare on the helpdesk. When I attempt to simulate the issue from ANY other mail system that I've tested (my own personal, GMail etc, etc), the legitimate addresses receive the message, and the relay agent in question in the test scenario sends back a 551 for ONLY the invalid recip, as opposed to including even the valid recips. Although it has not been yet completely verified via logs that the client SMTP server sends a QUIT before verifying all of the addresses, it certainly appears thus far that all of the addresses are put through the standard verification stages prior to DATA and then gives up, even if the invalid recipient is the last one passed to our system. Can anyone else provide advise on how to further troubleshoot this, or for those who live in my part of North America (Toronto), test it for themselves who have MTA bounce-no-recip in place, that have access to the Hotmail mail system (I've confirmed the exact same problem exists (the 551 is very near identical) from a web-based Hotmail address as well as Sympatico). Examples of logs and bounces can be provided if necessary. Thanks, Steve From jra at baylink.com Mon Jun 16 22:47:52 2008 From: jra at baylink.com (Jay R. Ashworth) Date: Mon, 16 Jun 2008 23:47:52 -0400 Subject: Cable Colors In-Reply-To: <4856EF52.5090904@gmail.com> References: <785694cd0806161532s4a205b3ey19d2aef1eb12285e@mail.gmail.com> <4856EC12.30500@wingfoot.org> <4856EF52.5090904@gmail.com> Message-ID: <20080617034752.GA30714@cgi.jachomes.com> On Mon, Jun 16, 2008 at 06:55:14PM -0400, Soren Telfer wrote: > TIA-606A and some of the other TIA docs have cable color recommendations. This is the standard recommended by the Yellow Book for cable jacket color selection, yes. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com '87 e24 St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 Those who cast the vote decide nothing. Those who count the vote decide everything. -- (Joseph Stalin) From mksmith at adhost.com Mon Jun 16 22:55:54 2008 From: mksmith at adhost.com (Michael Smith) Date: Mon, 16 Jun 2008 20:55:54 -0700 Subject: Cable Colors In-Reply-To: Message-ID: And not having to worry about a color-blind tech. :-) Mike From: Christian Koch Date: Mon, 16 Jun 2008 22:20:59 -0400 To: Michael Smith Cc: JoeSox , Subject: Re: Cable Colors i guess thats what having a good data center manager is all about - being prepared and keeping things uniform and to a standard they define... On Mon, Jun 16, 2008 at 10:15 PM, Michael Smith wrote: > Hi Joe: >> > >> > Hello Newbie here (hopefully I have the correct list), >> > >> > I was just wondering if anyone knows of a website with recommended >> > colors for cables for a new datacenter? >> > I have written some things down but I don't want to get stuck saying >> > 'darn, I wish I would have bought this color for this type, now I am >> > stuck'. >> > What standard color to use if voice and data on same interface etc. Thanks. >> > -- >> > Thank You, Joe >> > > > I have found that it's better not to standardize on wire color because > someone will always use the wrong color in a pinch if it will solve an > immediate problem. Instead, come up with a labeling system that clearly > defines the physical source and destination of the wire. > > Mike > > From jra at baylink.com Mon Jun 16 22:58:00 2008 From: jra at baylink.com (Jay R. Ashworth) Date: Mon, 16 Jun 2008 23:58:00 -0400 Subject: Cable Colors In-Reply-To: <200806170326.m5H3QfwE071681@aurora.sol.net> References: <200806170326.m5H3QfwE071681@aurora.sol.net> Message-ID: <20080617035800.GC30714@cgi.jachomes.com> On Mon, Jun 16, 2008 at 10:26:41PM -0500, Joe Greco wrote: > Maybe we just wire in more tight places, but I find that it's somewhat > difficult to deal with more than about three excess inches when doing > in-frame wiring. I don't want to have to deal with excess. Perhaps it's because my wiring background, such as it is, runs more to video than networking... but doesn't *anyone* put service loops in anything anymore? Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com '87 e24 St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 Those who cast the vote decide nothing. Those who count the vote decide everything. -- (Joseph Stalin) From nanog at armorfirewall.com Mon Jun 16 23:07:35 2008 From: nanog at armorfirewall.com (George Imburgia) Date: Tue, 17 Jun 2008 00:07:35 -0400 (EDT) Subject: Cable Colors - A Standard In-Reply-To: <20080617035800.GC30714@cgi.jachomes.com> References: <200806170326.m5H3QfwE071681@aurora.sol.net> <20080617035800.GC30714@cgi.jachomes.com> Message-ID: There's a standard; ANSI/TIA/EIA 606A http://www.flexcomm.com/library/606aguide.pdf Page 23 From jgreco at ns.sol.net Mon Jun 16 23:27:43 2008 From: jgreco at ns.sol.net (Joe Greco) Date: Mon, 16 Jun 2008 23:27:43 -0500 (CDT) Subject: Cable Colors In-Reply-To: <20080617035800.GC30714@cgi.jachomes.com> from "Jay R. Ashworth" at Jun 16, 2008 11:58:00 PM Message-ID: <200806170427.m5H4RhZx073414@aurora.sol.net> > On Mon, Jun 16, 2008 at 10:26:41PM -0500, Joe Greco wrote: > > Maybe we just wire in more tight places, but I find that it's somewhat > > difficult to deal with more than about three excess inches when doing > > in-frame wiring. I don't want to have to deal with excess. > > Perhaps it's because my wiring background, such as it is, runs more to > video than networking... > > but doesn't *anyone* put service loops in anything anymore? Assuming you're using "service loops" in the sense of allowing enough cable to allow a server to slide out while running... usually in copper building wiring, the term loosely refers to excess cable or whathaveyou stuffed back into the conduit/cavity/box to allow for the fixture to be pulled out and worked on. When you've got a dense rack (think something like 30 1U servers, with a minimum of 4 x Cat5/6/etc to each one), "service loops" are a great way to significantly reduce your airflow. Think about how far you have to pull a server out... is anything significantly less than 30" deep these days? That means a lot of wire to store. When it isn't mission critical that downtime be minimized to the second, it changes the perspective on whether or not you need to be able to pull equipment while having it still running. So, if you really need the capability, an alternate method for providing "service loops" is to simply swap out cables. You disconnect the precut, swap in a nice long cable. Pull out your server. You lose connectivity for a moment or two, but don't need to make arrangements for extra feet of cable per each 1U. Each situation will have tradeoffs. Pick appropriately, as always. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From jra at baylink.com Mon Jun 16 23:31:36 2008 From: jra at baylink.com (Jay R. Ashworth) Date: Tue, 17 Jun 2008 00:31:36 -0400 Subject: Cable Colors In-Reply-To: <200806170427.m5H4RhZx073414@aurora.sol.net> References: <20080617035800.GC30714@cgi.jachomes.com> <200806170427.m5H4RhZx073414@aurora.sol.net> Message-ID: <20080617043136.GB30920@cgi.jachomes.com> On Mon, Jun 16, 2008 at 11:27:43PM -0500, Joe Greco wrote: [ quoting me ] > > but doesn't *anyone* put service loops in anything anymore? > > Assuming you're using "service loops" in the sense of allowing enough > cable to allow a server to slide out while running... usually in copper > building wiring, the term loosely refers to excess cable or whathaveyou > stuffed back into the conduit/cavity/box to allow for the fixture to be > pulled out and worked on. > > When you've got a dense rack (think something like 30 1U servers, with a > minimum of 4 x Cat5/6/etc to each one), "service loops" are a great way > to significantly reduce your airflow. Think about how far you have to > pull a server out... is anything significantly less than 30" deep these > days? That means a lot of wire to store. When it isn't mission critical > that downtime be minimized to the second, it changes the perspective on > whether or not you need to be able to pull equipment while having it > still running. True. And I'm Mr Just Unplug It For A Second To Move The Cable, too. > Each situation will have tradeoffs. Pick appropriately, as always. Excellent reminder. Cheers, -- jra -- Jay R. Ashworth jra at baylink.com Designer +-Internetworking------+---------+ RFC 2100 Ashworth & Associates | Best Practices Wiki | | '87 e24 St Petersburg FL USA +-http://bestpractices.wikia.com-+ +1 727 647 1274 If you can read this... thank a system administrator. Or two. --me From steve at ibctech.ca Mon Jun 16 23:38:08 2008 From: steve at ibctech.ca (Steve Bertrand) Date: Tue, 17 Jun 2008 00:38:08 -0400 Subject: Cable Colors In-Reply-To: <4856FD4B.9010202@davidcoulson.net> References: <785694cd0806161532s4a205b3ey19d2aef1eb12285e@mail.gmail.com> <4856F0BC.5000607@aset.com> <4856FD4B.9010202@davidcoulson.net> Message-ID: <48573FB0.4020901@ibctech.ca> David Coulson wrote: > Jon Kibler wrote: >> Not based on any standard, but here is a schema I have used many times: > > > Where I used to work - ISP. All of the above - Yellow. > Where I work now - Enterprise. All of the above - Grey. LOL, simplicity via obscurity at its finest ;) Colour coding works great, and it's easy to follow. Then there is that issue that pops up where *that* cable over there will work! Steve From david at davidcoulson.net Mon Jun 16 23:44:18 2008 From: david at davidcoulson.net (David Coulson) Date: Tue, 17 Jun 2008 00:44:18 -0400 Subject: Cable Colors In-Reply-To: <48573FB0.4020901@ibctech.ca> References: <785694cd0806161532s4a205b3ey19d2aef1eb12285e@mail.gmail.com> <4856F0BC.5000607@aset.com> <4856FD4B.9010202@davidcoulson.net> <48573FB0.4020901@ibctech.ca> Message-ID: <48574122.405@davidcoulson.net> Steve Bertrand wrote: > LOL, simplicity via obscurity at its finest ;) > > Colour coding works great, and it's easy to follow. Then there is that > issue that pops up where *that* cable over there will work! > 90% of our movable cable patches (aka stuff that is not hard wired into a patch panel) are less than three feet long and are totally enclosed within individual racks (e.g. server to top of rack switch, switch to patch panel, other side of patch panel to core) - Each end of the cable is labeled, so it's pretty easy to trace it. I care more about cable management when you have something like a 6513 with a bunch of 48 port Ethernet blades. Not figured out a way to deal with that which doesn't look like complete crap - Doesn't matter what color they are. The vertical 7600s/6509-VE models are nice, but of course, we don't have those :) David From steve at ibctech.ca Tue Jun 17 00:03:32 2008 From: steve at ibctech.ca (Steve Bertrand) Date: Tue, 17 Jun 2008 01:03:32 -0400 Subject: Cable Colors In-Reply-To: <48574122.405@davidcoulson.net> References: <785694cd0806161532s4a205b3ey19d2aef1eb12285e@mail.gmail.com> <4856F0BC.5000607@aset.com> <4856FD4B.9010202@davidcoulson.net> <48573FB0.4020901@ibctech.ca> <48574122.405@davidcoulson.net> Message-ID: <485745A4.3080406@ibctech.ca> David Coulson wrote: > Steve Bertrand wrote: >> LOL, simplicity via obscurity at its finest ;) >> >> Colour coding works great, and it's easy to follow. Then there is that >> issue that pops up where *that* cable over there will work! >> > 90% of our movable cable patches (aka stuff that is not hard wired into > a patch panel) are less than three feet long and are totally enclosed > within individual racks (e.g. server to top of rack switch, switch to > patch panel, other side of patch panel to core) - Each end of the cable > is labeled, so it's pretty easy to trace it. Labeling is good. As I've tried to follow the pace of this thread, I appreciate where someone else stated that (paraphrased) "males essentially have a problem with identifying colours". I personally am relatively colour blind (mostly red-orange are the same, as is black-green). > I care more about cable management when you have something like a 6513 > with a bunch of 48 port Ethernet blades. Not figured out a way to deal > with that which doesn't look like complete crap - Doesn't matter what > color they are. The vertical 7600s/6509-VE models are nice, but of > course, we don't have those :) A very good friend of mine who is relatively quite older than I, used to run what we (I) would call now the 'IT' department in the Butterfield Bank of Bermuda way back years ago (relative), showed me pictures of closets which had numerous hundreds of Token Ring MAU connectors, attached to cabling dozens of feet long stretched down a corridor 100' at least after an effort to 'untangle' the typical 'this needs to be patched *to this floor*'. I will forever remember those pictures, and forever know that no matter how badly labeled/coloured an Ethernet infrastructure environment is, it can never be as bad as having several hundreds of cables as thick as my baby finger, all the same colour, entangled in a mess worse than anything I've seen. I would like to know ANYONE who has a policy strict enough, and enforces it so as to have even an almost perfect cabling infrastructure...is there such a thing? God bless CATx cable, especially when it terminates within the same area that it originates from ;) Steve From owen at delong.com Tue Jun 17 01:01:10 2008 From: owen at delong.com (Owen DeLong) Date: Mon, 16 Jun 2008 23:01:10 -0700 Subject: Cable Colors In-Reply-To: References: Message-ID: <45941DC5-AEA5-451B-ADEF-E13B13386ED9@delong.com> I work around the mess issue by stocking in 1/2 foot increments. Sure you sometimes get a little extra at the ends, but, with a maximum of 6" extra to deal with, it's usually not much of a mess and can mostly be absorbed within the width of the vertical and height of the horizontal cable managers at each end. Yes, it's a wee bit more expensive. In long term deployments, custom-cut to length on site might make sense, but, I work in dynamic and changing environments where a given cable's life-span varies unpredictably between a few days and several years. In that environment, cut-to- length requires more staff and cost than my budget allows. Velcro cable wraps are your friend and the pre-printed serial/length labels at each end help a lot in the long run, too. Owen On Jun 16, 2008, at 5:15 PM, Martin Hannigan wrote: > > This seems like a good demarcation for the colors, but two things. > Its a bit more expensive, and, it typically makes for a pretty mess. > You're talking pre determined cable lengths for the most part. I > tend to avoid patch cables like the plague and invest in long term > deployments cut to length. > > Intelligently strapping in mostly permanent wiring should be worth > the investment and reduce outages in the long run. The colors don't > hurt. > > Best, > > Marty > > > > > ----- Original Message ----- > From: Owen DeLong > To: Glenn Sieb > Cc: nanog at nanog.org > Sent: Mon Jun 16 22:56:45 2008 > Subject: Re: Cable Colors > > I don't know of any hard standard in use anywhere. I've generally > taken > to the following: > > Green == low-bandwidth straigh-through > Telephone, T1, Serial, etc. > Purple == Roll Cables (almost always serial, sometimes telecom) > (8-1 7-2 6-3 5-4 4-5 3-6 2-7 1-8) > Orange(C) == EIA-568b cross-over cable (ethernet xover) > Orange(F) == Multimode Fiber > Yellow(F) == Singlemode Fiber > White == Clear (inside VPN concentrator network) > Black == Crypt (Outside VPN concentrator network) > Blue == Publicly accessible networks > Red == Backend (usually OOB management) networks > Pink == KVM (KVM switch <-> Dongle) > > Occasionally I encounter needs for greater specificity, but, these > usually do most of what I need. > > I'm sure others use entirely different choices. > > Owen > > From owen at delong.com Tue Jun 17 01:11:45 2008 From: owen at delong.com (Owen DeLong) Date: Mon, 16 Jun 2008 23:11:45 -0700 Subject: Cable Colors In-Reply-To: <200806170059.m5H0xuhf061603@aurora.sol.net> References: <200806170059.m5H0xuhf061603@aurora.sol.net> Message-ID: <66CB287F-3274-49E0-AB7D-AA92F07C66CB@delong.com> On Jun 16, 2008, at 5:59 PM, Joe Greco wrote: >> To me far more important that color is tags, one on each end if it is >> more that a foot long. >> >> The tags should have a short (two or three word) description, the >> authority for the patch (person's name or position, order number, or >> trouble ticket number) and where the _other_ end of the patch is, >> followed by where _this_ is. (For short cords "this" will cover both >> ends, probably. >> >> Why "this end"? Make a mistake and pull the wrong one out of a >> mostly >> clear jack-field sometime. Clarity will occur. > > Ha, I don't see many other people who do that. > > So is the labeling device of choice still the Dymo Rhino stuff? > Preferences for/against heat shrink vs other methods? Always fun to > see > what others are doing. I'm very fond of the Brady with the self-laminating wrap-around vinyl labels. Owen From owen at delong.com Tue Jun 17 01:31:13 2008 From: owen at delong.com (Owen DeLong) Date: Mon, 16 Jun 2008 23:31:13 -0700 Subject: Cable Colors In-Reply-To: References: Message-ID: <01222EB0-4D92-43B0-AA68-F006BC986DEB@delong.com> On Jun 16, 2008, at 7:15 PM, Michael Smith wrote: > Hi Joe: >> >> Hello Newbie here (hopefully I have the correct list), >> >> I was just wondering if anyone knows of a website with recommended >> colors for cables for a new datacenter? >> I have written some things down but I don't want to get stuck saying >> 'darn, I wish I would have bought this color for this type, now I am >> stuck'. >> What standard color to use if voice and data on same interface etc. >> Thanks. >> -- >> Thank You, Joe >> > > I have found that it's better not to standardize on wire color because > someone will always use the wrong color in a pinch if it will solve an > immediate problem. Instead, come up with a labeling system that > clearly > defines the physical source and destination of the wire. > > Mike > Indeed, we solve the former problem using the latter solution. If someone uses the wrong color, we require them to do the following: 1. Do NOT install the cable into the cable management. Leave it hanging. 2. Use labels to label the intended color of the cable at each end and at 2' increments along the length of the cable if it is more than 3.5 feet long. Owen From Gregoire.VILLAIN at ingenico.com Tue Jun 17 03:52:58 2008 From: Gregoire.VILLAIN at ingenico.com (=?iso-8859-1?Q?Gr=E9goire_VILLAIN?=) Date: Tue, 17 Jun 2008 10:52:58 +0200 Subject: VZB colocation facilities Message-ID: <72CF8F2B2766084DBD7AEAFCAE4A3B790744A409@frsnprexc1.usr.ingenico.loc> Hi all, Can anyone with experience in Verizon Business colocation facilities in NYC, Sydney & Paris contact me off-list ? I'm looking for express feedback here. Also, pointers to decent & cost efficient facilities in NY would be welcome from anyone, I'm a little helpless here... (I'm based in Paris) Cheers & thanks a lot, Greg VILLAIN About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From Rod.Beck at hiberniaatlantic.com Tue Jun 17 03:58:59 2008 From: Rod.Beck at hiberniaatlantic.com (Rod Beck) Date: Tue, 17 Jun 2008 09:58:59 +0100 Subject: If bandwidth wasnt already cheap (!) enough .. References: <48562CB2.6090200@entagroup.com> <4856B2FA.2080802@ai.net> Message-ID: <71CB284A12EDA54880FF588A8BAC0BE221FF92@ernie.HiberniaAtlantic.local> I'm pretty sure the answer is no. Roderick S. Beck Director of European Sales Hibernia Atlantic 1, Passage du Chantier, 75012 Paris http://www.hiberniaatlantic.com From steve at ibctech.ca Tue Jun 17 06:13:43 2008 From: steve at ibctech.ca (Steve Bertrand) Date: Tue, 17 Jun 2008 07:13:43 -0400 Subject: SMTP no-such-user issues In-Reply-To: <485733E9.5030008@ibctech.ca> References: <485733E9.5030008@ibctech.ca> Message-ID: <48579C67.7000209@ibctech.ca> Steve Bertrand wrote: > Hi everyone, > > We are experiencing an issue in regards to SMTP MTA relay responses > regarding 'no such user', and it *apparently* appears to be only > occurring when a particular site attempts to deliver email to us. Any > advice on how to further troubleshoot my issue would be greatly > appreciated. Because I have been inundated with off-list replies, I'll post my findings here. First, a screen cap of me composing a message, in which two of the addresses are easily identified as valid, and two are clearly not: http://ibctech.ca/nanog_smtp/hotmail_compose.jpg ...when I sent it, I received thus: http://ibctech.ca/nanog_smtp/hotmail_response.txt So, we'll try it from a different server: http://ibctech.ca/nanog_smtp/local_compose.jpg ...hmmm, I received the message at steveb at eagle.ca (even though the To: field was cropped out of the jpg) this time, and my server generated the following....AFAICT, correct 551 error(s): http://ibctech.ca/nanog_smtp/local_err.txt I'm willing to provide any more documentation required in order to get this issue sorted. Thank you everyone, I truly appreciate it. Steve From francois at menards.ca Tue Jun 17 06:20:14 2008 From: francois at menards.ca (Francois Menard) Date: Tue, 17 Jun 2008 07:20:14 -0400 Subject: PPPoE over L2TP over GigE questions In-Reply-To: <86od67u5ix.fsf@seastrom.com> References: <484FF305.8010001@vaxination.ca> <86od67u5ix.fsf@seastrom.com> Message-ID: Actually, with AGAS, there are no tunnel switches anymore multiple tunnels are set-up directly netween Juniper ERXes aggregating DSLAMs and acting as LAC's and the ISPs LNS's receiving the L2TP tunnels. This is one giant step towards TR-101, but Bell won't accept to do this f. On 11-Jun-08, at 3:37 PM, Robert E. Seastrom wrote: > > Jean-Fran?ois Mezei writes: > >> Pardon my ignorance on the subject, but I would need to know how >> packets >> between a BAS/LAC and an ISP's router are transported (this is within >> Bell Canada ADSL territory). >> >> Bell uses L2TP to link each BAS/LAC to the ISP. Some of the ISPs >> get a >> Gigabit Ethernet link to the Bell cloud. > > Actually, they don't set up connections directly from the BASes and > SMSes anymore. I'm quite sure they've got some old Redback kit still > out there too, as well as perhaps some other ancient stuff. > > You're going to be talking to a tunnel switch (TSW2-TORONTO63 for > instance). These are all Juniper ERXes to the best of my knowledge. > > N number of BAS/SMS devices talk to a TSW, which talks to your LNS. > This cuts down drastically on the number of tunnels that you have to > manage (Bell has a couple of hundred BASes out there last I checked). > Brings the number of tunnels (and VLANs) down to a couple of hundred. > The tunnel switch is smart enough to look inside the authentication > packets at session start time and switch you properly based on the > realm the customer is logging into. > >> Would the L2TP payload be an ethernet packet which contains a PPPoE >> packet, or would the L2TP payload be the PPPoE packet only ? > > My recollection is that it includes the src/dst MAC addresses and the > rest of the ethernet header in the L2TP frame. > >> Also, while I am at it: >> >> Architecturally, is a BAS considered a router, or a bridge/switch ? >> (since the PPPoE packet has no routing information (source, >> destination), it is the BAS which maintains the table of >> source/destination for each PPPoE session ID. Yet, the BAS machines >> are >> supposedly Juniper ERX routers in Bell territory... > > I'd call them VPN endpoints for a layer 2 VPN; thus the functionality > they're providing is more like a bridge than a router, notwithstanding > their peeking into layer 5. > >> And while I am at it: >> >>> From the end user point of view, the ADSL modem sends all ATM >>> frames to >> a predetermined ATM destination (VPI/VCI). I assume that VPI/VCI >> points >> to the BAS. > > Yes, and at that point it's PPPoEoATM. Which gets turned into > PPPoEoATMoL2TP on the upstream side of the BAS. > >> How does the BAS address ATM packets back to an individual >> subscriber ? >> Do each subscribers get their own VPI/VCI that points to the right >> port >> on the right DSLAM ? > > Nothing that's visible on the upstream side of the BAS - it's all > src/dst mac address at that point. > >> And in cases where the telcos are extending the ethernet to the >> DSLAM, >> with the fragmentation into multiple ATM frames limited to the ADSL >> link >> itself, how does the BAS address invididual customers ? Does each >> ADSL >> port on the DSLAM get its own ethernet address ? > > the ADSL router has its own ethernet address. > >> (since some services do not use PPPoE, I have to assume that the >> DSLAM >> doesn't base its packet switching on PPPoE session IDs.) > > These other services are VLAN-per-customer and don't use PPPoE or L2TP > at all. I think we looked at these and decided not to use 'em. > > You may be thinking too deeply about this though. Contact me offline > if you want a working redacted config for Cisco kit talking to Bell > Canada. :-) > > -r > > > -- Fran?ois D. M?nard francois at menards.ca From rs at seastrom.com Tue Jun 17 07:17:12 2008 From: rs at seastrom.com (Robert E. Seastrom) Date: Tue, 17 Jun 2008 08:17:12 -0400 Subject: PPPoE over L2TP over GigE questions In-Reply-To: (Francois Menard's message of "Tue, 17 Jun 2008 07:20:14 -0400") References: <484FF305.8010001@vaxination.ca> <86od67u5ix.fsf@seastrom.com> Message-ID: <86d4mg1cjb.fsf@seastrom.com> That's some really good news... does it mean they're getting rid of the ATM network and the *&()&* Newbridges too? It's been a year and a half since I've even logged into the LNSes in question, and over two years since doing any meaningful reconfiguration... but it's good to hear my friends in Canada are getting improved service from Bell in some areas, even if they offset it by doing stupid stuff in other areas. :-/ -r Francois Menard writes: > Actually, with AGAS, there are no tunnel switches anymore > > multiple tunnels are set-up directly netween Juniper ERXes aggregating > DSLAMs and acting as LAC's and the ISPs LNS's receiving the L2TP > tunnels. > > This is one giant step towards TR-101, but Bell won't accept to do this > > f. > > On 11-Jun-08, at 3:37 PM, Robert E. Seastrom wrote: > >> >> Jean-Fran?ois Mezei writes: >> >>> Pardon my ignorance on the subject, but I would need to know how >>> packets >>> between a BAS/LAC and an ISP's router are transported (this is within >>> Bell Canada ADSL territory). >>> >>> Bell uses L2TP to link each BAS/LAC to the ISP. Some of the ISPs >>> get a >>> Gigabit Ethernet link to the Bell cloud. >> >> Actually, they don't set up connections directly from the BASes and >> SMSes anymore. I'm quite sure they've got some old Redback kit still >> out there too, as well as perhaps some other ancient stuff. >> >> You're going to be talking to a tunnel switch (TSW2-TORONTO63 for >> instance). These are all Juniper ERXes to the best of my knowledge. >> >> N number of BAS/SMS devices talk to a TSW, which talks to your LNS. >> This cuts down drastically on the number of tunnels that you have to >> manage (Bell has a couple of hundred BASes out there last I checked). >> Brings the number of tunnels (and VLANs) down to a couple of hundred. >> The tunnel switch is smart enough to look inside the authentication >> packets at session start time and switch you properly based on the >> realm the customer is logging into. >> >>> Would the L2TP payload be an ethernet packet which contains a PPPoE >>> packet, or would the L2TP payload be the PPPoE packet only ? >> >> My recollection is that it includes the src/dst MAC addresses and the >> rest of the ethernet header in the L2TP frame. >> >>> Also, while I am at it: >>> >>> Architecturally, is a BAS considered a router, or a bridge/switch ? >>> (since the PPPoE packet has no routing information (source, >>> destination), it is the BAS which maintains the table of >>> source/destination for each PPPoE session ID. Yet, the BAS machines >>> are >>> supposedly Juniper ERX routers in Bell territory... >> >> I'd call them VPN endpoints for a layer 2 VPN; thus the functionality >> they're providing is more like a bridge than a router, notwithstanding >> their peeking into layer 5. >> >>> And while I am at it: >>> >>>> From the end user point of view, the ADSL modem sends all ATM >>>> frames to >>> a predetermined ATM destination (VPI/VCI). I assume that VPI/VCI >>> points >>> to the BAS. >> >> Yes, and at that point it's PPPoEoATM. Which gets turned into >> PPPoEoATMoL2TP on the upstream side of the BAS. >> >>> How does the BAS address ATM packets back to an individual >>> subscriber ? >>> Do each subscribers get their own VPI/VCI that points to the right >>> port >>> on the right DSLAM ? >> >> Nothing that's visible on the upstream side of the BAS - it's all >> src/dst mac address at that point. >> >>> And in cases where the telcos are extending the ethernet to the >>> DSLAM, >>> with the fragmentation into multiple ATM frames limited to the ADSL >>> link >>> itself, how does the BAS address invididual customers ? Does each >>> ADSL >>> port on the DSLAM get its own ethernet address ? >> >> the ADSL router has its own ethernet address. >> >>> (since some services do not use PPPoE, I have to assume that the >>> DSLAM >>> doesn't base its packet switching on PPPoE session IDs.) >> >> These other services are VLAN-per-customer and don't use PPPoE or L2TP >> at all. I think we looked at these and decided not to use 'em. >> >> You may be thinking too deeply about this though. Contact me offline >> if you want a working redacted config for Cisco kit talking to Bell >> Canada. :-) >> >> -r >> >> >> > > -- > Fran?ois D. M?nard > francois at menards.ca From frnkblk at iname.com Tue Jun 17 07:39:29 2008 From: frnkblk at iname.com (Frank Bulk - iNAME) Date: Tue, 17 Jun 2008 07:39:29 -0500 Subject: SMTP no-such-user issues In-Reply-To: <48579C67.7000209@ibctech.ca> References: <485733E9.5030008@ibctech.ca> <48579C67.7000209@ibctech.ca> Message-ID: Please share a packet capture of a working and not working SMTP exchange. Frank -----Original Message----- From: Steve Bertrand [mailto:steve at ibctech.ca] Sent: Tuesday, June 17, 2008 6:14 AM To: nanog at nanog.org Subject: Re: SMTP no-such-user issues Steve Bertrand wrote: > Hi everyone, > > We are experiencing an issue in regards to SMTP MTA relay responses > regarding 'no such user', and it *apparently* appears to be only > occurring when a particular site attempts to deliver email to us. Any > advice on how to further troubleshoot my issue would be greatly > appreciated. Because I have been inundated with off-list replies, I'll post my findings here. First, a screen cap of me composing a message, in which two of the addresses are easily identified as valid, and two are clearly not: http://ibctech.ca/nanog_smtp/hotmail_compose.jpg ...when I sent it, I received thus: http://ibctech.ca/nanog_smtp/hotmail_response.txt So, we'll try it from a different server: http://ibctech.ca/nanog_smtp/local_compose.jpg ...hmmm, I received the message at steveb at eagle.ca (even though the To: field was cropped out of the jpg) this time, and my server generated the following....AFAICT, correct 551 error(s): http://ibctech.ca/nanog_smtp/local_err.txt I'm willing to provide any more documentation required in order to get this issue sorted. Thank you everyone, I truly appreciate it. Steve From steve at ibctech.ca Tue Jun 17 07:43:35 2008 From: steve at ibctech.ca (Steve Bertrand) Date: Tue, 17 Jun 2008 08:43:35 -0400 Subject: SMTP no-such-user issues In-Reply-To: References: <485733E9.5030008@ibctech.ca> <48579C67.7000209@ibctech.ca> Message-ID: <4857B177.10201@ibctech.ca> Frank Bulk - iNAME wrote: > Please share a packet capture of a working and not working SMTP exchange. In order to provide the highest amount of clarity, could you recommend a specific set of tcpdump command line args that I should use? Steve From frnkblk at iname.com Tue Jun 17 07:45:55 2008 From: frnkblk at iname.com (Frank Bulk - iNAME) Date: Tue, 17 Jun 2008 07:45:55 -0500 Subject: SMTP no-such-user issues In-Reply-To: <4857B177.10201@ibctech.ca> References: <485733E9.5030008@ibctech.ca> <48579C67.7000209@ibctech.ca> <4857B177.10201@ibctech.ca> Message-ID: Once you've performed a full capture on port 25, Wireshark does a nice job of providing an option to extract the relevant conversation by right-clicking on just one packet in that conversation and choosing something called "Follow the TCP stream", I believe. Frank -----Original Message----- From: Steve Bertrand [mailto:steve at ibctech.ca] Sent: Tuesday, June 17, 2008 7:44 AM To: frnkblk at iname.com Cc: nanog at nanog.org Subject: Re: SMTP no-such-user issues Frank Bulk - iNAME wrote: > Please share a packet capture of a working and not working SMTP exchange. In order to provide the highest amount of clarity, could you recommend a specific set of tcpdump command line args that I should use? Steve From steve at ibctech.ca Tue Jun 17 07:50:05 2008 From: steve at ibctech.ca (Steve Bertrand) Date: Tue, 17 Jun 2008 08:50:05 -0400 Subject: SMTP no-such-user issues In-Reply-To: References: <485733E9.5030008@ibctech.ca> <48579C67.7000209@ibctech.ca> <4857B177.10201@ibctech.ca> Message-ID: <4857B2FD.8080900@ibctech.ca> Frank Bulk - iNAME wrote: > Once you've performed a full capture on port 25, Wireshark does a nice job > of providing an option to extract the relevant conversation by > right-clicking on just one packet in that conversation and choosing > something called "Follow the TCP stream", I believe. Ok. I've never captured in tcpdump and then imported into Wireshark before, but I'll do some tests, scp the file to my Windows workstation, then follow the stream. Once I ensure I get a clean stream, I'll post the results. Steve From jra at baylink.com Tue Jun 17 07:52:49 2008 From: jra at baylink.com (Jay R. Ashworth) Date: Tue, 17 Jun 2008 08:52:49 -0400 Subject: Cable Colors In-Reply-To: <485745A4.3080406@ibctech.ca> References: <785694cd0806161532s4a205b3ey19d2aef1eb12285e@mail.gmail.com> <4856F0BC.5000607@aset.com> <4856FD4B.9010202@davidcoulson.net> <48573FB0.4020901@ibctech.ca> <48574122.405@davidcoulson.net> <485745A4.3080406@ibctech.ca> Message-ID: <20080617125249.GA424@cgi.jachomes.com> On Tue, Jun 17, 2008 at 01:03:32AM -0400, Steve Bertrand wrote: > I would like to know ANYONE who has a policy strict enough, and enforces > it so as to have even an almost perfect cabling infrastructure...is > there such a thing? ValPak, Largo FL. Their datacenter is new, $3.6M in a new completely automated $200M building, and it's *gorgeous*. Thanks to APC for organizing a (sales) tour about 3 months ago; I love facility porn. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com '87 e24 St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 Those who cast the vote decide nothing. Those who count the vote decide everything. -- (Joseph Stalin) From steve at ibctech.ca Tue Jun 17 07:56:47 2008 From: steve at ibctech.ca (Steve Bertrand) Date: Tue, 17 Jun 2008 08:56:47 -0400 Subject: Cable Colors In-Reply-To: <20080617125249.GA424@cgi.jachomes.com> References: <785694cd0806161532s4a205b3ey19d2aef1eb12285e@mail.gmail.com> <4856F0BC.5000607@aset.com> <4856FD4B.9010202@davidcoulson.net> <48573FB0.4020901@ibctech.ca> <48574122.405@davidcoulson.net> <485745A4.3080406@ibctech.ca> <20080617125249.GA424@cgi.jachomes.com> Message-ID: <4857B48F.7020604@ibctech.ca> Jay R. Ashworth wrote: > On Tue, Jun 17, 2008 at 01:03:32AM -0400, Steve Bertrand wrote: >> I would like to know ANYONE who has a policy strict enough, and enforces >> it so as to have even an almost perfect cabling infrastructure...is >> there such a thing? > > ValPak, Largo FL. > > Their datacenter is new, $3.6M in a new completely automated $200M > building, and it's *gorgeous*. Thanks to APC for organizing a (sales) > tour about 3 months ago; I love facility porn. LOL ;) ...facility porn... Steve From steve at ibctech.ca Tue Jun 17 08:20:12 2008 From: steve at ibctech.ca (Steve Bertrand) Date: Tue, 17 Jun 2008 09:20:12 -0400 Subject: SMTP no-such-user issues In-Reply-To: <4857B2FD.8080900@ibctech.ca> References: <485733E9.5030008@ibctech.ca> <48579C67.7000209@ibctech.ca> <4857B177.10201@ibctech.ca> <4857B2FD.8080900@ibctech.ca> Message-ID: <4857BA0C.70502@ibctech.ca> Steve Bertrand wrote: > Frank Bulk - iNAME wrote: >> Once you've performed a full capture on port 25, Wireshark does a nice >> job >> of providing an option to extract the relevant conversation by >> right-clicking on just one packet in that conversation and choosing >> something called "Follow the TCP stream", I believe. > > Ok. I've never captured in tcpdump and then imported into Wireshark > before, but I'll do some tests, scp the file to my Windows workstation, > then follow the stream. > > Once I ensure I get a clean stream, I'll post the results. As I research the documentation on the how-to specifics on capturing with tcpdump in a format that is Wireshark compatible, is there anyone here that could perform a simple test against their own domain email system, that can confirm or deny what I have been witnessing? If it can be confirmed that either A) my end is broken, or B) a remote end is broken, I will be content, and can continue with other work. My mind will rest at ease if someone, with known bounce-no-mbox enabled, can: - provide me off list (or test for themselves from a remote location) a list of valid, and invalid recipients within their own domain's email infrastructure. It doesn't even matter if you specify which are valid and which ones are not - create a temporary account on Hotmail (or from a sympatico.ca email address, using whatever outbound servers they specify) send a message to the same recipients as requested above. - in the case that you don't want to provide the addresses, and want to test internally, inform me of the overall result - in the case that I receive the addresses to test from my location, provide me with the results of the Hotmail test so I can compare results If this is happening to other ops along with myself, I can justify it to my users, and I can justify it in my own mind. If this is a locale specific issue to my own network, then I need to know that, as I obviously have work to do. Thanks to everyone again. Steve From nanog at daork.net Tue Jun 17 08:21:40 2008 From: nanog at daork.net (Nathan Ward) Date: Wed, 18 Jun 2008 01:21:40 +1200 Subject: SMTP no-such-user issues In-Reply-To: <4857BA0C.70502@ibctech.ca> References: <485733E9.5030008@ibctech.ca> <48579C67.7000209@ibctech.ca> <4857B177.10201@ibctech.ca> <4857B2FD.8080900@ibctech.ca> <4857BA0C.70502@ibctech.ca> Message-ID: <36207D59-67E2-4C36-934D-19C385066715@daork.net> On 18/06/2008, at 1:20 AM, Steve Bertrand wrote: > Steve Bertrand wrote: >> Frank Bulk - iNAME wrote: >>> Once you've performed a full capture on port 25, Wireshark does a >>> nice job >>> of providing an option to extract the relevant conversation by >>> right-clicking on just one packet in that conversation and choosing >>> something called "Follow the TCP stream", I believe. >> Ok. I've never captured in tcpdump and then imported into Wireshark >> before, but I'll do some tests, scp the file to my Windows >> workstation, then follow the stream. >> Once I ensure I get a clean stream, I'll post the results. > > As I research the documentation on the how-to specifics on capturing > with tcpdump in a format that is Wireshark compatible, is there > anyone here that could perform a simple test against their own > domain email system, that can confirm or deny what I have been > witnessing? Wireshark reads pcap files. Spit them out with this option on the tcpdump commandline. -w file -- Nathan Ward From joesox at gmail.com Tue Jun 17 08:26:40 2008 From: joesox at gmail.com (JoeSox) Date: Tue, 17 Jun 2008 06:26:40 -0700 Subject: Cable Colors - A Standard In-Reply-To: References: <200806170326.m5H3QfwE071681@aurora.sol.net> <20080617035800.GC30714@cgi.jachomes.com> Message-ID: <785694cd0806170626g900fdai8fad76809d5d1081@mail.gmail.com> On Mon, Jun 16, 2008 at 9:07 PM, George Imburgia wrote: > > There's a standard; > > ANSI/TIA/EIA 606A > > http://www.flexcomm.com/library/606aguide.pdf > > Page 23 Informative and what I was looking for.. -- Thank You, Joe From thegameiam at yahoo.com Tue Jun 17 08:30:31 2008 From: thegameiam at yahoo.com (David Barak) Date: Tue, 17 Jun 2008 06:30:31 -0700 (PDT) Subject: Cable Colors Message-ID: <695728.74208.qm@web31801.mail.mud.yahoo.com> ----- Original Message ---- >From: Steve Bertrand steve at ibctech.ca >Jay R. Ashworth wrote: >> Their datacenter is new, $3.6M in a new completely automated $200M >> building, and it's *gorgeous*.? Thanks to APC for organizing a (sales) >> tour about 3 months ago; I love facility porn. >...facility porn... But is the facility porn available over IPv6? David Barak Need Geek Rock? Try The Franchise: http://www.listentothefranchise.com From jra at baylink.com Tue Jun 17 08:41:21 2008 From: jra at baylink.com (Jay R. Ashworth) Date: Tue, 17 Jun 2008 09:41:21 -0400 Subject: Cable Colors In-Reply-To: <695728.74208.qm@web31801.mail.mud.yahoo.com> References: <695728.74208.qm@web31801.mail.mud.yahoo.com> Message-ID: <20080617134121.GA639@cgi.jachomes.com> On Tue, Jun 17, 2008 at 06:30:31AM -0700, David Barak wrote: > >From: Steve Bertrand steve at ibctech.ca > > >Jay R. Ashworth wrote: > >> Their datacenter is new, $3.6M in a new completely automated $200M > >> building, and it's *gorgeous*.? Thanks to APC for organizing a (sales) > >> tour about 3 months ago; I love facility porn. > > >...facility porn... > > But is the facility porn available over IPv6? Alas, no; I asked permission to take pictures; had my Oly e10 with me and everything... they preferred not, which I can understand. AFCOM or APC might have something posted somewhere though that's already been vetted. A quick googling doesn't turn up anything, though. Cheers, - jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com '87 e24 St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 Those who cast the vote decide nothing. Those who count the vote decide everything. -- (Joseph Stalin) From marc at let.de Tue Jun 17 09:16:17 2008 From: marc at let.de (Marc Manthey) Date: Tue, 17 Jun 2008 16:16:17 +0200 Subject: Cable Colors In-Reply-To: <695728.74208.qm@web31801.mail.mud.yahoo.com> References: <695728.74208.qm@web31801.mail.mud.yahoo.com> Message-ID: Am 17.06.2008 um 15:30 schrieb David Barak: > ----- Original Message ---- >> From: Steve Bertrand steve at ibctech.ca > >> Jay R. Ashworth wrote: >>> Their datacenter is new, $3.6M in a new completely automated $200M >>> building, and it's *gorgeous*. Thanks to APC for organizing a >>> (sales) >>> tour about 3 months ago; I love facility porn. > >> ...facility porn... > > But is the facility porn available over IPv6? http://www.ipv6experiment.com/ From bpfankuch at cpgreeley.com Tue Jun 17 09:18:06 2008 From: bpfankuch at cpgreeley.com (Blake Pfankuch) Date: Tue, 17 Jun 2008 08:18:06 -0600 Subject: Cable Colors In-Reply-To: <48572023.1010205@eeph.com> References: <785694cd0806161532s4a205b3ey19d2aef1eb12285e@mail.gmail.com> <485700C6.2020302@whack.org> <48572023.1010205@eeph.com> Message-ID: <01759D50DC387C45A018FE1817CE27D74F0229EE11@CPExchange1.cpgreeley.com> Course it can still get a little rough. In our noc we have a well working standard. Blue == IPKVM Black == Internal Data VLAN Red == WAN VLAN Green == Client managed device Yellow == Client device (we manage) White == to Desktop (or phone) Pink == iSCSI Orange == SAN fiber Sadly we don't have any white and red (as someone else pointed out. Poor new tech with no fingers) -----Original Message----- From: Matthew Kaufman [mailto:matthew at eeph.com] Sent: Monday, June 16, 2008 8:24 PM To: Peter Wohlers Cc: nanog at nanog.org Subject: Re: Cable Colors Peter Wohlers wrote: > As you can see, by and large, people assign colors to functions. What > color to what function varies like the wind. Unlike a previous employer > whose colo-manager person insisted on using colors to represent cable > lengths (Doh!), color -> function mapping seems pretty universal. I used to do that too... Until I stood behind a rack trying to figure out which of the 70 or so gray wires from the switch was the one going to the box I was having the problem with. Then I bought as many different colors as I could find, and mixed things up a bit. Matthew Kaufman From joe.johnson at inwk.com Tue Jun 17 10:11:32 2008 From: joe.johnson at inwk.com (Johnson, Joe) Date: Tue, 17 Jun 2008 10:11:32 -0500 Subject: AOL Instant Messenger Message-ID: <730AEB5ADF0DA54EA9317BF5E9A5224AD90180@iwex1.IWPrint.net> Is anyone else seeing issues with AOL Instant Messenger? Personally, my PC logged out for 10-15 minutes this morning and came right back, but my home PC and the desktops of many employees have intermittent issues (some have been unable to connect since 9:15 am CDT). Their site is less than helpful, but the user forums at aim.com show others having minor to major issues connecting. Thanks! Joe Johnson Senior Systems Engineer InnerWorkings, Inc. Managed Print & Promotional Solutions 600 West Chicago Avenue, Suite 850 Chicago, IL 60610 Phone: 312.676.6873 Fax: 312.604.5487 joe.johnson at inwk.com www.inwk.com NASDAQ: INWK From jason.iannone at gmail.com Tue Jun 17 10:14:33 2008 From: jason.iannone at gmail.com (Jason Iannone) Date: Tue, 17 Jun 2008 09:14:33 -0600 Subject: AOL Instant Messenger In-Reply-To: <730AEB5ADF0DA54EA9317BF5E9A5224AD90180@iwex1.IWPrint.net> References: <730AEB5ADF0DA54EA9317BF5E9A5224AD90180@iwex1.IWPrint.net> Message-ID: there's a big ole' thread on the outages list. On Tue, Jun 17, 2008 at 9:11 AM, Johnson, Joe wrote: > Is anyone else seeing issues with AOL Instant Messenger? Personally, my > PC logged out for 10-15 minutes this morning and came right back, but my > home PC and the desktops of many employees have intermittent issues > (some have been unable to connect since 9:15 am CDT). Their site is less > than helpful, but the user forums at aim.com show others having minor to > major issues connecting. > > Thanks! > > > > Joe Johnson > Senior Systems Engineer > InnerWorkings, Inc. > Managed Print & Promotional Solutions > 600 West Chicago Avenue, Suite 850 > Chicago, IL 60610 > Phone: 312.676.6873 > Fax: 312.604.5487 > joe.johnson at inwk.com > www.inwk.com > NASDAQ: INWK > > > From jgoltz at mail.nih.gov Tue Jun 17 10:16:19 2008 From: jgoltz at mail.nih.gov (Goltz, Jim (NIH/CIT) [E]) Date: Tue, 17 Jun 2008 11:16:19 -0400 Subject: AOL Instant Messenger In-Reply-To: <730AEB5ADF0DA54EA9317BF5E9A5224AD90180@iwex1.IWPrint.net> References: <730AEB5ADF0DA54EA9317BF5E9A5224AD90180@iwex1.IWPrint.net> Message-ID: > Is anyone else seeing issues with AOL Instant Messenger? Based on the messages on the "outages" list, it's not just you. No details yet as to what's happening. Some of us here seem to have been bumped off, some haven't. -- Jim Goltz National Institutes of Health CIT/DCSS/HSB/ASIG 12/2216 From mdonahue at watg.com Tue Jun 17 10:19:28 2008 From: mdonahue at watg.com (Mike Donahue) Date: Tue, 17 Jun 2008 08:19:28 -0700 Subject: Cable Colors In-Reply-To: <785694cd0806161532s4a205b3ey19d2aef1eb12285e@mail.gmail.com> References: <785694cd0806161532s4a205b3ey19d2aef1eb12285e@mail.gmail.com> Message-ID: <49900C758A716C499CE8C56BF0CB527109D68A47@newexch01.ohana.watg.com> >-----Original Message----- >From: JoeSox [mailto:joesox at gmail.com] >Sent: Monday, June 16, 2008 3:32 PM >To: nanog at nanog.org >Subject: Cable Colors >Hello Newbie here (hopefully I have the correct list), >I was just wondering if anyone knows of a website with recommended >colors for cables for a new datacenter? >I have written some things down but I don't want to get stuck saying >'darn, I wish I would have bought this color for this type, now I am >stuck'. >What standard color to use if voice and data on same interface etc. Thanks. >-- >Thank You, Joe We use this cable for our UDP applications: http://www.amazon.com/Denon-AKDL1-Dedicated-Link-Cable/dp/B000I1X6PM . The fluoropolymer coating makes sure we don't drop any packets onto the floor. At least that's what the salesman told me. And we don't need to color-code them, they just kind of glow from their own awesomeness. Mike Donahue WATG From joe.johnson at inwk.com Tue Jun 17 10:19:44 2008 From: joe.johnson at inwk.com (Johnson, Joe) Date: Tue, 17 Jun 2008 10:19:44 -0500 Subject: AOL Instant Messenger In-Reply-To: <730AEB5ADF0DA54EA9317BF5E9A5224AD90180@iwex1.IWPrint.net> References: <730AEB5ADF0DA54EA9317BF5E9A5224AD90180@iwex1.IWPrint.net> Message-ID: <730AEB5ADF0DA54EA9317BF5E9A5224AD9018F@iwex1.IWPrint.net> Since outages is covering it, no need to spam everyone twice. We're all back online here and in remote offices, so it looks to be resolving itself. Thanks to everyone who replied on- and off-list! Joe Johnson Senior Systems Engineer InnerWorkings, Inc. Managed Print & Promotional Solutions 600 West Chicago Avenue, Suite 850 Chicago, IL 60610 Phone: 312.676.6873 Fax: 312.604.5487 joe.johnson at inwk.com www.inwk.com NASDAQ: INWK NOTE NEW E-MAIL AND WEBSITE ADDRESSES! -----Original Message----- From: Johnson, Joe [mailto:joe.johnson at inwk.com] Sent: Tuesday, June 17, 2008 10:12 AM To: nanog at nanog.org Subject: AOL Instant Messenger Is anyone else seeing issues with AOL Instant Messenger? Personally, my PC logged out for 10-15 minutes this morning and came right back, but my home PC and the desktops of many employees have intermittent issues (some have been unable to connect since 9:15 am CDT). Their site is less than helpful, but the user forums at aim.com show others having minor to major issues connecting. Thanks! Joe Johnson Senior Systems Engineer InnerWorkings, Inc. Managed Print & Promotional Solutions 600 West Chicago Avenue, Suite 850 Chicago, IL 60610 Phone: 312.676.6873 Fax: 312.604.5487 joe.johnson at inwk.com www.inwk.com NASDAQ: INWK From steve at ibctech.ca Tue Jun 17 10:50:03 2008 From: steve at ibctech.ca (Steve Bertrand) Date: Tue, 17 Jun 2008 11:50:03 -0400 Subject: SMTP no-such-user issues In-Reply-To: <36207D59-67E2-4C36-934D-19C385066715@daork.net> References: <485733E9.5030008@ibctech.ca> <48579C67.7000209@ibctech.ca> <4857B177.10201@ibctech.ca> <4857B2FD.8080900@ibctech.ca> <4857BA0C.70502@ibctech.ca> <36207D59-67E2-4C36-934D-19C385066715@daork.net> Message-ID: <4857DD2B.4020401@ibctech.ca> Nathan Ward wrote: > > On 18/06/2008, at 1:20 AM, Steve Bertrand wrote: > >> Steve Bertrand wrote: >>> Frank Bulk - iNAME wrote: >>>> Once you've performed a full capture on port 25, Wireshark does a >>>> nice job >>>> of providing an option to extract the relevant conversation by >>>> right-clicking on just one packet in that conversation and choosing >>>> something called "Follow the TCP stream", I believe. >>> Ok. I've never captured in tcpdump and then imported into Wireshark >>> before, but I'll do some tests, scp the file to my Windows >>> workstation, then follow the stream. >>> Once I ensure I get a clean stream, I'll post the results. >> >> As I research the documentation on the how-to specifics on capturing >> with tcpdump in a format that is Wireshark compatible, is there anyone >> here that could perform a simple test against their own domain email >> system, that can confirm or deny what I have been witnessing? > > > Wireshark reads pcap files. Spit them out with this option on the > tcpdump commandline. I'm capturing this now. In the meantime, I had assistance off-list from someone within an external domain, and we confirmed that the problem is NOT solely Hotmail, yet it is not solely my end (at least I'm not completely convinced). I feel quite a bit more relaxed now, although the problem is not resolved. Hotmail encompassed domains are the only site that we have noticed this problem with, however, now I'm certain that there could be more. Most are confirmed to work properly, most notably GMail. It is also not solely related to the Barracuda. Another SMTP server is experiencing the same issue within the same network, which is not located behind the 'cuda cluster. The only common ground is that both environments operate under Qmail. The 'cuda setup with no filtering, and the non-cuda setup with SA, ClamAV being called by Simscan. We're back to square one, but now I know to point squarely at my configuration to find out why this is happening. My sincerest regards for all of the on and off-list help that I have received in regards to this issue. I have learned a tremendous amount along the way. Thank you to everyone who has provided the patience and willingness to help, and those that are continuing to do so. If it does turn out to be an implementation issue with any of the software chain we have operating here, we will attempt with our best efforts to document it, and provide patches to the original source. Steve From charles at thewybles.com Tue Jun 17 10:53:59 2008 From: charles at thewybles.com (Charles N Wyble) Date: Tue, 17 Jun 2008 08:53:59 -0700 Subject: PPPoE over L2TP over GigE questions In-Reply-To: References: <484FF305.8010001@vaxination.ca> <86od67u5ix.fsf@seastrom.com> Message-ID: <4857DE17.6050505@thewybles.com> This has been a very informative thread. All sorts of acronyms to research and so forth. :) The mention of TR-101 took me down another rabbit hole, and I discovered http://www.dslforum.org/trlist/trlist.php. Very interesting info. Charles -- Charles N Wyble (818) 280-7059 http://charlesnw.blogspot.com From steve at ibctech.ca Tue Jun 17 11:14:21 2008 From: steve at ibctech.ca (Steve Bertrand) Date: Tue, 17 Jun 2008 12:14:21 -0400 Subject: SMTP no-such-user issues In-Reply-To: <1693D46C-60CA-464D-A96C-F5FDBEC42D91@short.id.au> References: <485733E9.5030008@ibctech.ca> <48579C67.7000209@ibctech.ca> <4857B177.10201@ibctech.ca> <4857B2FD.8080900@ibctech.ca> <4857BA0C.70502@ibctech.ca> <36207D59-67E2-4C36-934D-19C385066715@daork.net> <4857DD2B.4020401@ibctech.ca> <1693D46C-60CA-464D-A96C-F5FDBEC42D91@short.id.au> Message-ID: <4857E2DD.70600@ibctech.ca> Shane Short wrote: > are you using vpopmail with your qmail install? (I can't seem to load > your errors again, I recall they were chkuser failures) Yes, vpopmail against MySQL. > I've had this problem before when I've run out of MySQL connections and > vchkuser was then failing. Thanks for the feedback, but this is not the case. The problem has been identified to be extraordinarily site specific. I'm attempting to follow the recommendations of members that mailed me off list one at a time, and am proceeding with testing. It would be of great value if other mail admins who are running Qmail that have a few minutes could contact me off list in order to compare some quick test results/config setups. Steve From cmadams at hiwaay.net Tue Jun 17 11:24:30 2008 From: cmadams at hiwaay.net (Chris Adams) Date: Tue, 17 Jun 2008 11:24:30 -0500 Subject: Outages list info Message-ID: <20080617162430.GG1074252@hiwaay.net> The outages list is at isotf.org, right? I had not yet gotten around to signing up and a couple of messages here prompted me to take a look. Assuming the links I see for isotf.org are correct, someone might want to notify the list about an outage: $ dig +trace isotf.org mx ; <<>> DiG 9.2.8 <<>> +trace isotf.org mx ;; global options: printcmd . 424771 IN NS M.ROOT-SERVERS.NET. . 424771 IN NS A.ROOT-SERVERS.NET. . 424771 IN NS B.ROOT-SERVERS.NET. . 424771 IN NS C.ROOT-SERVERS.NET. . 424771 IN NS D.ROOT-SERVERS.NET. . 424771 IN NS E.ROOT-SERVERS.NET. . 424771 IN NS F.ROOT-SERVERS.NET. . 424771 IN NS G.ROOT-SERVERS.NET. . 424771 IN NS H.ROOT-SERVERS.NET. . 424771 IN NS I.ROOT-SERVERS.NET. . 424771 IN NS J.ROOT-SERVERS.NET. . 424771 IN NS K.ROOT-SERVERS.NET. . 424771 IN NS L.ROOT-SERVERS.NET. ;; Received 304 bytes from 216.180.54.2#53(216.180.54.2) in 2 ms org. 172800 IN NS TLD2.ULTRADNS.NET. org. 172800 IN NS TLD1.ULTRADNS.NET. org. 172800 IN NS B0.ORG.AFILIAS-NST.org. org. 172800 IN NS A0.ORG.AFILIAS-NST.INFO. org. 172800 IN NS C0.ORG.AFILIAS-NST.INFO. org. 172800 IN NS D0.ORG.AFILIAS-NST.org. ;; Received 417 bytes from 202.12.27.33#53(M.ROOT-SERVERS.NET) in 206 ms isotf.org. 86400 IN NS ns2.amigostecnicos.net. isotf.org. 86400 IN NS ns.amigostecnicos.net. ;; Received 80 bytes from 204.74.113.1#53(TLD2.ULTRADNS.NET) in 32 ms ;; connection timed out; no servers could be reached $ host ns.amigostecnicos.net. ns.amigostecnicos.net has address 209.151.108.152 $ host ns2.amigostecnicos.net. ns2.amigostecnicos.net has address 209.151.108.152 $ Somebody might want to read up on nameserver diversity. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From steve at ibctech.ca Tue Jun 17 11:38:22 2008 From: steve at ibctech.ca (Steve Bertrand) Date: Tue, 17 Jun 2008 12:38:22 -0400 Subject: SMTP no-such-user issues In-Reply-To: <4857E2DD.70600@ibctech.ca> References: <485733E9.5030008@ibctech.ca> <48579C67.7000209@ibctech.ca> <4857B177.10201@ibctech.ca> <4857B2FD.8080900@ibctech.ca> <4857BA0C.70502@ibctech.ca> <36207D59-67E2-4C36-934D-19C385066715@daork.net> <4857DD2B.4020401@ibctech.ca> <1693D46C-60CA-464D-A96C-F5FDBEC42D91@short.id.au> <4857E2DD.70600@ibctech.ca> Message-ID: <4857E87E.80501@ibctech.ca> Steve Bertrand wrote: > Shane Short wrote: >> are you using vpopmail with your qmail install? (I can't seem to load >> your errors again, I recall they were chkuser failures) > > Yes, vpopmail against MySQL. > >> I've had this problem before when I've run out of MySQL connections >> and vchkuser was then failing. > > Thanks for the feedback, but this is not the case. > > The problem has been identified to be extraordinarily site specific. I'm > attempting to follow the recommendations of members that mailed me off > list one at a time, and am proceeding with testing. > > It would be of great value if other mail admins who are running Qmail > that have a few minutes could contact me off list in order to compare > some quick test results/config setups. Well, in order to draw a conclusion (not yet tested), someone mentioned off-list to look at the extended function PIPELINING. After reviewing this possibility, it directly fits the bill in regards to the issues I have been experiencing. I will disable it just as a pure test, however, after scouring the web to weigh the benefits to drawbacks, I've found a pretty general consensus that disabling pipelining because of a single poorly-implemented client will effectively erase any performance enhancement that well-behaved clients can achieve with it. If this does turn out to be the problem, then the users, whom are out of my control, of the single site who are witnessing this problem that appears to originate from my end can deal with sorting through the apparently 'faulty' list of addresses they receive in the bounce. Does this theory sound reasonable, and is keeping pipelining in place a recommended option? Steve From streiner at cluebyfour.org Tue Jun 17 10:25:09 2008 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Tue, 17 Jun 2008 11:25:09 -0400 (EDT) Subject: Cable Colors In-Reply-To: <20080617125249.GA424@cgi.jachomes.com> References: <785694cd0806161532s4a205b3ey19d2aef1eb12285e@mail.gmail.com> <4856F0BC.5000607@aset.com> <4856FD4B.9010202@davidcoulson.net> <48573FB0.4020901@ibctech.ca> <48574122.405@davidcoulson.net> <485745A4.3080406@ibctech.ca> <20080617125249.GA424@cgi.jachomes.com> Message-ID: On Tue, 17 Jun 2008, Jay R. Ashworth wrote: > On Tue, Jun 17, 2008 at 01:03:32AM -0400, Steve Bertrand wrote: >> I would like to know ANYONE who has a policy strict enough, and enforces >> it so as to have even an almost perfect cabling infrastructure...is >> there such a thing? > > ValPak, Largo FL. > > Their datacenter is new, $3.6M in a new completely automated $200M > building, and it's *gorgeous*. Thanks to APC for organizing a (sales) > tour about 3 months ago; I love facility porn. I was in a data center for a large bank here in Pittsburgh a few years ago, and they definitely went the extra mile to keep their cable plant neatly organized and properly dressed, and they continued to maintain that after the building was turned up. That's the real test. I've seen lots of data centers and colo facilities that looked great for the grand opening and started turning into rat's nests as the move/add/change tickets started coming in :( jms From jabley at ca.afilias.info Tue Jun 17 12:28:38 2008 From: jabley at ca.afilias.info (Joe Abley) Date: Tue, 17 Jun 2008 13:28:38 -0400 Subject: Cable Colors In-Reply-To: References: <785694cd0806161532s4a205b3ey19d2aef1eb12285e@mail.gmail.com> <4856F0BC.5000607@aset.com> <4856FD4B.9010202@davidcoulson.net> <48573FB0.4020901@ibctech.ca> <48574122.405@davidcoulson.net> <485745A4.3080406@ibctech.ca> <20080617125249.GA424@cgi.jachomes.com> Message-ID: On 17 Jun 2008, at 11:25, Justin M. Streiner wrote: > I was in a data center for a large bank here in Pittsburgh a few > years ago, and they definitely went the extra mile to keep their > cable plant neatly organized and properly dressed, and they > continued to maintain that after the building was turned up. A boutique hosting company of my acquaintance once decided that cable management within racks was rather important -- they had the rather pragmatic opinion that setting things up right to start with was not enough, and that they also needed a conscious plan to keep things tidy as the cabinets filled up that did not rely on techs following rules or being diligent. The initial cable install for the pre-provisioned servers was done with much planning and documentation by people who did data cabling for a living, and was correspondingly tidy. The cables were all blue. Any change that was required after that was installed using a red cable. Once per week the data cabling people would return, within a posted window, and replace the temporary red patch cables with cut-to-length, tested, blue cables which were run according to the larger cabling strategy, and rigourously documented. This approach had the advantage that the cabinets always looked pristine and the documentation was always current (modulo a few red cables), regardless of what changes had happened since the original install, and regardless of who had made those changes. The theory was that bringing in dedicated cabling contractors to do audits once per week was cheaper in the grand scheme of things than dealing with the implications of messy cabling. There was an additional advantage that any potential customer who was shown the suite was overwhelmed with the pristine neatness of it, and felt immediately comfortable with the idea of emptying their own appallingly messy and undocumented machine room into such a place. Joe From sdalberg at marchex.com Tue Jun 17 12:31:21 2008 From: sdalberg at marchex.com (Steve Dalberg) Date: Tue, 17 Jun 2008 10:31:21 -0700 Subject: Cable Colors In-Reply-To: References: <785694cd0806161532s4a205b3ey19d2aef1eb12285e@mail.gmail.com><4856F0BC.5000607@aset.com> <4856FD4B.9010202@davidcoulson.net><48573FB0.4020901@ibctech.ca> <48574122.405@davidcoulson.net><485745A4.3080406@ibctech.ca> <20080617125249.GA424@cgi.jachomes.com> Message-ID: <9B4191CF8F73B04BB4F437E1F7F86ED50D775716@exchbe1sea.windows.marchex.com> > On Tue, 17 Jun 2008, Jay R. Ashworth wrote: > > > On Tue, Jun 17, 2008 at 01:03:32AM -0400, Steve Bertrand wrote: > >> I would like to know ANYONE who has a policy strict enough, and > >> enforces it so as to have even an almost perfect cabling > >> infrastructure...is there such a thing? > > > > ValPak, Largo FL. > > > > Their datacenter is new, $3.6M in a new completely automated $200M > > building, and it's *gorgeous*. Thanks to APC for > organizing a (sales) > > tour about 3 months ago; I love facility porn. > > I was in a data center for a large bank here in Pittsburgh a > few years ago, and they definitely went the extra mile to > keep their cable plant neatly organized and properly dressed, > and they continued to maintain that after the building was turned up. > > That's the real test. I've seen lots of data centers and > colo facilities that looked great for the grand opening and > started turning into rat's nests as the move/add/change > tickets started coming in :( > > jms > > I opened a ~100k square ft DC in 2001, and it is still immaculate (i'm not with the company any longer btw), for one very simple reason... Its someones job. All the guy does is run cables, if anyone brings in their own cable, it gets immediately unplugged and cut in half (not kidding, its happened). All cables are labelled at each end, with hostname/patch panel/switch-m-p info, so at any point you can reference the run. When you make it someones job, they can take pride in it. If you have a guy who has 10 other things to do, being tidy will end up low on the list... The mucky mucks toured the Data Center and were very impressed, then they asked the facility manager how long they spent cleaning up. The answer was simple, "It always looks like this." My advice to anyone with a large facility. Hire someone who does good work, pay them well, and give them your confidence to do the right thing. Don't depend on NE's, or SA's to keep it tidy, because honestly, there will come a time when they have bigger fish to fry. Steve From morrowc.lists at gmail.com Tue Jun 17 12:38:58 2008 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 17 Jun 2008 13:38:58 -0400 Subject: Outages list info In-Reply-To: <20080617162430.GG1074252@hiwaay.net> References: <20080617162430.GG1074252@hiwaay.net> Message-ID: <75cb24520806171038g1abf5e6al2a514f9c03a2fbba@mail.gmail.com> On Tue, Jun 17, 2008 at 12:24 PM, Chris Adams wrote: > The outages list is at isotf.org, right? I had not yet gotten around to > signing up and a couple of messages here prompted me to take a look. > > Assuming the links I see for isotf.org are correct, someone might want > to notify the list about an outage: > ;; connection timed out; no servers could be reached > $ host ns.amigostecnicos.net. > ns.amigostecnicos.net has address 209.151.108.152 > $ host ns2.amigostecnicos.net. > ns2.amigostecnicos.net has address 209.151.108.152 > $ amigostecnicos.net has 4 NS hosts, on 2 ip addresses on one /28, behind one ASN (4963) with 2 upstreams (L3 + cogent) if this is important someone certainly can offer secondary NS outside that /28? I'd be happy to help if one of the owners wants to find me off-list... -chris From morrowc.lists at gmail.com Tue Jun 17 13:00:42 2008 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 17 Jun 2008 14:00:42 -0400 Subject: P2P agents for software distribution - saving the WAN from meltdown?!? In-Reply-To: <200806160853.20416.netfortius@gmail.com> References: <200806160853.20416.netfortius@gmail.com> Message-ID: <75cb24520806171100s28de94f8h80cff4a3b4982257@mail.gmail.com> On Mon, Jun 16, 2008 at 9:53 AM, Netfortius wrote: > Has anybody used (and been successful at) a bit-torrent-like agent for fast > distribution of LEGAL software (install programs of large-DVD size), across > multiple sites, all over the globe, with bad WAN connectivity? I have read a > couple of references online (e.g. > http://torrentfreak.com/university-uses-utorrent-080306/) about such, but I > am a little reluctant to do it in a corporate environment, especially in the > light of potential misuse of such ... unless finding a way to install, use > and remove the P2P agent, all in one shot ... catch 22, sort of (distributing > the P2P agent, that is :)) ... revision3.com ubuntu.com fedoraproject.org . . . most of the larger free-nix's do BT downloads on release day(s). Revision3 distributes their content via BT. There were rumors of Disney and Apple moving to BT models for their content distribution at one point as well. If the tracker isn't accessible from untrusted networks, what's the concern you have? -Chris From brandon.galbraith at gmail.com Tue Jun 17 13:14:16 2008 From: brandon.galbraith at gmail.com (Brandon Galbraith) Date: Tue, 17 Jun 2008 13:14:16 -0500 Subject: P2P agents for software distribution - saving the WAN from meltdown?!? In-Reply-To: <75cb24520806171100s28de94f8h80cff4a3b4982257@mail.gmail.com> References: <200806160853.20416.netfortius@gmail.com> <75cb24520806171100s28de94f8h80cff4a3b4982257@mail.gmail.com> Message-ID: <366100670806171114k24c99df8ha348c882dd9b5f65@mail.gmail.com> On 6/17/08, Christopher Morrow wrote: > > On Mon, Jun 16, 2008 at 9:53 AM, Netfortius wrote: > > Has anybody used (and been successful at) a bit-torrent-like agent for > fast > > distribution of LEGAL software (install programs of large-DVD size), > across > > multiple sites, all over the globe, with bad WAN connectivity? most of the larger free-nix's do BT downloads on release day(s). > Revision3 distributes their content via BT. There were rumors of > Disney and Apple moving to BT models for their content distribution at > one point as well. > I believe World of Warcraft uses Bittorrent to push out updates as well (Steam may, haven't checked, would make sense though). Something we've been working with for a client is using Amazon's S3 service to host the tracker, as S3 will natively handle serving it (both the content and the tracker, you simply need to append ?torrent to the S3 request). HTH, -brandon From joelja at bogus.com Tue Jun 17 13:19:19 2008 From: joelja at bogus.com (Joel Jaeggli) Date: Tue, 17 Jun 2008 11:19:19 -0700 Subject: P2P agents for software distribution - saving the WAN from meltdown?!? In-Reply-To: <200806160853.20416.netfortius@gmail.com> References: <200806160853.20416.netfortius@gmail.com> Message-ID: <48580027.1040405@bogus.com> Netfortius wrote: > Has anybody used (and been successful at) a bit-torrent-like agent for fast > distribution of LEGAL software (install programs of large-DVD size), across > multiple sites, all over the globe, with bad WAN connectivity? I have read a > couple of references online (e.g. > http://torrentfreak.com/university-uses-utorrent-080306/) about such, but I > am a little reluctant to do it in a corporate environment, especially in the > light of potential misuse of such ... unless finding a way to install, use > and remove the P2P agent, all in one shot ... catch 22, sort of (distributing > the P2P agent, that is :)) ... well if the connectivity universally sucks no amount of p2p is going to help... We have some experience with large file distribution in this fashion because of the fedora core DVD iso's and we can say generally at this point that the mirror infrastructure serves more iso's on release day than the torrents do... that said the p2p client does rule out needing to select a mirror that has free slots during a flash crowd. > Stefan > > P.S. If inappropriate for this mailing list, I apologize - but the "long fat > pipe" thread gave me the idea to ask here, vs. sysadmin-like lists, as the > potential for network impact is my primary concern. > From rfg at tristatelogic.com Tue Jun 17 12:30:47 2008 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Tue, 17 Jun 2008 10:30:47 -0700 Subject: Spam Book Author Implicated in Second IP Block Controversy Message-ID: <12317.1213723847@tristatelogic.com> ARIN, NASA, and the United States Air Force would probably prefer it if people didn't read this: http://www.47-usc-230c2.org/chapter3.html From smb at cs.columbia.edu Tue Jun 17 13:43:59 2008 From: smb at cs.columbia.edu (Steven M. Bellovin) Date: Tue, 17 Jun 2008 14:43:59 -0400 Subject: P2P agents for software distribution - saving the WAN from meltdown?!? In-Reply-To: <48580027.1040405@bogus.com> References: <200806160853.20416.netfortius@gmail.com> <48580027.1040405@bogus.com> Message-ID: <20080617144359.1fcd6732@cs.columbia.edu> On Tue, 17 Jun 2008 11:19:19 -0700 Joel Jaeggli wrote: > that said the p2p client does rule out needing to select a mirror > that has free slots during a flash crowd. As Mozilla is learning today: http://www.techspot.com/news/30486-mozilla-sites-die-shortly-after-download-day-begins.html --Steve Bellovin, http://www.cs.columbia.edu/~smb From brandon.galbraith at gmail.com Tue Jun 17 13:46:33 2008 From: brandon.galbraith at gmail.com (Brandon Galbraith) Date: Tue, 17 Jun 2008 13:46:33 -0500 Subject: Comcast Business IPv6 Message-ID: <366100670806171146g41100b87mfffdaeb0e6080e95@mail.gmail.com> Has anyone had any experience with asking Comcast Business Services for IPv6 connectivity? Off-list replies are preferred (feel free to contact me if you're looking for the same thing, will pass along any info I obtain). Thanks! -brandon From jra at baylink.com Tue Jun 17 16:15:22 2008 From: jra at baylink.com (Jay R. Ashworth) Date: Tue, 17 Jun 2008 17:15:22 -0400 Subject: Cable Colors In-Reply-To: References: <785694cd0806161532s4a205b3ey19d2aef1eb12285e@mail.gmail.com> <4856F0BC.5000607@aset.com> <4856FD4B.9010202@davidcoulson.net> <48573FB0.4020901@ibctech.ca> <48574122.405@davidcoulson.net> <485745A4.3080406@ibctech.ca> <20080617125249.GA424@cgi.jachomes.com> Message-ID: <20080617211522.GG1556@cgi.jachomes.com> On Tue, Jun 17, 2008 at 01:28:38PM -0400, Joe Abley wrote: > The initial cable install for the pre-provisioned servers was done > with much planning and documentation by people who did data cabling > for a living, and was correspondingly tidy. The cables were all blue. > Any change that was required after that was installed using a red cable. > > Once per week the data cabling people would return, within a posted > window, and replace the temporary red patch cables with cut-to-length, > tested, blue cables which were run according to the larger cabling > strategy, and rigourously documented. Ah yes, the 'purple wire' technique. I forget which book it's mentioned in, but it had to do with really old wire-wrapped computer boards. If you had to put in such a 'hack' wire, you did it in purple so it would stand out. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com '87 e24 St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 Those who cast the vote decide nothing. Those who count the vote decide everything. -- (Joseph Stalin) From ge at linuxbox.org Tue Jun 17 19:24:20 2008 From: ge at linuxbox.org (Gadi Evron) Date: Tue, 17 Jun 2008 19:24:20 -0500 (CDT) Subject: [Outages] Outages have an Outage? (fwd) Message-ID: Lightning storm, subsequent commercial power failure. UPS not up due to restructing. We are working on getting backup servers alive, as to DNS we used to secondary at vixie's, but due to IP changes and movements removed that for now. A comedy of mistakes. Details below. ---------- Forwarded message ---------- Date: Tue, 17 Jun 2008 21:18:45 +0000 From: Randy Vaughn To: Jason Iannone Cc: outages at isotf.org Subject: Re: [Outages] Outages have an Outage? Hi Jason et al! The rack restructuring was only able to proceed as far as one rack and did not make to the point of attaching the isotf server to a UPS. As luck has it, our provider's location lost commercial power this morning. The remainder of the rack restructuring will be announced once we have a firm timeline established for that activity. On a slightly different matter. I appreciate the problems caused by high list volume. Digest mode is one potential solution, list moderation is another. R On 14:55 Tue 17 Jun , Jason Iannone wrote: > We weren't able to resolve anything on amigostecnicos.net. isotf > admin care to elaborate? > _______________________________________________ > Outages mailing list > Outages at isotf.org > http://isotf.org/mailman/listinfo/outages _______________________________________________ Outages mailing list Outages at isotf.org http://isotf.org/mailman/listinfo/outages From LarrySheldon at cox.net Tue Jun 17 19:38:03 2008 From: LarrySheldon at cox.net (Laurence F. Sheldon, Jr.) Date: Tue, 17 Jun 2008 19:38:03 -0500 Subject: [Outages] Outages have an Outage? (fwd) In-Reply-To: References: Message-ID: <485858EB.2030506@cox.net> Gadi Evron wrote: > Lightning storm, subsequent commercial power failure. UPS not up due to > restructing. How does it go..."For the want of a nail..." Nope ... "The cobblers son...." Maybe that is the one. > We are working on getting backup servers alive, as to DNS we used to > secondary at vixie's, but due to IP changes and movements removed that > for now. > > A comedy of mistakes. Funny unless you are explaining it to the boss. -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs From ops.lists at gmail.com Tue Jun 17 21:54:10 2008 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Tue, 17 Jun 2008 19:54:10 -0700 Subject: Latest instalment of the "hijacked /16s" story Message-ID: <485878d2.qzmcM+qfoe5r1k3u%ops.lists@gmail.com> Another legacy /16, after the previous one - the sf bay packet radio /16 http://www.47-usc-230c2.org/chapter3.html This time 128.168/16 - and by the same group that seems to have acquired control of the earlier one. --srs -- Suresh Ramasubramanian (ops.lists at gmail.com) From francois at menards.ca Tue Jun 17 22:43:35 2008 From: francois at menards.ca (Francois Menard) Date: Tue, 17 Jun 2008 23:43:35 -0400 Subject: PPPoE over L2TP over GigE questions In-Reply-To: <4857DE17.6050505@thewybles.com> References: <484FF305.8010001@vaxination.ca> <86od67u5ix.fsf@seastrom.com> <4857DE17.6050505@thewybles.com> Message-ID: How about a couple more rabbit holes to dig into: Try to find the intersection between: DSL Forum TR-101 unbundling Bell replacing tunnel switching with AGAS 802.3AH PBB QinQ NENA i2 Wiremap update protocol LIS SIP Location Conveyance PIDF-LO transmission over the NENA i2 V0 interface Carrying the originating DSLAM port over the RADIUS accounting interface Bitstream unbundling of the multicast plane Denial of access to subloop unbundling Phase II costing of DSL access and capping mark-ups to 15% Capping the mark-up for conditional-essential services Throttling DPI Net Neutrality Dark fibre forbearance Phase out of non-essential services You mix this alphabet soup, eat a good portion daily - this keeps your brain sharp and the doctor away We're trying to figure out how the next 10 years of DSL unbundling will be done, such as that it will support prioritized VoIP, triple play and E-9-1-1, and how ISPs will be able to secure their own DSL aggregation out of dark fibre being available at tariffed rates. Comments due June 25 at the CRTC. F. On 17-Jun-08, at 11:53 AM, Charles N Wyble wrote: > > This has been a very informative thread. All sorts of acronyms to > research and so forth. :) > > The mention of TR-101 took me down another rabbit hole, and I > discovered > http://www.dslforum.org/trlist/trlist.php. > > Very interesting info. > > Charles > > > -- > Charles N Wyble (818) 280-7059 > http://charlesnw.blogspot.com > > > -- Fran?ois D. M?nard francois at menards.ca From justin at justinshore.com Tue Jun 17 23:10:39 2008 From: justin at justinshore.com (Justin Shore) Date: Tue, 17 Jun 2008 23:10:39 -0500 Subject: Latest instalment of the "hijacked /16s" story In-Reply-To: <485878d2.qzmcM+qfoe5r1k3u%ops.lists@gmail.com> References: <485878d2.qzmcM+qfoe5r1k3u%ops.lists@gmail.com> Message-ID: <48588ABF.4040605@justinshore.com> Is the whole AS (33302) rogue like the AS advertising the SF Bay Packet Radio block is? Looking at the WHOIS for some of the prefixes advertised by both ASs, I see some common company names. That would lead me to believe that 33302 is no better than 33211 but I can't confirm that. Any takers? Justin Suresh Ramasubramanian wrote: > Another legacy /16, after the previous one - the sf bay packet radio /16 > > http://www.47-usc-230c2.org/chapter3.html > > This time 128.168/16 - and by the same group that seems to have acquired > control of the earlier one. > > --srs > From ops.lists at gmail.com Wed Jun 18 00:38:24 2008 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Wed, 18 Jun 2008 11:08:24 +0530 Subject: Latest instalment of the "hijacked /16s" story In-Reply-To: <48588ABF.4040605@justinshore.com> References: <485878d2.qzmcM+qfoe5r1k3u%ops.lists@gmail.com> <48588ABF.4040605@justinshore.com> Message-ID: On Wed, Jun 18, 2008 at 9:40 AM, Justin Shore wrote: > Is the whole AS (33302) rogue like the AS advertising the SF Bay Packet > Radio block is? Looking at the WHOIS for some of the prefixes advertised by > both ASs, I see some common company names. That would lead me to believe > that 33302 is no better than 33211 but I can't confirm that. Any takers? Not sure. The AS announces some more but an arin query for DATA102 simply has this /16 and a smaller netblock That 47-usc site is not mine either .. its by Ron Guilmette, interviewed in the Wash Post - http://blog.washingtonpost.com/securityfix/2008/04/a_case_of_network_identity_the_1.html suresh at frodo 22:17:45 <~> $ whois -h whois.arin.net Data102* Data102 Abuse Team (DAT13-ARIN) abuse at data102.com +1-719-578-8842 Data102 Network Ops (DNO44-ARIN) netops at data102.com +1-719-578-8842 Data Works Inc DATA102984 (NET-63-243-82-144-1) 63.243.82.144 - 63.243.82.159 Gold Hill Computers DATA102 (NET-128-168-0-0-1) 128.168.0.0 - 128.168.255.255 From randy at psg.com Wed Jun 18 00:55:40 2008 From: randy at psg.com (Randy Bush) Date: Wed, 18 Jun 2008 14:55:40 +0900 Subject: Latest instalment of the "hijacked /16s" story In-Reply-To: <485878d2.qzmcM+qfoe5r1k3u%ops.lists@gmail.com> References: <485878d2.qzmcM+qfoe5r1k3u%ops.lists@gmail.com> Message-ID: <4858A35C.9050200@psg.com> Suresh Ramasubramanian wrote: > Another legacy /16, after the previous one - the sf bay packet radio /16 > http://www.47-usc-230c2.org/chapter3.html > This time 128.168/16 - and by the same group that seems to have acquired > control of the earlier one. luckily, there is no black market in address space. or at least so the theory goes on arin and ripe public policy lists. randy From tomb at byrneit.net Wed Jun 18 00:59:21 2008 From: tomb at byrneit.net (Tomas L. Byrnes) Date: Tue, 17 Jun 2008 22:59:21 -0700 Subject: Latest instalment of the "hijacked /16s" story In-Reply-To: <4858A35C.9050200@psg.com> References: <485878d2.qzmcM+qfoe5r1k3u%ops.lists@gmail.com> <4858A35C.9050200@psg.com> Message-ID: <70D072392E56884193E3D2DE09C097A9F222@pascal.zaphodb.org> And there is also no black market in credit card, social security, and PIN numbers. "See no evil, hear no evil, fear no evil" > -----Original Message----- > From: Randy Bush [mailto:randy at psg.com] > Sent: Tuesday, June 17, 2008 10:56 PM > To: Suresh Ramasubramanian > Cc: nanog at nanog.org > Subject: Re: Latest instalment of the "hijacked /16s" story > > Suresh Ramasubramanian wrote: > > Another legacy /16, after the previous one - the sf bay > packet radio > > /16 http://www.47-usc-230c2.org/chapter3.html > > This time 128.168/16 - and by the same group that seems to have > > acquired control of the earlier one. > > luckily, there is no black market in address space. or at > least so the theory goes on arin and ripe public policy lists. > > randy > > > From leo.vegoda at icann.org Wed Jun 18 04:56:33 2008 From: leo.vegoda at icann.org (Leo Vegoda) Date: Wed, 18 Jun 2008 02:56:33 -0700 Subject: AS Numbers registry updated Message-ID: Hi, This is to let you know that we have updated the AS Numbers registry in cooperation with the RIRs. It now shows which RIR currently provides Whois service for an AS Number instead of the RIR to which the AS Number was originally allocated. The updated registry is now over 2000 lines long but the format has not changed. In addition to the current format, the AS Numbers registry will be made available in XML during July. The updated registry will shortly be available at: http://www.iana.org/assignments/as-numbers Kind regards, Leo Vegoda IANA From michael.dillon at bt.com Wed Jun 18 05:32:35 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Wed, 18 Jun 2008 11:32:35 +0100 Subject: Latest instalment of the "hijacked /16s" story In-Reply-To: <4858A35C.9050200@psg.com> Message-ID: > > http://www.47-usc-230c2.org/chapter3.html > > This time 128.168/16 - and by the same group that seems to have > > acquired control of the earlier one. > > luckily, there is no black market in address space. or at > least so the theory goes on arin and ripe public policy lists. No, the theory goes that there *IS* a black market and changing ARIN or RIPE policies to make it a white market would be a bad idea. Better to help ARIN to document the fact that this is not a valid allocation so that they can recover the block. --Michael Dillon From nanog-post at rsuc.gweep.net Wed Jun 18 06:57:22 2008 From: nanog-post at rsuc.gweep.net (Joe Provo) Date: Wed, 18 Jun 2008 07:57:22 -0400 Subject: Latest instalment of the "hijacked /16s" story In-Reply-To: <70D072392E56884193E3D2DE09C097A9F222@pascal.zaphodb.org> References: <485878d2.qzmcM+qfoe5r1k3u%ops.lists@gmail.com> <4858A35C.9050200@psg.com> <70D072392E56884193E3D2DE09C097A9F222@pascal.zaphodb.org> Message-ID: <20080618115722.GA84429@gweep.net> On Tue, Jun 17, 2008 at 10:59:21PM -0700, Tomas L. Byrnes wrote: [snip] > "See no evil, hear no evil, fear no evil" The (human) operators who cared have been pushed out by the (coprorate) operators who would rather disavow responsibility, turn up quickly, and book the revenue instead of vetting any customer claims for basis in fact or reason. Customer filtering -even when black hats drive an AS- is Not Hard if the backbones (nets) displayed actual backbone (spine). -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE From steve at ibctech.ca Wed Jun 18 07:18:25 2008 From: steve at ibctech.ca (Steve Bertrand) Date: Wed, 18 Jun 2008 08:18:25 -0400 Subject: SMTP no-such-user issues In-Reply-To: <485733E9.5030008@ibctech.ca> References: <485733E9.5030008@ibctech.ca> Message-ID: <4858FD11.6080103@ibctech.ca> Steve Bertrand wrote: > Hi everyone, > > We are experiencing an issue in regards to SMTP MTA relay responses > regarding 'no such user', and it *apparently* appears to be only > occurring when a particular site attempts to deliver email to us. For the sake of completeness... The problem has been found within the defining of a variable in chkuser: "But I found the problem. chkuser_settings.h shows: #define CHKUSER_NORCPT_STRING "511 sorry, no mailbox here by that name (#5.1.1 - chkuser)\r\n" I changed the 511 to 550 (as shown here http://www.faqs.org/rfcs/rfc821.html )" I'm also told that version 2.09 of chkuser works around this problem. For those who have recommended Postfix, I'd love to switch, however Qmail is tied so tightly into my mail infrastructure at this point that I don't think it would be possible without months and months of planning, and redeveloping a whole lot of internal management software. Thanks everyone, Steve From jared at puck.nether.net Wed Jun 18 07:25:39 2008 From: jared at puck.nether.net (Jared Mauch) Date: Wed, 18 Jun 2008 08:25:39 -0400 Subject: Latest instalment of the "hijacked /16s" story In-Reply-To: <20080618115722.GA84429@gweep.net> References: <485878d2.qzmcM+qfoe5r1k3u%ops.lists@gmail.com> <4858A35C.9050200@psg.com> <70D072392E56884193E3D2DE09C097A9F222@pascal.zaphodb.org> <20080618115722.GA84429@gweep.net> Message-ID: On Jun 18, 2008, at 7:57 AM, Joe Provo wrote: > On Tue, Jun 17, 2008 at 10:59:21PM -0700, Tomas L. Byrnes wrote: > [snip] >> "See no evil, hear no evil, fear no evil" > > The (human) operators who cared have been pushed out by the > (coprorate) operators who would rather disavow responsibility, > turn up quickly, and book the revenue instead of vetting any > customer claims for basis in fact or reason. Customer > filtering -even when black hats drive an AS- is Not Hard if > the backbones (nets) displayed actual backbone (spine). I would argue the same for any/all security issues. If people would just shut off $VALUE, we'd have a lot fewer problems on the network. I will concede the problem is making it scale and viable for some parties. The ones that don't make the inherent security of the global network a priority are dragging the average down. - jared VALUE = ( infected host ip/customer, route leaker/hijacker, nonfiltering customer, ... ) From randy at psg.com Wed Jun 18 08:11:50 2008 From: randy at psg.com (Randy Bush) Date: Wed, 18 Jun 2008 22:11:50 +0900 Subject: Latest instalment of the "hijacked /16s" story In-Reply-To: <20080618115722.GA84429@gweep.net> References: <485878d2.qzmcM+qfoe5r1k3u%ops.lists@gmail.com> <4858A35C.9050200@psg.com> <70D072392E56884193E3D2DE09C097A9F222@pascal.zaphodb.org> <20080618115722.GA84429@gweep.net> Message-ID: <48590996.4070707@psg.com> > The (human) operators who cared have been pushed out by the > (coprorate) operators who would rather disavow responsibility, > turn up quickly, and book the revenue instead of vetting any > customer claims for basis in fact or reason. Customer > filtering -even when black hats drive an AS- is Not Hard if > the backbones (nets) displayed actual backbone (spine). there is a reason i am in japan. well, many actually. randy From adrian at creative.net.au Wed Jun 18 09:42:22 2008 From: adrian at creative.net.au (Adrian Chadd) Date: Wed, 18 Jun 2008 22:42:22 +0800 Subject: P2P agents for software distribution - saving the WAN from meltdown?!? In-Reply-To: <75cb24520806171100s28de94f8h80cff4a3b4982257@mail.gmail.com> References: <200806160853.20416.netfortius@gmail.com> <75cb24520806171100s28de94f8h80cff4a3b4982257@mail.gmail.com> Message-ID: <20080618144222.GA20909@skywalker.creative.net.au> On Tue, Jun 17, 2008, Christopher Morrow wrote: > most of the larger free-nix's do BT downloads on release day(s). > Revision3 distributes their content via BT. There were rumors of > Disney and Apple moving to BT models for their content distribution at > one point as well. If only there was a way for a SP to run a BitTorrent type service for their clients, subscribing the BT server(s) to known-good (ie, not warez-y) torrents pre-seeded from trusted sources and then leaving it the hell alone and not having to continuously dump specific torrent files into it. Hm! Adrian From jabley at ca.afilias.info Wed Jun 18 09:52:38 2008 From: jabley at ca.afilias.info (Joe Abley) Date: Wed, 18 Jun 2008 10:52:38 -0400 Subject: P2P agents for software distribution - saving the WAN from meltdown?!? In-Reply-To: <20080618144222.GA20909@skywalker.creative.net.au> References: <200806160853.20416.netfortius@gmail.com> <75cb24520806171100s28de94f8h80cff4a3b4982257@mail.gmail.com> <20080618144222.GA20909@skywalker.creative.net.au> Message-ID: <376FFC1C-478B-43DA-858D-22CBAE7AEC96@ca.afilias.info> On 18 Jun 2008, at 10:42, Adrian Chadd wrote: > > If only there was a way for a SP to run a BitTorrent type service for > their clients, subscribing the BT server(s) to known-good (ie, not > warez-y) > torrents pre-seeded from trusted sources and then leaving it the hell > alone and not having to continuously dump specific torrent files into > it. > Automatically leeching and then seeding for long periods is trivial to set up if you can get an RSS feed with torrent enclosures. It is my (highly theoretical, naturally) understanding that many BitTorrent trackers make such feeds available. However just because you have a fast, on-net seed for particular torrents doesn't mean that your on-net leechers will necessarily pick it up. The behaviour I have observed with BitTorrent is that clients are handed a relatively short list of potential peers by the tracker, and it's quite common for sensible, close, local peers not to be included. My assumption has been that the set of potential peers passed to the client is assembled randomly. If this behaviour is widespread (i.e. if my observations are valid and my interpretation of those observations reasonable) then the more popular the content, the less likely leechers are to see the seed you want them to see. This relegates your local, on-net, fast seed to be a way of distributing unpopular content (that which is not being seeded by many other people). There has been at least one presentation at NANOG in the past couple of years which describes the benefit to ISPs of p2p, by virtue of keeping traffic for popular content on-net. From memory, however, that presentation was based on a non-deployed p2p protocol which made more of an effort to help peers find local peers than the clients I described above. Joe From warren at kumari.net Wed Jun 18 10:06:12 2008 From: warren at kumari.net (Warren Kumari) Date: Wed, 18 Jun 2008 11:06:12 -0400 Subject: P2P agents for software distribution - saving the WAN from meltdown?!? In-Reply-To: <20080618144222.GA20909@skywalker.creative.net.au> References: <200806160853.20416.netfortius@gmail.com> <75cb24520806171100s28de94f8h80cff4a3b4982257@mail.gmail.com> <20080618144222.GA20909@skywalker.creative.net.au> Message-ID: On Jun 18, 2008, at 10:42 AM, Adrian Chadd wrote: > On Tue, Jun 17, 2008, Christopher Morrow wrote: > >> most of the larger free-nix's do BT downloads on release day(s). >> Revision3 distributes their content via BT. There were rumors of >> Disney and Apple moving to BT models for their content distribution >> at >> one point as well. > > > If only there was a way for a SP to run a BitTorrent type service for > their clients, subscribing the BT server(s) to known-good (ie, not > warez-y) > torrents pre-seeded from trusted sources and then leaving it the hell > alone and not having to continuously dump specific torrent files into > it. > > Ah, if only there was a way for my SP to go and look all over the web and figure out what pages are acceptable for me to browse and block out all of the other stuff like porn and warez and phishing --- and other objectionable content like creationism / evolution [delete whichever is appropriate ], those bastard [insert your least favorite ethnic / religious group here ] and any mention of [insert political party]..... Oh, and anything to do with clowns, they freak me out... Yes, P2P is not the web, but the general principle still applies -- I don't think that handing over the censorship keys to my ISP is a reasonable solution... W > Hm! > > > > Adrian > > -- Do not meddle in the affairs of wizards, for they are subtle and quick to anger. -- J.R.R. Tolkien From bortzmeyer at nic.fr Wed Jun 18 10:21:42 2008 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Wed, 18 Jun 2008 17:21:42 +0200 Subject: P2P agents for software distribution - saving the WAN from meltdown?!? In-Reply-To: <376FFC1C-478B-43DA-858D-22CBAE7AEC96@ca.afilias.info> References: <200806160853.20416.netfortius@gmail.com> <75cb24520806171100s28de94f8h80cff4a3b4982257@mail.gmail.com> <20080618144222.GA20909@skywalker.creative.net.au> <376FFC1C-478B-43DA-858D-22CBAE7AEC96@ca.afilias.info> Message-ID: <20080618152142.GA31833@laperouse.bortzmeyer.org> On Wed, Jun 18, 2008 at 10:52:38AM -0400, Joe Abley wrote a message of 41 lines which said: > The behaviour I have observed with BitTorrent is that clients are > handed a relatively short list of potential peers by the tracker, > and it's quite common for sensible, close, local peers not to be > included. My assumption has been that the set of potential peers > passed to the client is assembled randomly. I did not check seriously so I cannot confirm or deny but do note that there are several proposals to improve "peer selection" behind random sorting or crude measurements with ping on a few hosts. A summary of existing work is on the ALTO Web site . ALTO will have a BoF session at the next IETF in Dublin, so we may see one day a standard protocol for peer selection. From adrian at creative.net.au Wed Jun 18 10:27:10 2008 From: adrian at creative.net.au (Adrian Chadd) Date: Wed, 18 Jun 2008 23:27:10 +0800 Subject: P2P agents for software distribution - saving the WAN from meltdown?!? In-Reply-To: References: <200806160853.20416.netfortius@gmail.com> <75cb24520806171100s28de94f8h80cff4a3b4982257@mail.gmail.com> <20080618144222.GA20909@skywalker.creative.net.au> Message-ID: <20080618152710.GB20909@skywalker.creative.net.au> On Wed, Jun 18, 2008, Warren Kumari wrote: > Yes, P2P is not the web, but the general principle still applies -- I > don't think that handing over the censorship keys to my ISP is a > reasonable solution... I dunno, an RSS type feed of bittorrent files which can be subscribed to would be useful. You could then just subscribe to certain content, implictly trusting that they're publishing sensible content (and filtering the content you seed your torrent with using tags or some such.) You could then subscribe to various projects' downloads and mirror appropriately. Of course, this could already be being done; I haven't any idea. :) Adrian From nanog at daork.net Wed Jun 18 10:29:36 2008 From: nanog at daork.net (Nathan Ward) Date: Thu, 19 Jun 2008 03:29:36 +1200 Subject: P2P agents for software distribution - saving the WAN from meltdown?!? In-Reply-To: <376FFC1C-478B-43DA-858D-22CBAE7AEC96@ca.afilias.info> References: <200806160853.20416.netfortius@gmail.com> <75cb24520806171100s28de94f8h80cff4a3b4982257@mail.gmail.com> <20080618144222.GA20909@skywalker.creative.net.au> <376FFC1C-478B-43DA-858D-22CBAE7AEC96@ca.afilias.info> Message-ID: On 19/06/2008, at 2:52 AM, Joe Abley wrote: > On 18 Jun 2008, at 10:42, Adrian Chadd wrote: >> >> If only there was a way for a SP to run a BitTorrent type service for >> their clients, subscribing the BT server(s) to known-good (ie, not >> warez-y) >> torrents pre-seeded from trusted sources and then leaving it the hell >> alone and not having to continuously dump specific torrent files into >> it. >> > > Automatically leeching and then seeding for long periods is trivial > to set up if you can get an RSS feed with torrent enclosures. It is > my (highly theoretical, naturally) understanding that many > BitTorrent trackers make such feeds available. > > However just because you have a fast, on-net seed for particular > torrents doesn't mean that your on-net leechers will necessarily > pick it up. The behaviour I have observed with BitTorrent is that > clients are handed a relatively short list of potential peers by the > tracker, and it's quite common for sensible, close, local peers not > to be included. My assumption has been that the set of potential > peers passed to the client is assembled randomly. > > If this behaviour is widespread (i.e. if my observations are valid > and my interpretation of those observations reasonable) then the > more popular the content, the less likely leechers are to see the > seed you want them to see. This relegates your local, on-net, fast > seed to be a way of distributing unpopular content (that which is > not being seeded by many other people). > > There has been at least one presentation at NANOG in the past couple > of years which describes the benefit to ISPs of p2p, by virtue of > keeping traffic for popular content on-net. From memory, however, > that presentation was based on a non-deployed p2p protocol which > made more of an effort to help peers find local peers than the > clients I described above. There was a product around that would keep track of torrents and fudge the tracker responses to direct you to on-net peers where possible. Not sure what it's called. Inline box thing, much like Sandvine, Allot, etc. I imagine you could either inject the details of a local seed you're running, or keep track of on-net users and inject those. From a tracker software point of view, it would be fairly trivial to weight peer lists to prefer peers within the same ASN I imagine. Perhaps that could be turned in to same country, or what not. Better, combine it with some kind of rough AS adjacency graph and and viola. Is there any data available that would let that happen easily? Obviously routing tables for the ASN/IP mapping, but what about rough ASN adjacency? It doesn't really need to be updated that often - even CAIDA's yearly data that they use to make their pretty pictures could work OK. Seems like win/win/win - linux distribution vendors can pride themselves on how much faster their torrents run, end users get better speeds for their torrents, networks move less traffic off-net. .. this is the part where someone bustles off and makes it go. -- Nathan Ward From groups at digital-z.com Wed Jun 18 11:20:28 2008 From: groups at digital-z.com (Blaine Fleming) Date: Wed, 18 Jun 2008 10:20:28 -0600 Subject: P2P agents for software distribution - saving the WAN from meltdown?!? In-Reply-To: <75cb24520806171100s28de94f8h80cff4a3b4982257@mail.gmail.com> References: <200806160853.20416.netfortius@gmail.com> <75cb24520806171100s28de94f8h80cff4a3b4982257@mail.gmail.com> Message-ID: <485935CC.5020402@digital-z.com> Christopher Morrow wrote: > On Mon, Jun 16, 2008 at 9:53 AM, Netfortius wrote: > >> Has anybody used (and been successful at) a bit-torrent-like agent for fast >> distribution of LEGAL software (install programs of large-DVD size), across >> multiple sites, all over the globe, with bad WAN connectivity? I have read a >> couple of references online (e.g. >> http://torrentfreak.com/university-uses-utorrent-080306/) about such, but I >> am a little reluctant to do it in a corporate environment, especially in the >> light of potential misuse of such ... unless finding a way to install, use >> and remove the P2P agent, all in one shot ... catch 22, sort of (distributing >> the P2P agent, that is :)) ... >> > > revision3.com > And we saw how it worked out for Revision3.com. MediaDefender considered them illegal and launched a Denial of Service attack against them over Memorial Day weekend. P2P is considered illegal and wrong by people with lots of money and that makes it hard to use for legitimate services. Because MediaDefender is backed by the RIAA and similar organizations they seem to be immune to prosecution. However, if *I* did the same thing then I know I would be locked up right now. --Blaine From ren.provo at gmail.com Wed Jun 18 12:46:02 2008 From: ren.provo at gmail.com (Ren Provo) Date: Wed, 18 Jun 2008 13:46:02 -0400 Subject: [NANOG-announce] Reminder - NANOG PC tool is accepting presentations for both NANOG 44 & 45 Message-ID: <787581440806181046g5b576b9bn138d5321943985ea@mail.gmail.com> Hi folks, As mentioned in the NANOG Program Committee call minutes, posted at http://www.nanog.org/pc.nanog44_minutes.html, we are currently accepting presentations for both NANOG44 and NANOG45. Several abstracts have been received for the October meeting and we are going to assume they are intended for NANOG44. Please clearly mark submissions if NANOG45 is your intention. Our next call is scheduled for early July so keep the submissions, and promised slides for those with abstracts in the tool at present, flowing. Thanks! -Ren, on behalf of the NANOG Program Committee _______________________________________________ NANOG-announce mailing list NANOG-announce at nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-announce From laird at pando.com Wed Jun 18 14:43:21 2008 From: laird at pando.com (Laird Popkin) Date: Wed, 18 Jun 2008 15:43:21 -0400 (EDT) Subject: P2P agents for software distribution - saving the WAN from meltdown?!? In-Reply-To: <115717186.412471213817624581.JavaMail.root@dkny.pando.com> Message-ID: <1974940950.412541213818201463.JavaMail.root@dkny.pando.com> To address the original question, there are several p2p companies focusing on optimizing p2p for internal distribution of software and rich media. In particular, Kontiki and Ignite both offer such services, and between the two have many of the Fortune 1000 as customers (Coke, Bank of America, Accenture, McDonalds, Canon, Burger King, etc.). Their systems manage not just the (p2p) physical delivery of the bits, but also the enterprise management aspects (e.g. sending the right versions of the right software to the right desktops, managing data flow in a way that works well on a corporate LAN, security, running the installs/upgrades, etc.). Addressing the Revision3 comment in the thread, I don't think that the "RIAA and similar organizations" had any problem with Revision3 using the BitTorrent protocol, but with them running an (inadvertently) open Tracker that was hosting 250K pirate torrents. The "attack" was pretty clearly a MediaDefender software bug in their code that monitors pirate torrents, multiplied by the large number of servers that they run, which unfortunately kicked in over a holiday weekend when nobody was around to fix it. Once MediaDefender was notified of the problem, Revision3 said that it was fixed quickly. So while you may not like what MediaDefender does for a living, it doesn't look like they were trying to DDOS Revision3 for using p2p protocols. - Laird Popkin, CTO, Pando Networks mobile: 646/465-0570 ----- Original Message ----- From: "Blaine Fleming" To: nanog at merit.edu Sent: Wednesday, June 18, 2008 12:20:28 PM (GMT-0500) America/New_York Subject: Re: P2P agents for software distribution - saving the WAN from meltdown?!? Christopher Morrow wrote: > On Mon, Jun 16, 2008 at 9:53 AM, Netfortius wrote: > >> Has anybody used (and been successful at) a bit-torrent-like agent for fast >> distribution of LEGAL software (install programs of large-DVD size), across >> multiple sites, all over the globe, with bad WAN connectivity? I have read a >> couple of references online (e.g. >> http://torrentfreak.com/university-uses-utorrent-080306/) about such, but I >> am a little reluctant to do it in a corporate environment, especially in the >> light of potential misuse of such ... unless finding a way to install, use >> and remove the P2P agent, all in one shot ... catch 22, sort of (distributing >> the P2P agent, that is :)) ... >> > > revision3.com > And we saw how it worked out for Revision3.com. MediaDefender considered them illegal and launched a Denial of Service attack against them over Memorial Day weekend. P2P is considered illegal and wrong by people with lots of money and that makes it hard to use for legitimate services. Because MediaDefender is backed by the RIAA and similar organizations they seem to be immune to prosecution. However, if *I* did the same thing then I know I would be locked up right now. --Blaine From josmon at rigozsaurus.com Wed Jun 18 15:50:37 2008 From: josmon at rigozsaurus.com (John Osmon) Date: Wed, 18 Jun 2008 14:50:37 -0600 Subject: A pipe dream? [WAS: Re: P2P agents for software distribution - saving the WAN from meltdown?!?] In-Reply-To: <20080618144222.GA20909@skywalker.creative.net.au> References: <200806160853.20416.netfortius@gmail.com> <75cb24520806171100s28de94f8h80cff4a3b4982257@mail.gmail.com> <20080618144222.GA20909@skywalker.creative.net.au> Message-ID: <20080618205037.GA29460@jeeves.rigozsaurus.com> On Wed, Jun 18, 2008 at 10:42:22PM +0800, Adrian Chadd wrote: [...] > > If only there was a way for a SP to run a BitTorrent type service for > their clients, subscribing the BT server(s) to known-good (ie, not warez-y) > torrents pre-seeded from trusted sources and then leaving it the hell > alone and not having to continuously dump specific torrent files into > it. > Modifying the P2P protocols might help find good seeds, etc. However, I always like to take this thought a bit further and combine it with a particular Network Neutrality "solution." Imagine a world where "Net Neutral" means that you have a neutral layer 2 architecture and you're free to choose the layer 3 provider. (Model it on US West/Qwest's original DSL product.) Then, sprinkle in a *bunch* of ISPs that must have transparent layer 3 policies. Let them block/fold/mutilate/spindle/synthesize packets at their whim -- as long as they *tell* the customer what they're going to do. In the end, I can see ISPs that do *nothing* to your traffic, and charge what we would call "normal" pricing. There would be cut-rate ISPs that would promise best-effort, but will throttle if they have congestion issues. If you're an ISP, you might even try to cut a deal with the RIAA and/or MPAA so your customers have *fast* access to legitimate content. As a content provider, I would look seriously into subsidizing the access costs so that I could capture an end user... Guess I picked the wrong week to stop sniffing glue... From justin at justinshore.com Wed Jun 18 17:22:28 2008 From: justin at justinshore.com (Justin Shore) Date: Wed, 18 Jun 2008 17:22:28 -0500 Subject: P2P agents for software distribution - saving the WAN from meltdown?!? In-Reply-To: References: <200806160853.20416.netfortius@gmail.com> <75cb24520806171100s28de94f8h80cff4a3b4982257@mail.gmail.com> <20080618144222.GA20909@skywalker.creative.net.au> <376FFC1C-478B-43DA-858D-22CBAE7AEC96@ca.afilias.info> Message-ID: <48598AA4.2010406@justinshore.com> Nathan Ward wrote: > There was a product around that would keep track of torrents and fudge > the tracker responses to direct you to on-net peers where possible. Not > sure what it's called. Inline box thing, much like Sandvine, Allot, etc. > I imagine you could either inject the details of a local seed you're > running, or keep track of on-net users and inject those. Out of curiosity, how many SPs out there have local Akamai servers on their network? I inquired about it last Fall and our average bandwidth to Akamai wasn't enough at the time to warrant placing hardware on our site, from their perspective anyway. The bandwidth though accounted for roughly 1/10th of our overall bandwidth. I wonder what it would be today. Our Internet bandwidth is just over 4x what it was last Fall. Justin From joe_hznm at yahoo.com.sg Thu Jun 19 10:37:54 2008 From: joe_hznm at yahoo.com.sg (Joe Shen) Date: Thu, 19 Jun 2008 23:37:54 +0800 (SGT) Subject: Wifi access problem: control session time and accounting accuracy Message-ID: <795353.23256.qm@web76304.mail.sg1.yahoo.com> hi, we provide Wifi access to customers. The basic system architecture is, customer get IP address using DHCP, but BAS limit customer access to special IP address block before customer log in. Customer log in at portal page, where policy server get username/passwed and authenticate by sending radius packets to AAA server. We use Redback NPM with SE800 and Juniper C2k with E1440. We met two problem : 1. Could we control customer session time according to radius authentication echo message ( Session-timeout )? it seems redback could not translate Session-timeout to its internal control policy. 2. How could we track customer status ? we noticed some people leave hotspot without log out explicitly disconnect. There leave a lot of open session record on radius server, because no Accouting-Off packet received. Is there any mechanism we could use to detect cliet status in Wifi environment ? ( e.g. PPPOE keepalive message ) thanks in advance . Joe Try cool new emoticons, skins, plus more space for friends. Download Yahoo! Messenger Singapore now! http://sg.messenger.yahoo.com From ppauly at gmail.com Thu Jun 19 10:43:26 2008 From: ppauly at gmail.com (Peter Pauly) Date: Thu, 19 Jun 2008 11:43:26 -0400 Subject: Level 3 / Time Warner problem in Columbus OH? Message-ID: Time Warner is reporting to me that their provider, Level 3 is having problems in Columbus OH that is affecting several large midwest cities. Anyone have more details? From mwalter at 3z.net Thu Jun 19 10:48:03 2008 From: mwalter at 3z.net (Mike Walter) Date: Thu, 19 Jun 2008 11:48:03 -0400 Subject: Level 3 / Time Warner problem in Columbus OH? In-Reply-To: References: Message-ID: Just spoke with TW Telecom on my ticket. They have (2) OC-192s down in the Ohio area. They have open troubles with their vendor. Seems odd that both are down according to the rep I spoke with. We have shut down our TW Telecom BGP session until resolved due to high latency. Mike Walter, MCP Systems Administrator 3z.net -----Original Message----- From: Peter Pauly [mailto:ppauly at gmail.com] Sent: Thursday, June 19, 2008 11:43 AM To: Nanog Mailing list Subject: Level 3 / Time Warner problem in Columbus OH? Time Warner is reporting to me that their provider, Level 3 is having problems in Columbus OH that is affecting several large midwest cities. Anyone have more details? From rkidder at safelitegroup.com Thu Jun 19 10:58:24 2008 From: rkidder at safelitegroup.com (Roy Kidder) Date: Thu, 19 Jun 2008 11:58:24 -0400 Subject: Level 3 / Time Warner problem in Columbus OH? In-Reply-To: References: Message-ID: <1213891104.9853.38.camel@allanon.safelite.com> Master ticket number is ST78001, effecting OH, IN, KY. They report that they have a couple of OC-192s down. On Thu, 2008-06-19 at 11:43 -0400, Peter Pauly wrote: > Time Warner is reporting to me that their provider, Level 3 is having > problems in Columbus OH that is affecting several large midwest > cities. Anyone have more details? > From steve at zimcom.net Thu Jun 19 11:15:04 2008 From: steve at zimcom.net (Steve Searles) Date: Thu, 19 Jun 2008 12:15:04 -0400 Subject: Level 3 / Time Warner problem in Columbus OH? In-Reply-To: References: Message-ID: Same here, we have also shut down our TWT peer. Steve Searles Sr. Network Engineer Zimmerman Communications Inc. http://www.zimcom.net Phone. 513-624-3900 Fax. 513-624-3909 Toll Free. 888-624-3910 -----Original Message----- From: Mike Walter [mailto:mwalter at 3z.net] Sent: Thursday, June 19, 2008 11:48 AM To: Peter Pauly; Nanog Mailing list Subject: RE: Level 3 / Time Warner problem in Columbus OH? Just spoke with TW Telecom on my ticket. They have (2) OC-192s down in the Ohio area. They have open troubles with their vendor. Seems odd that both are down according to the rep I spoke with. We have shut down our TW Telecom BGP session until resolved due to high latency. Mike Walter, MCP Systems Administrator 3z.net -----Original Message----- From: Peter Pauly [mailto:ppauly at gmail.com] Sent: Thursday, June 19, 2008 11:43 AM To: Nanog Mailing list Subject: Level 3 / Time Warner problem in Columbus OH? Time Warner is reporting to me that their provider, Level 3 is having problems in Columbus OH that is affecting several large midwest cities. Anyone have more details? From tims at donet.com Thu Jun 19 11:18:52 2008 From: tims at donet.com (Tim Sanderson) Date: Thu, 19 Jun 2008 12:18:52 -0400 Subject: Level 3 / Time Warner problem in Ohio In-Reply-To: References: Message-ID: Same. Also shut down peering with TWC. We have confirmation from some local technicians that an OC-192 is down between Columbus, OH and Ashburton, VA... and an OC-192 down between Indianapolis and Chicago. Another tech that I spoke to said it was a problem between Ohio and NYC. That is causing major problems all over Ohio. www.donet.com (Dayton Ohio ISP) -- Tim Sanderson, network administrator tims at donet.com -----Original Message----- From: Steve Searles [mailto:steve at zimcom.net] Sent: Thursday, June 19, 2008 12:15 PM To: 'Mike Walter'; Peter Pauly; Nanog Mailing list Subject: RE: Level 3 / Time Warner problem in Columbus OH? Same here, we have also shut down our TWT peer. Steve Searles Sr. Network Engineer Zimmerman Communications Inc. http://www.zimcom.net Phone. 513-624-3900 Fax. 513-624-3909 Toll Free. 888-624-3910 -----Original Message----- From: Mike Walter [mailto:mwalter at 3z.net] Sent: Thursday, June 19, 2008 11:48 AM To: Peter Pauly; Nanog Mailing list Subject: RE: Level 3 / Time Warner problem in Columbus OH? Just spoke with TW Telecom on my ticket. They have (2) OC-192s down in the Ohio area. They have open troubles with their vendor. Seems odd that both are down according to the rep I spoke with. We have shut down our TW Telecom BGP session until resolved due to high latency. Mike Walter, MCP Systems Administrator 3z.net -----Original Message----- From: Peter Pauly [mailto:ppauly at gmail.com] Sent: Thursday, June 19, 2008 11:43 AM To: Nanog Mailing list Subject: Level 3 / Time Warner problem in Columbus OH? Time Warner is reporting to me that their provider, Level 3 is having problems in Columbus OH that is affecting several large midwest cities. Anyone have more details? From gdt at gdt.id.au Thu Jun 19 11:19:33 2008 From: gdt at gdt.id.au (Glen Turner) Date: Fri, 20 Jun 2008 01:49:33 +0930 Subject: Cable Colors - A Standard In-Reply-To: References: <200806170326.m5H3QfwE071681@aurora.sol.net> <20080617035800.GC30714@cgi.jachomes.com> Message-ID: <485A8715.9060004@gdt.id.au> George Imburgia wrote: > There's a standard; > ANSI/TIA/EIA 606A > http://www.flexcomm.com/library/606aguide.pdf Here in Australia there's no standard for colours of data communications patch cables. But there are some non-data communications standards for fixed cable colours. In particular, fire system sensors must use red; the use of cream is reserved for telephony; and fixed electrical cables must be white. To minimise error I avoid those colours for patch cables (ie, non-fixed cables). This is prudent anyway, as under the Wiring Rules simply tying down a patch lead with a cable tie is enough to turn it into a fixed cable. I've found that it's more important to have a ready supply of cable lengths (say 0.5m increments) and labels than to have colours. That avoids a mess developing in the first place that might need colour coding to sort out. We use blue, simply because it's the most readily available colour. The only cable which really needs a special colour is one which doesn't connect all eight pins in sequence. To avoid stocking many lengths of cross-over cables, we use a 0.6m crossover cable and a Cat6 joiner. We colour these pink -- it's noticeable and Real Men sysadmins don't steal them. A useful tool is a audio cable tracer. When disconnecting a PC you attach the signal injector. You then use the other half of the tool to identify the cable (it buzzes when near). This allows the patch cables to be pulled with certainty rather than left in the rack just in case it attached to some other host and you fear causing an unplanned outage. Also I've found that many cabling messes occur because the installer had no alternative. There was simply no cableway that wasn't congested. For high-density routers I've found that about 1/3rd of the rack is given over to cable patch panels and ring runs. About two racks in ten (ie, one optical, one UTP) need to be given over to just inter-rack patching and I'd encourage a specialist-built patch rack for that purpose. A rack full of PCs requires about 0.8m of available tray down the side of the rack to tie down the patch leads and other cables. Again, that huge amount of tray isn't usually provided, can't be added afterwards, and the installer has no choice but to do poor work if there's nothing to tie cables to. We ban non-fixed cabling between our racks, which means that patch cables only run within a rack. This simplifies things considerably. Fortunately, we've got the fiber density to racks to justify that design. I've noticed a considerable fall in the price of pre-assembled optical patch panels, so it's well worth looking at the prices even at low densities of cables to see if they fallen enough to make a fixed cabling system worthwhile. It's not like alternative -- those gutters used to pull optical patch leads between racks -- are cheap so I've expect the prices to cross at some stage in the next few years. Cheers, glen From cgrundemann at gmail.com Thu Jun 19 13:23:07 2008 From: cgrundemann at gmail.com (Chris Grundemann) Date: Thu, 19 Jun 2008 12:23:07 -0600 Subject: Level 3 / Time Warner problem in Ohio In-Reply-To: References: Message-ID: <443de7ad0806191123s382a7034o58969d0c0957e50a@mail.gmail.com> My sources report that both OC-192 circuits in Time Warner's backbone have recovered. I see no packet loss or latency across their network now. ~Chris On Thu, Jun 19, 2008 at 10:18 AM, Tim Sanderson wrote: > Same. Also shut down peering with TWC. > > We have confirmation from some local technicians that an OC-192 is down between Columbus, OH and Ashburton, VA... and an OC-192 down between Indianapolis and Chicago. Another tech that I spoke to said it was a problem between Ohio and NYC. That is causing major problems all over Ohio. > > www.donet.com (Dayton Ohio ISP) > > -- > Tim Sanderson, network administrator > tims at donet.com > > > -----Original Message----- > From: Steve Searles [mailto:steve at zimcom.net] > Sent: Thursday, June 19, 2008 12:15 PM > To: 'Mike Walter'; Peter Pauly; Nanog Mailing list > Subject: RE: Level 3 / Time Warner problem in Columbus OH? > > Same here, we have also shut down our TWT peer. > > > Steve Searles > Sr. Network Engineer > Zimmerman Communications Inc. > http://www.zimcom.net > Phone. 513-624-3900 > Fax. 513-624-3909 > Toll Free. 888-624-3910 > > -----Original Message----- > From: Mike Walter [mailto:mwalter at 3z.net] > Sent: Thursday, June 19, 2008 11:48 AM > To: Peter Pauly; Nanog Mailing list > Subject: RE: Level 3 / Time Warner problem in Columbus OH? > > Just spoke with TW Telecom on my ticket. They have (2) OC-192s down in > the Ohio area. They have open troubles with their vendor. Seems odd > that both are down according to the rep I spoke with. We have shut down > our TW Telecom BGP session until resolved due to high latency. > > Mike Walter, MCP > Systems Administrator > 3z.net > > > -----Original Message----- > From: Peter Pauly [mailto:ppauly at gmail.com] > Sent: Thursday, June 19, 2008 11:43 AM > To: Nanog Mailing list > Subject: Level 3 / Time Warner problem in Columbus OH? > > Time Warner is reporting to me that their provider, Level 3 is having > problems in Columbus OH that is affecting several large midwest > cities. Anyone have more details? > > > > > -- Chris Grundemann From source_route at yahoo.com Thu Jun 19 17:53:24 2008 From: source_route at yahoo.com (Philip Lavine) Date: Thu, 19 Jun 2008 15:53:24 -0700 (PDT) Subject: YIPES outage in San Diego? Message-ID: <312140.59966.qm@web30802.mail.mud.yahoo.com> From nanog at daork.net Thu Jun 19 19:50:41 2008 From: nanog at daork.net (Nathan Ward) Date: Fri, 20 Jun 2008 12:50:41 +1200 Subject: Cable Colors - A Standard In-Reply-To: <485A8715.9060004@gdt.id.au> References: <200806170326.m5H3QfwE071681@aurora.sol.net> <20080617035800.GC30714@cgi.jachomes.com> <485A8715.9060004@gdt.id.au> Message-ID: <84C1D04C-0AA6-47F0-9A14-1D1097685575@daork.net> On 20/06/2008, at 4:19 AM, Glen Turner wrote: > A useful tool is a audio cable tracer. When disconnecting > a PC you attach the signal injector. You then use the other > half of the tool to identify the cable (it buzzes when near). > This allows the patch cables to be pulled with certainty > rather than left in the rack just in case it attached to some > other host and you fear causing an unplanned outage. You whack on one of these things when there's still active gear on the end? -- Nathan Ward From jackson.tim at gmail.com Thu Jun 19 20:45:50 2008 From: jackson.tim at gmail.com (Tim Jackson) Date: Thu, 19 Jun 2008 20:45:50 -0500 Subject: Cable Colors - A Standard In-Reply-To: <84C1D04C-0AA6-47F0-9A14-1D1097685575@daork.net> References: <200806170326.m5H3QfwE071681@aurora.sol.net> <20080617035800.GC30714@cgi.jachomes.com> <485A8715.9060004@gdt.id.au> <84C1D04C-0AA6-47F0-9A14-1D1097685575@daork.net> Message-ID: <4407932e0806191845o5d6bef96x2a98401cc8c20cb@mail.gmail.com> This one is plenty safe to stick on a live cable, plus it works a whole lot better than the old analog ones: http://www.flukenetworks.com/fnet/en-us/products/IntelliTone+Toner+and+Probe/Overview.htm?categorycode=CPTT -- Tim On Thu, Jun 19, 2008 at 7:50 PM, Nathan Ward wrote: > On 20/06/2008, at 4:19 AM, Glen Turner wrote: > >> A useful tool is a audio cable tracer. When disconnecting >> a PC you attach the signal injector. You then use the other >> half of the tool to identify the cable (it buzzes when near). >> This allows the patch cables to be pulled with certainty >> rather than left in the rack just in case it attached to some >> other host and you fear causing an unplanned outage. >> > > > You whack on one of these things when there's still active gear on the end? > > -- > Nathan Ward > > > > > > From cidr-report at potaroo.net Fri Jun 20 07:00:04 2008 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 20 Jun 2008 22:00:04 +1000 (EST) Subject: BGP Update Report Message-ID: <200806201200.m5KC04mC077280@wattle.apnic.net> BGP Update Report Interval: 19-May-08 -to- 19-Jun-08 (32 days) Observation Point: BGP Peering with AS2.0 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS15169 172069 2.6% 1274.6 -- GOOGLE - Google Inc. 2 - AS4538 146961 2.2% 29.6 -- ERX-CERNET-BKB China Education and Research Network Center 3 - AS6140 76831 1.1% 84.1 -- IMPSAT-USA - ImpSat USA, Inc. 4 - AS5691 75542 1.1% 5810.9 -- MITRE-AS-5 - The MITRE Corporation 5 - AS8866 62879 0.9% 196.5 -- BTC-AS Bulgarian Telecommunication Company Plc. 6 - AS17974 59601 0.9% 101.2 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia 7 - AS9583 57591 0.9% 47.9 -- SIFY-AS-IN Sify Limited 8 - AS42787 46540 0.7% 15513.3 -- MMIP-AS MultiMedia IP Ltd. 9 - AS9198 44400 0.7% 86.7 -- KAZTELECOM-AS Kazakhtelecom Corporate Sales Administration 10 - AS31003 31653 0.5% 4521.9 -- IRON-MOUNTAIN-UK-AS Iron Mountain UK Ltd 11 - AS18231 30617 0.5% 130.8 -- EXATT-AS-AP IOL NETCOM LTD 12 - AS15611 29249 0.4% 298.5 -- Iranian Research Organization for Science & Technology 13 - AS21565 29103 0.4% 159.0 -- HTCC - HTC Communications, LLC 14 - AS23966 28415 0.4% 83.3 -- DANCOM-AS-AP LINKdotNET Pakistan 15 - AS6471 27411 0.4% 65.3 -- ENTEL CHILE S.A. 16 - AS8151 26791 0.4% 21.3 -- Uninet S.A. de C.V. 17 - AS6568 25638 0.4% 226.9 -- Ag para el Desarrollo de la Sociedad de la Inf en Bolivia - ADSIB 18 - AS702 24560 0.4% 44.8 -- AS702 Verizon Business EMEA - Commercial IP service provider in Europe 19 - AS14522 23373 0.3% 118.6 -- Satnet 20 - AS47212 23363 0.3% 2123.9 -- UGD-AS University "Goce Delcev" TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS17834 19962 0.3% 19962.0 -- KYOBOAUTO-AS-KR Kyobo Auto Insurance CO.,LTD 2 - AS42787 46540 0.7% 15513.3 -- MMIP-AS MultiMedia IP Ltd. 3 - AS9988 8692 0.1% 8692.0 -- MPT-AP Myanma Post and Telecommunication 4 - AS29910 6032 0.1% 6032.0 -- IACP - INTL. ASSN OF CHIEF OF POLICEI 5 - AS5691 75542 1.1% 5810.9 -- MITRE-AS-5 - The MITRE Corporation 6 - AS36384 16646 0.2% 5548.7 -- GOOGLE-IT - Google Incorporated 7 - AS38513 4617 0.1% 4617.0 -- LINTASARTA-AS-ID PT Aplikanusa Lintasarta 8 - AS31003 31653 0.5% 4521.9 -- IRON-MOUNTAIN-UK-AS Iron Mountain UK Ltd 9 - AS30287 4370 0.1% 4370.0 -- ALON-USA - ALON USA, LP 10 - AS23082 18626 0.3% 3725.2 -- MPHI - Michigan Public Health Institute 11 - AS30929 3488 0.1% 3488.0 -- HUTCB Hidrotechnical Faculty - Technical University 12 - AS13620 16292 0.2% 3258.4 -- ASN-ELAN - Elan Communications, Inc. 13 - AS39105 2822 0.0% 2822.0 -- CLASS-AS SC Class Computers And Service SRL 14 - AS38069 22372 0.3% 2485.8 -- WARIDTEL-BD-AS-AP Warid Telecom 15 - AS25250 7397 0.1% 2465.7 -- GAMTEL-AS 16 - AS25799 2404 0.0% 2404.0 -- HOLMAN - Holman Enterprises 17 - AS47212 23363 0.3% 2123.9 -- UGD-AS University "Goce Delcev" 18 - AS9747 12660 0.2% 1582.5 -- EZINTERNET-AS-AP EZInternet Pty Ltd 19 - AS26829 1566 0.0% 1566.0 -- YKK-USA - YKK USA,INC 20 - AS38165 14810 0.2% 1481.0 -- ADSNET-AS-ID PT. AMBHARA DUTA SHANTI TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 192.12.120.0/24 75241 1.1% AS5691 -- MITRE-AS-5 - The MITRE Corporation 2 - 193.33.184.0/23 46492 0.7% AS42787 -- MMIP-AS MultiMedia IP Ltd. 3 - 213.91.175.0/24 37383 0.5% AS8866 -- BTC-AS Bulgarian Telecommunication Company Plc. 4 - 193.239.114.0/24 27113 0.4% AS31003 -- IRON-MOUNTAIN-UK-AS Iron Mountain UK Ltd 5 - 221.128.192.0/18 26773 0.4% AS18231 -- EXATT-AS-AP IOL NETCOM LTD 6 - 84.23.102.0/24 22216 0.3% AS24731 -- ASN-NESMA National Engineering Services and Marketing Company Ltd. (NESMA) AS34400 -- ASN-ETTIHADETISALAT Etihad Etisalat 7 - 221.135.230.0/23 21489 0.3% AS9583 -- SIFY-AS-IN Sify Limited 8 - 210.92.148.0/24 19962 0.3% AS17834 -- KYOBOAUTO-AS-KR Kyobo Auto Insurance CO.,LTD 9 - 83.228.71.0/24 16059 0.2% AS8866 -- BTC-AS Bulgarian Telecommunication Company Plc. AS8953 -- ASN-ORANGE-ROMANIA Orange Romania Autonomous System Number 10 - 24.121.123.0/24 13805 0.2% AS25994 -- NPG-001 - NPG Cable, INC 11 - 203.63.26.0/24 12646 0.2% AS9747 -- EZINTERNET-AS-AP EZInternet Pty Ltd 12 - 210.214.88.0/23 9425 0.1% AS9583 -- SIFY-AS-IN Sify Limited 13 - 203.81.64.0/19 8692 0.1% AS9988 -- MPT-AP Myanma Post and Telecommunication 14 - 192.166.49.0/24 7903 0.1% AS3320 -- DTAG Deutsche Telekom AG 15 - 125.23.208.0/20 7093 0.1% AS9498 -- BBIL-AP BHARTI BT INTERNET LTD. 16 - 203.101.87.0/24 6291 0.1% AS9498 -- BBIL-AP BHARTI BT INTERNET LTD. 17 - 208.83.117.0/24 6178 0.1% AS23082 -- MPHI - Michigan Public Health Institute 18 - 208.83.118.0/24 6164 0.1% AS23082 -- MPHI - Michigan Public Health Institute 19 - 208.83.119.0/24 6151 0.1% AS23082 -- MPHI - Michigan Public Health Institute 20 - 149.117.166.0/24 6117 0.1% AS701 -- UUNET - MCI Communications Services, Inc. d/b/a Verizon Business Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at merit.edu eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From cidr-report at potaroo.net Fri Jun 20 07:00:02 2008 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 20 Jun 2008 22:00:02 +1000 (EST) Subject: The Cidr Report Message-ID: <200806201200.m5KC02Kl077263@wattle.apnic.net> This report has been generated at Fri Jun 20 21:14:56 2008 AEST. The report analyses the BGP Routing Table of AS2.0 router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org for a current version of this report. Recent Table History Date Prefixes CIDR Agg 13-06-08 271485 169907 14-06-08 271821 168435 15-06-08 272067 168701 16-06-08 272099 169179 17-06-08 272070 168603 18-06-08 270608 167742 19-06-08 270477 167948 20-06-08 270490 168547 AS Summary 28643 Number of ASes in routing system 12111 Number of ASes announcing only one prefix 4923 Largest number of prefixes announced by an AS AS4538 : ERX-CERNET-BKB China Education and Research Network Center 88347904 Largest address span announced by an AS (/32s) AS721 : DISA-ASNBLK - DoD Network Information Center Aggregation Summary The algorithm used in this report proposes aggregation only when there is a precise match using the AS path, so as to preserve traffic transit policies. Aggregation is also proposed across non-advertised address space ('holes'). --- 20Jun08 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 270510 168401 102109 37.7% All ASes AS4538 4923 875 4048 82.2% ERX-CERNET-BKB China Education and Research Network Center AS209 3030 671 2359 77.9% ASN-QWEST - Qwest AS6389 2443 553 1890 77.4% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS4755 1649 237 1412 85.6% VSNL-AS Videsh Sanchar Nigam Ltd. Autonomous System AS9498 1182 78 1104 93.4% BBIL-AP BHARTI BT INTERNET LTD. AS18566 1045 42 1003 96.0% COVAD - Covad Communications Co. AS22773 963 66 897 93.1% CCINET-2 - Cox Communications Inc. AS4323 1460 664 796 54.5% TWTC - Time Warner Telecom, Inc. AS8151 1246 488 758 60.8% Uninet S.A. de C.V. AS17488 1140 386 754 66.1% HATHWAY-NET-AP Hathway IP Over Cable Internet AS11492 1229 481 748 60.9% CABLEONE - CABLE ONE AS19262 915 173 742 81.1% VZGNI-TRANSIT - Verizon Internet Services Inc. AS1785 1075 359 716 66.6% AS-PAETEC-NET - PaeTec Communications, Inc. AS2386 1496 890 606 40.5% INS-AS - AT&T Data Communications Services AS6478 957 419 538 56.2% ATT-INTERNET3 - AT&T WorldNet Services AS18101 693 165 528 76.2% RIL-IDC Reliance Infocom Ltd Internet Data Centre, AS4766 873 395 478 54.8% KIXS-AS-KR Korea Telecom AS855 602 131 471 78.2% CANET-ASN-4 - Bell Aliant AS6197 951 485 466 49.0% BATI-ATL - BellSouth Network Solutions, Inc AS17676 525 82 443 84.4% GIGAINFRA BB TECHNOLOGY Corp. AS7018 1420 998 422 29.7% ATT-INTERNET4 - AT&T WorldNet Services AS4134 825 406 419 50.8% CHINANET-BACKBONE No.31,Jin-rong Street AS4668 679 271 408 60.1% LGNET-AS-KR LG CNS AS22047 565 159 406 71.9% VTR BANDA ANCHA S.A. AS9443 488 84 404 82.8% INTERNETPRIMUS-AS-AP Primus Telecommunications AS7011 1026 634 392 38.2% FRONTIER-AND-CITIZENS - Frontier Communications of America, Inc. AS3602 456 79 377 82.7% AS3602-RTI - Rogers Telecom Inc. AS4808 521 159 362 69.5% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS16814 426 67 359 84.3% NSS S.A. AS4804 430 79 351 81.6% MPX-AS Microplex PTY LTD Total 35233 10576 24657 70.0% Top 30 total Possible Bogus Routes 24.38.0.0/17 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 24.48.0.0/13 AS19548 ADELPHIA-AS2 - Road Runner HoldCo LLC 24.48.244.0/23 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 24.51.159.0/24 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 24.54.224.0/19 AS20001 ROADRUNNER-WEST - Road Runner HoldCo LLC 24.75.160.0/19 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 24.75.192.0/18 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 24.142.40.0/21 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 24.142.160.0/19 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 24.246.0.0/17 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 24.246.128.0/18 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV - Wireless Broadband via Satellite 63.140.213.0/24 AS22555 UTC - Universal Talkware Corporation 63.141.42.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 63.143.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 63.143.115.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 63.143.251.0/24 AS22555 UTC - Universal Talkware Corporation 63.248.0.0/16 AS3356 LEVEL3 Level 3 Communications 64.7.112.0/21 AS6453 GLOBEINTERNET TATA Communications 64.7.120.0/21 AS6453 GLOBEINTERNET TATA Communications 64.50.128.0/18 AS4565 MEGAPATH2-US - MegaPath Networks Inc. 64.64.159.0/24 AS32004 BIG-ASN - Business Information Group, Inc. 64.144.0.0/15 AS4565 MEGAPATH2-US - MegaPath Networks Inc. 64.188.0.0/16 AS3356 LEVEL3 Level 3 Communications 65.36.8.0/24 AS5696 65.36.9.0/24 AS5696 65.36.33.0/24 AS5696 65.36.52.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 66.11.32.0/20 AS6261 VISINET - Visionary Systems, Inc. 66.11.40.0/21 AS6261 VISINET - Visionary Systems, Inc. 66.54.91.0/24 AS30506 BLACKSUN-1 - Blacksun Technologies LLC 66.55.160.0/19 AS29994 66.64.96.0/20 AS3790 RADIGRAFICA COSTARRICENSE 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.199.32.0/20 AS10397 WISP-AS - Wispnet, LLC 66.206.32.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.33.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.34.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.35.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.40.0/22 AS174 COGENT Cogent/PSI 66.206.44.0/23 AS174 COGENT Cogent/PSI 66.206.47.0/24 AS17557 PKTELECOM-AS-AP Pakistan Telecom 66.207.32.0/20 AS23011 66.219.192.0/18 AS5048 FIBER - FIBERNET Corp. 67.20.0.0/14 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 68.64.0.0/13 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 68.168.0.0/14 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 68.232.0.0/14 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 69.71.192.0/20 AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport 69.80.0.0/17 AS3043 AMPHIB-AS - Amphibian Media Corporation 69.164.0.0/17 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 70.34.0.0/16 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 80.88.0.0/21 AS33774 DJAWEB 80.88.8.0/22 AS33774 DJAWEB 80.88.10.0/24 AS33774 DJAWEB 80.88.11.0/24 AS33774 DJAWEB 80.88.12.0/24 AS33779 wataniya-telecom-as 95.192.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 95.255.248.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 137.0.0.0/13 AS721 DISA-ASNBLK - DoD Network Information Center 151.135.0.0/16 AS4768 CLIX-NZ TelstraClear Ltd 159.3.211.0/24 AS2687 ASATTCA AT&T Global Network Services - AP 163.142.0.0/16 AS2500 WIDE-BB WIDE Project 166.63.0.0/16 AS33775 NITEL-AS 172.7.0.0/24 AS28175 172.10.1.0/30 AS18305 POSNET POSDATA Co.,Ltd 192.9.200.0/24 AS3602 AS3602-RTI - Rogers Telecom Inc. 192.30.93.0/24 AS17757 HPAUS-AP HP Australia 192.30.94.0/24 AS17757 HPAUS-AP HP Australia 192.40.105.0/24 AS12582 TSF-DATANET-NGD-AS TSF MPLS VPN Services 192.64.85.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.107.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.108.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.177.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.70.164.0/24 AS25689 NRCNET-AS - National Research Council of Canada 192.96.36.0/24 AS5713 SAIX-NET 192.96.37.0/24 AS10474 NETACTIVE 192.96.135.0/24 AS2018 TENET-1 192.96.136.0/23 AS2018 TENET-1 192.96.141.0/24 AS5713 SAIX-NET 192.96.143.0/24 AS2018 TENET-1 192.96.145.0/24 AS2018 TENET-1 192.96.177.0/24 AS6083 POSIX-AFRICA 192.101.45.0/24 AS2905 TICSA-ASN 192.101.46.0/24 AS6503 Avantel, S.A. 192.101.47.0/24 AS6503 Avantel, S.A. 192.101.64.0/21 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.67.0/24 AS21775 192.101.70.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.72.0/24 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.73.0/24 AS4765 WORLDNET-AS World Net & Services Co., Ltd. 192.101.74.0/24 AS1239 SPRINTLINK - Sprint 192.122.212.0/24 AS209 ASN-QWEST - Qwest 192.124.252.0/22 AS680 DFN-IP service G-WiN 192.131.233.0/24 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 192.133.6.0/24 AS10282 EQUANT-CEEUR EQUANT AS for Central and Eastern Europe region 192.153.144.0/21 AS721 DISA-ASNBLK - DoD Network Information Center 192.154.32.0/19 AS81 NCREN - MCNC 192.188.208.0/20 AS721 DISA-ASNBLK - DoD Network Information Center 193.200.114.0/23 AS31530 SERVERCREW-AS Servercrew LTD Autonomes System 194.31.227.0/24 AS21461 TRANSFAIRNET Transfair-net GmbH Krefeld 194.246.72.0/23 AS8893 ARTFILES-AS Artfiles New Media GmbH 196.6.108.0/24 AS5713 SAIX-NET 196.10.119.0/24 AS2018 TENET-1 196.10.122.0/23 AS2018 TENET-1 196.10.251.0/24 AS2018 TENET-1 196.10.252.0/23 AS2018 TENET-1 196.10.254.0/24 AS2018 TENET-1 196.13.101.0/24 AS2018 TENET-1 196.13.102.0/23 AS2018 TENET-1 196.13.104.0/24 AS2018 TENET-1 196.13.121.0/24 AS2018 TENET-1 196.13.125.0/24 AS2018 TENET-1 196.13.126.0/24 AS2018 TENET-1 196.13.169.0/24 AS2018 TENET-1 196.13.174.0/23 AS2018 TENET-1 196.13.176.0/21 AS2018 TENET-1 196.13.192.0/22 AS2018 TENET-1 196.13.196.0/24 AS2018 TENET-1 196.201.98.0/24 AS29571 CITelecom-AS 196.216.132.0/24 AS9207 TAIDE-KE-NAIROBI Taide - Kenya POP 196.216.134.0/24 AS9207 TAIDE-KE-NAIROBI Taide - Kenya POP 198.23.26.0/24 AS4390 BELLATLANTIC-COM - Bell Atlantic, Inc. 198.54.82.0/24 AS2018 TENET-1 198.54.92.0/24 AS2018 TENET-1 198.54.222.0/24 AS2018 TENET-1 198.97.72.0/21 AS721 DISA-ASNBLK - DoD Network Information Center 198.97.80.0/20 AS721 DISA-ASNBLK - DoD Network Information Center 198.97.96.0/19 AS721 DISA-ASNBLK - DoD Network Information Center 198.97.240.0/20 AS721 DISA-ASNBLK - DoD Network Information Center 198.144.96.0/20 AS12185 198.161.87.0/24 AS6539 GT-BELL - Bell Canada 198.167.0.0/16 AS7456 INTERHOP - Interhop Network SERVICES Inc. 198.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 198.169.0.0/16 AS803 SASKTEL - Saskatchewan Telecommunications 198.180.198.0/24 AS23715 SEOUL-INTGW-GXS-AP Global Exchange Services 199.9.128.0/17 AS668 ASN-ASNET-NET-AS - Defense Research and Engineering Network 199.10.0.0/16 AS721 DISA-ASNBLK - DoD Network Information Center 199.114.0.0/21 AS721 DISA-ASNBLK - DoD Network Information Center 199.114.128.0/18 AS721 DISA-ASNBLK - DoD Network Information Center 199.114.130.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.131.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.132.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.134.0/24 AS3541 ITSDN-U4 - DoD Network Information Center 199.114.136.0/24 AS27044 DDN-ASNBLK1 - DoD Network Information Center 199.114.138.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.140.0/24 AS3544 ITSDN-U7 - DoD Network Information Center 199.114.142.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.144.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.148.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.150.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.152.0/24 AS27033 DDN-ASNBLK1 - DoD Network Information Center 199.114.153.0/24 AS27034 DDN-ASNBLK1 - DoD Network Information Center 199.114.154.0/24 AS1733 CENTAF-SWA - AF DDN PMO 199.114.156.0/24 AS1733 CENTAF-SWA - AF DDN PMO 199.114.160.0/24 AS1733 CENTAF-SWA - AF DDN PMO 199.121.0.0/16 AS721 DISA-ASNBLK - DoD Network Information Center 199.123.0.0/18 AS721 DISA-ASNBLK - DoD Network Information Center 199.123.16.0/20 AS721 DISA-ASNBLK - DoD Network Information Center 199.123.80.0/21 AS721 DISA-ASNBLK - DoD Network Information Center 199.189.32.0/19 AS7332 IQUEST-AS - IQuest Internet 199.202.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 199.246.116.0/24 AS813 UUNET-CANADA - MCI Communications Services, Inc. d/b/a Verizon Business 202.58.113.0/24 AS19161 INNOCOM-TELECOM - INNOCOM TELECOM 202.73.144.0/20 AS4788 TMNET-AS-AP TM Net, Internet Service Provider 202.80.192.0/20 AS2706 HKSUPER-HK-AP Pacific Internet (Hong Kong) Limited 202.86.252.0/22 AS4748 RESOLINK-AS-AP Resources Link Network Limited 202.86.252.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.253.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.254.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.255.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.90.33.0/24 AS9830 SWIFTONLINE-AS-AP SWIFT ONLINE BORDER AS 202.90.40.0/24 AS9830 SWIFTONLINE-AS-AP SWIFT ONLINE BORDER AS 202.90.41.0/24 AS9830 SWIFTONLINE-AS-AP SWIFT ONLINE BORDER AS 202.90.42.0/24 AS9830 SWIFTONLINE-AS-AP SWIFT ONLINE BORDER AS 202.90.43.0/24 AS9830 SWIFTONLINE-AS-AP SWIFT ONLINE BORDER AS 202.90.44.0/24 AS9830 SWIFTONLINE-AS-AP SWIFT ONLINE BORDER AS 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.94.70.0/24 AS9837 POWERTEL-AP Powertel Ltd 202.124.195.0/24 AS17557 PKTELECOM-AS-AP Pakistan Telecom 202.124.207.0/24 AS17911 BRAINPK-AS-AP Brain Telecommunication Ltd. 202.136.254.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.136.255.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.164.100.0/24 AS18101 RIL-IDC Reliance Infocom Ltd Internet Data Centre, 202.176.228.0/24 AS17988 SINOSAT-AS-AP SINOSAT (HONG KONG) LIMITED 202.176.232.0/24 AS17988 SINOSAT-AS-AP SINOSAT (HONG KONG) LIMITED 202.181.32.0/24 AS4645 ASN-HKNET-AP HKNet Co. Ltd 203.12.45.0/24 AS4854 NETSPACE-AS-AP Netspace Online Systems 203.62.0.0/17 AS7575 AARNET-AS-AP Australian Academic and Reasearch Network (AARNet) 203.78.48.0/20 AS9299 IPG-AS-AP Philippine Long Distance Telephone Company 203.89.139.0/24 AS17911 BRAINPK-AS-AP Brain Telecommunication Ltd. 203.111.192.0/20 AS7473 SINGTEL-AS-AP Singapore Telecom 203.112.97.0/24 AS9942 COMINDICO-AP SOUL Converged Communications Australia 203.112.111.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.113.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.114.0/24 AS4802 ASN-IINET iiNet Limited 203.112.116.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.117.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.118.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.119.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.120.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.121.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.127.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.128.128.0/19 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 203.128.128.0/24 AS23849 CNNIC-NET263-AP Beijing Capital-online science development Co.,Ltd. 203.152.136.0/23 AS23649 NEWSKIES-AS-AP New Skies Satellites, Hong Kong Teleport 203.152.138.0/23 AS23649 NEWSKIES-AS-AP New Skies Satellites, Hong Kong Teleport 203.152.142.0/24 AS23649 NEWSKIES-AS-AP New Skies Satellites, Hong Kong Teleport 203.152.143.0/24 AS23649 NEWSKIES-AS-AP New Skies Satellites, Hong Kong Teleport 203.160.110.0/23 AS7643 VNN-AS-AP Vietnam Posts and Telecommunications (VNPT) 204.9.216.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.9.217.0/24 AS4323 TWTC - Time Warner Telecom, Inc. 204.9.218.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.13.140.0/22 AS7270 NET2PHONE - Net2Phone Corp. 204.16.120.0/23 AS12077 204.16.122.0/23 AS12077 204.19.14.0/23 AS577 BACOM - Bell Canada 204.29.196.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 204.29.197.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 204.48.58.0/24 AS4323 TWTC - Time Warner Telecom, Inc. 204.48.60.0/24 AS4323 TWTC - Time Warner Telecom, Inc. 204.154.125.0/24 AS3952 TELLABS-ASN - TELLABS Operations, Inc. 204.154.126.0/24 AS3952 TELLABS-ASN - TELLABS Operations, Inc. 204.154.127.0/24 AS3952 TELLABS-ASN - TELLABS Operations, Inc. 205.150.0.0/15 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 206.162.224.0/19 AS23464 ILCSNET - Interlink Computer Services 206.180.240.0/20 AS12083 KNOLOGY-NET - Knology Holdings 206.220.240.0/24 AS10764 STARTAP - National Center for Supercomputing Applications 206.220.240.64/26 AS22335 MREN - Metropolitan Research and Education Network 206.220.240.128/25 AS10764 STARTAP - National Center for Supercomputing Applications 206.220.240.160/30 AS10764 STARTAP - National Center for Supercomputing Applications 206.220.240.220/32 AS10764 STARTAP - National Center for Supercomputing Applications 206.220.241.0/24 AS10764 STARTAP - National Center for Supercomputing Applications 207.98.192.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 207.98.209.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 207.98.223.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 207.191.128.0/19 AS10887 BPSI-AS - BPSI Internet Services 207.204.168.0/24 AS15150 BELLTECH-AS - BELLWETHER TECHNOLOGY CORPORATION 207.204.222.0/24 AS22773 CCINET-2 - Cox Communications Inc. 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc. 208.38.192.0/18 AS3043 AMPHIB-AS - Amphibian Media Corporation 208.38.192.0/21 AS14237 BEAMSPEED1 - Beamspeed 208.38.202.0/24 AS14237 BEAMSPEED1 - Beamspeed 208.38.203.0/24 AS14237 BEAMSPEED1 - Beamspeed 208.38.204.0/22 AS14237 BEAMSPEED1 - Beamspeed 209.54.93.0/24 AS22773 CCINET-2 - Cox Communications Inc. 209.54.111.0/24 AS22773 CCINET-2 - Cox Communications Inc. 209.54.123.0/24 AS6062 NETPLEX - NETPLEX 209.54.240.0/21 AS10887 BPSI-AS - BPSI Internet Services 209.105.224.0/19 AS20074 209.140.90.0/24 AS14461 NTSL - NET SOLUTIONS 209.140.224.0/21 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.234.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.235.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.236.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.237.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.238.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.239.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.141.16.0/21 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.141.48.0/22 AS14461 NTSL - NET SOLUTIONS 209.145.192.0/18 AS3043 AMPHIB-AS - Amphibian Media Corporation 209.145.204.0/22 AS14237 BEAMSPEED1 - Beamspeed 210.5.128.0/20 AS4837 CHINA169-BACKBONE CNCGROUP China169 Backbone 213.150.192.0/21 AS29571 CITelecom-AS 213.150.200.0/22 AS29571 CITelecom-AS 213.150.201.0/24 AS29338 AFOL-AS Used by Africaonline Operations 213.150.202.0/24 AS41042 SKYVISION SkyVision Network Services 216.37.114.0/23 AS3549 GBLX Global Crossing Ltd. 216.37.120.0/23 AS13377 216.59.0.0/17 AS3356 LEVEL3 Level 3 Communications 216.99.16.0/24 AS6395 LVLT-6395 - Level 3 Communications, Inc. 216.99.20.0/24 AS6395 LVLT-6395 - Level 3 Communications, Inc. 216.162.96.0/19 AS7393 CYBERCON - CYBERCON, INC. 216.172.198.0/24 AS22773 CCINET-2 - Cox Communications Inc. 216.172.199.0/24 AS22773 CCINET-2 - Cox Communications Inc. 216.210.86.0/24 AS577 BACOM - Bell Canada 216.235.96.0/19 AS13645 BROADBANDONE - BroadbandONE, Inc. 216.240.240.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 216.240.241.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 216.240.242.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 216.251.207.0/24 AS1239 SPRINTLINK - Sprint 217.78.71.0/24 AS12491 IPPLANET-AS IPPlanet 217.78.72.0/24 AS12491 IPPLANET-AS IPPlanet 217.78.73.0/24 AS12491 IPPLANET-AS IPPlanet Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at merit.edu eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From mike at rockynet.com Fri Jun 20 13:07:01 2008 From: mike at rockynet.com (Mike Lewinski) Date: Fri, 20 Jun 2008 12:07:01 -0600 Subject: Seeking clue @ Cbeyond / ASN17184 and/or other suggestions Message-ID: <485BF1C5.5040807@rockynet.com> We're having some difficulties getting a lame DNS delegation and old email hosting configuration removed from Cbeyond's servers. According to their front line tech support "We cannot work on something we do not host no more". Jared's NOC list doesn't have anything on them, nor do they appear to participate in INOC-DBA. Additional attempts to resolve this are noted below. The specific issues are: 1) lame authority on prosourcedenver.com: $ dig +short ns prosourcedenver.com @beyond.cbeyond.net. beyond.cbeyond.net. infinity.cbeyond.net. to.cbeyond.net. vs: $ dig +short ns prosourcedenver.com @c.gtld-servers.net ns0.rockynet.com. ns1.rockynet.com. ns2.rockynet.com. Front line tech support indicated this is a Registrar problem, and they would open up a ticket with Tucows to get it resolved :( I also tried sending an email to the address in the SOA: $ dig +short soa prosourcedenver.com @beyond.cbeyond.net. prosourcedenver.com. hostmaster.cbeyond.com. 2004042100 86400 1800 604800 3600 $ Unfortunately, that address is invalid :( : host mx2.cbeyond.net[64.238.96.58] said: 550 #5.1.0 Address rejected hostmaster at cbeyond.com (in reply to RCPT TO command) 2) The invalid MX records that Cbeyond is serving resolve to hosts that apparently believe they are authoritative for the prosourcedenver.com domain, and are in effect creating an email blackhole: $ dig +short mx prosourcedenver.com @to.cbeyond.net. 10 mail.west.cbeyond.com. 20 smtp.atl.cbeyond.com. $ telnet mail.west.cbeyond.com smtp Trying 66.180.96.57... Connected to mail.west.cbeyond.com (66.180.96.57). Escape character is '^]'. 220 mail.east.cbeyond.com ESMTP EHLO me 250-mail.east.cbeyond.com 250-8BITMIME 250-SIZE 20971520 250-STARTTLS 250-AUTH PLAIN LOGIN 250 AUTH=PLAIN LOGIN mail from:<> 250 sender <> ok rcpt to: 250 recipient ok ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ rcpt to: 550 #5.1.0 Address rejected anyone at anywhere.com QUIT 221 mail.east.cbeyond.com Connection closed by foreign host. $ Email to postmaster at cbeyond.com hasn't resolved the issue either :( All of the above commands have been sent to their tech support address in an attempt to convince them that the problem is with their servers, but they refuse to accept this. Finally, as an additional note, the whois delegation for their ASN seems to be broken: $ whois -h whois.arin.net 17184 [Querying whois.arin.net] [Redirected to rwhois.cbeyond.net:4321] [Querying rwhois.cbeyond.net] [rwhois.cbeyond.net] %rwhois V-1.5:003eff:00 rwhois.cbeyond.net (by Network Solutions, Inc. V-1.5.9.5) %error 230 No Objects Found $ I'm at a loss of how to proceed now, except to tell people who are suffering from the email blackhole to find another ISP. Does anyone else have any contacts with a clue, or semblance of clue, at Cbeyond? Does anyone have any better ideas for me, short of this lame attempt at public shaming? I won't even get into the issue of what a PITA it is to port DIDs from them.... :( From cscora at apnic.net Fri Jun 20 13:08:02 2008 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 21 Jun 2008 04:08:02 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <200806201808.m5KI82ua021790@thyme.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 21 Jun, 2008 Report Website: http://thyme.apnic.net Detailed Analysis: http://thyme.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 260459 Prefixes after maximum aggregation: 128122 Deaggregation factor: 2.03 Unique aggregates announced to Internet: 126833 Total ASes present in the Internet Routing Table: 28517 Prefixes per ASN: 9.13 Origin-only ASes present in the Internet Routing Table: 24858 Origin ASes announcing only one prefix: 12026 Transit ASes present in the Internet Routing Table: 3659 Transit-only ASes present in the Internet Routing Table: 79 Average AS path length visible in the Internet Routing Table: 3.6 Max AS path length visible: 18 Max AS path prepend of ASN ( 3816) 15 Prefixes from unregistered ASNs in the Routing Table: 618 Unregistered ASNs in the Routing Table: 225 Number of 32-bit ASNs allocated by the RIRs: 47 Prefixes from 32-bit ASNs in the Routing Table: 8 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 777 Number of addresses announced to Internet: 1862946912 Equivalent to 111 /8s, 10 /16s and 80 /24s Percentage of available address space announced: 50.3 Percentage of allocated address space announced: 61.0 Percentage of available address space allocated: 82.3 Percentage of address space in use by end-sites: 72.3 Total number of prefixes smaller than registry allocations: 126692 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 59314 Total APNIC prefixes after maximum aggregation: 22110 APNIC Deaggregation factor: 2.68 Prefixes being announced from the APNIC address blocks: 56332 Unique aggregates announced from the APNIC address blocks: 24955 APNIC Region origin ASes present in the Internet Routing Table: 3277 APNIC Prefixes per ASN: 17.19 APNIC Region origin ASes announcing only one prefix: 873 APNIC Region transit ASes present in the Internet Routing Table: 512 Average APNIC Region AS path length visible: 3.5 Max APNIC Region AS path length visible: 17 Number of APNIC addresses announced to Internet: 356094240 Equivalent to 21 /8s, 57 /16s and 145 /24s Percentage of available APNIC address space announced: 75.8 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079 APNIC Address Blocks 58/8, 59/8, 60/8, 61/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 120010 Total ARIN prefixes after maximum aggregation: 65020 ARIN Deaggregation factor: 1.85 Prefixes being announced from the ARIN address blocks: 89707 Unique aggregates announced from the ARIN address blocks: 34758 ARIN Region origin ASes present in the Internet Routing Table: 12231 ARIN Prefixes per ASN: 7.33 ARIN Region origin ASes announcing only one prefix: 4734 ARIN Region transit ASes present in the Internet Routing Table: 1142 Average ARIN Region AS path length visible: 3.3 Max ARIN Region AS path length visible: 15 Number of ARIN addresses announced to Internet: 356059296 Equivalent to 21 /8s, 57 /16s and 8 /24s Percentage of available ARIN address space announced: 73.2 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 ARIN Address Blocks 24/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 173/8, 174/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 56169 Total RIPE prefixes after maximum aggregation: 34107 RIPE Deaggregation factor: 1.65 Prefixes being announced from the RIPE address blocks: 51378 Unique aggregates announced from the RIPE address blocks: 34372 RIPE Region origin ASes present in the Internet Routing Table: 11510 RIPE Prefixes per ASN: 4.46 RIPE Region origin ASes announcing only one prefix: 6031 RIPE Region transit ASes present in the Internet Routing Table: 1735 Average RIPE Region AS path length visible: 4.0 Max RIPE Region AS path length visible: 18 Number of RIPE addresses announced to Internet: 361394560 Equivalent to 21 /8s, 138 /16s and 113 /24s Percentage of available RIPE address space announced: 82.8 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-48127 RIPE Address Blocks 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 20280 Total LACNIC prefixes after maximum aggregation: 5171 LACNIC Deaggregation factor: 3.92 Prefixes being announced from the LACNIC address blocks: 18502 Unique aggregates announced from the LACNIC address blocks: 10386 LACNIC Region origin ASes present in the Internet Routing Table: 958 LACNIC Prefixes per ASN: 19.31 LACNIC Region origin ASes announcing only one prefix: 310 LACNIC Region transit ASes present in the Internet Routing Table: 162 Average LACNIC Region AS path length visible: 4.1 Max LACNIC Region AS path length visible: 17 Number of LACNIC addresses announced to Internet: 52542464 Equivalent to 3 /8s, 33 /16s and 188 /24s Percentage of available LACNIC address space announced: 52.2 LACNIC AS Blocks 26592-26623, 27648-28671, plus ERX transfers LACNIC Address Blocks 186/8, 187/8, 189/8, 190/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 4071 Total AfriNIC prefixes after maximum aggregation: 1202 AfriNIC Deaggregation factor: 3.39 Prefixes being announced from the AfriNIC address blocks: 4340 Unique aggregates announced from the AfriNIC address blocks: 1891 AfriNIC Region origin ASes present in the Internet Routing Table: 241 AfriNIC Prefixes per ASN: 18.01 AfriNIC Region origin ASes announcing only one prefix: 78 AfriNIC Region transit ASes present in the Internet Routing Table: 48 Average AfriNIC Region AS path length visible: 4.0 Max AfriNIC Region AS path length visible: 15 Number of AfriNIC addresses announced to Internet: 12221440 Equivalent to 0 /8s, 186 /16s and 124 /24s Percentage of available AfriNIC address space announced: 36.4 AfriNIC AS Blocks 36864-37887 & ERX transfers AfriNIC Address Blocks 41/8, 196/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4755 1649 387 89 Videsh Sanchar Nigam Ltd. Aut 9498 1183 550 62 BHARTI BT INTERNET LTD. 17488 1156 80 79 Hathway IP Over Cable Interne 9583 1138 112 415 Sify Limited 4766 846 6006 342 Korea Telecom (KIX) 23577 831 35 706 Korea Telecom (ATM-MPLS) 4134 824 12915 321 CHINANET-BACKBONE 18101 696 168 35 Reliance Infocom Ltd Internet 9829 598 450 12 BSNL National Internet Backbo 1221 551 1919 424 Telstra Pty Ltd Complete listing at http://thyme.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 209 3012 3874 620 Qwest 6389 2446 3138 190 bellsouth.net, inc. 2386 1493 663 874 AT&T Data Communications Serv 4323 1459 1044 376 Time Warner Telecom 7018 1397 5824 977 AT&T WorldNet Services 11492 1229 149 12 Cable One 1785 1077 510 104 AppliedTheory Corporation 18566 1045 296 10 Covad Communications 20115 1042 1064 565 Charter Communications 7011 1026 288 561 Citizens Utilities Complete listing at http://thyme.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 3292 414 1773 372 TDC Tele Danmark 8452 344 188 11 TEDATA 3301 335 1460 305 TeliaNet Sweden 8866 319 77 21 Bulgarian Telecommunication C 3320 316 7045 266 Deutsche Telekom AG 5462 292 666 27 Telewest Broadband 3215 286 2742 89 France Telecom Transpac 8551 283 269 38 Bezeq International 680 274 2047 264 DFN-IP service G-WiN 8708 266 421 250 Romania Data Systems S.A. Complete listing at http://thyme.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8151 1246 2464 227 UniNet S.A. de C.V. 11830 603 299 9 Instituto Costarricense de El 22047 565 270 14 VTR PUNTO NET S.A. 7303 467 230 69 Telecom Argentina Stet-France 16814 426 27 10 NSS, S.A. 6471 412 85 46 ENTEL CHILE S.A. 11172 410 118 70 Servicios Alestra S.A de C.V 10620 394 101 72 TVCABLE BOGOTA 14117 374 23 9 Telefonica del Sur S.A. 20299 333 23 97 NEWCOM AMERICAS Complete listing at http://thyme.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 24863 475 61 30 LINKdotNET AS number 20858 391 34 3 EgyNet 3741 283 853 224 The Internet Solution 2018 201 205 85 Tertiary Education Network 5713 153 541 92 Telkom SA Ltd 6713 143 135 11 Itissalat Al-MAGHRIB 33783 135 10 12 EEPAD TISP TELECOM & INTERNET 5536 121 8 16 Internet Egypt Network 29571 102 13 8 Ci Telecom Autonomous system 33776 100 6 3 Starcomms Nigeria Limited Complete listing at http://thyme.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 209 3012 3874 620 Qwest 6389 2446 3138 190 bellsouth.net, inc. 4755 1649 387 89 Videsh Sanchar Nigam Ltd. Aut 2386 1493 663 874 AT&T Data Communications Serv 4323 1459 1044 376 Time Warner Telecom 7018 1397 5824 977 AT&T WorldNet Services 8151 1246 2464 227 UniNet S.A. de C.V. 11492 1229 149 12 Cable One 9498 1183 550 62 BHARTI BT INTERNET LTD. 17488 1156 80 79 Hathway IP Over Cable Interne Complete listing at http://thyme.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 6389 2446 2256 bellsouth.net, inc. 4755 1649 1560 Videsh Sanchar Nigam Ltd. Aut 11492 1229 1217 Cable One 9498 1183 1121 BHARTI BT INTERNET LTD. 4323 1459 1083 Time Warner Telecom 17488 1156 1077 Hathway IP Over Cable Interne 18566 1045 1035 Covad Communications 8151 1246 1019 UniNet S.A. de C.V. 1785 1077 973 AppliedTheory Corporation 22773 963 901 Cox Communications, Inc. Complete listing at http://thyme.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 16927 UNALLOCATED 12.0.252.0/23 701 UUNET Technologies, 22492 UNALLOCATED 12.2.46.0/24 7018 AT&T WorldNet Servic 15132 UNALLOCATED 12.9.150.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.14.170.0/24 7018 AT&T WorldNet Servic 13632 UNALLOCATED 12.20.55.0/24 6517 Yipes Communications 13746 UNALLOCATED 12.24.56.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.25.107.0/24 7018 AT&T WorldNet Servic 13632 UNALLOCATED 12.31.25.0/24 6517 Yipes Communications 27220 UNALLOCATED 12.35.204.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.152.0/24 7018 AT&T WorldNet Servic Complete listing at http://thyme.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 24.48.244.0/23 7843 Adelphia Corp. 24.51.159.0/24 7843 Adelphia Corp. 24.54.224.0/19 20001 HoldCo LLC - Road Runner 24.75.160.0/19 7843 Adelphia Corp. 24.75.192.0/18 7843 Adelphia Corp. 24.142.40.0/21 7018 AT&T WorldNet Services 24.142.160.0/19 7018 AT&T WorldNet Services 24.246.0.0/17 7018 AT&T WorldNet Services 24.246.128.0/18 7018 AT&T WorldNet Services 62.61.220.0/24 24974 Tachyon Europe BV - Wireless Complete listing at http://thyme.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:18 /9:9 /10:16 /11:43 /12:143 /13:280 /14:514 /15:1031 /16:9961 /17:4344 /18:7371 /19:15700 /20:18330 /21:17995 /22:22352 /23:23272 /24:136306 /25:865 /26:1032 /27:778 /28:82 /29:9 /30:1 /31:0 /32:7 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 209 1768 3012 Qwest 6389 1510 2446 bellsouth.net, inc. 11492 1210 1229 Cable One 2386 1189 1493 AT&T Data Communications Serv 18566 1026 1045 Covad Communications 4755 994 1649 Videsh Sanchar Nigam Ltd. Aut 9583 988 1138 Sify Limited 6298 974 989 Cox Communicatons 17488 968 1156 Hathway IP Over Cable Interne 6478 948 957 AT&T Worldnet Services Complete listing at http://thyme.apnic.net/current/data/sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 4:7 8:119 12:2063 13:1 15:22 16:3 17:5 18:13 20:35 24:1076 25:1 32:61 38:445 40:92 41:643 43:1 44:2 47:12 52:3 55:3 56:3 57:23 58:464 59:487 60:442 61:990 62:1221 63:2033 64:3296 65:2411 66:3582 67:1216 68:694 69:2272 70:679 71:121 72:1821 73:5 74:1016 75:157 76:297 77:732 78:726 79:193 80:957 81:846 82:596 83:398 84:578 85:1018 86:423 87:694 88:329 89:1268 90:14 91:1286 92:202 93:581 94:51 96:36 97:25 98:167 99:3 112:1 113:1 114:38 116:724 117:327 118:149 119:446 120:61 121:547 122:782 123:349 124:862 125:1134 128:362 129:202 130:131 131:408 132:67 133:9 134:177 135:33 136:219 137:86 138:146 139:78 140:491 141:99 142:419 143:315 144:356 145:51 146:363 147:155 148:507 149:194 150:130 151:193 152:143 153:135 154:10 155:277 156:177 157:273 158:168 159:242 160:266 161:114 162:234 163:187 164:522 165:446 166:319 167:325 168:618 169:138 170:428 171:29 172:10 189:210 190:2119 192:5795 193:4101 194:3204 195:2505 196:1075 198:3739 199:3271 200:5528 201:1471 202:7613 203:7932 204:3975 205:2110 206:2392 207:2767 208:3373 209:3491 210:2520 211:1012 212:1413 213:1652 214:149 215:49 216:4397 217:1198 218:346 219:415 220:1071 221:471 222:309 End of report From kgasso-lists at visp.net Fri Jun 20 13:23:47 2008 From: kgasso-lists at visp.net (Kameron Gasso) Date: Fri, 20 Jun 2008 11:23:47 -0700 Subject: Ping: GLBX NOC Message-ID: <485BF5B3.8090200@visp.net> Anyone from Global Crossing network engineering on-list? We're experiencing a connectivity issue from 63.228.227.0/24 to 64.233.187.99 that appears to be originating in Global Crossing's network. Other prefixes we announce from our AS (13941) such as 207.109.251.0/24 aren't having the problem. Tried the NOC email and phone number and was told that I can't open a case since we're not a direct customer. Unfortunately, I also can't reach the company today who we interconnect with that does peer with GLBX. To everyone else, sorry about the spam. -K grps-edge-rtr-1#ping ip 64.233.187.99 source 63.228.227.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 64.233.187.99, timeout is 2 seconds: Packet sent with a source address of 63.228.227.1 ..... Success rate is 0 percent (0/5) grps-edge-rtr-1#ping ip 64.233.187.99 source 207.109.251.253 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 64.233.187.99, timeout is 2 seconds: Packet sent with a source address of 207.109.251.253 !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 84/85/88 ms grps-edge-rtr-1#trace ip 64.233.187.99 source 63.228.227.1 Type escape sequence to abort. Tracing the route to google.com (64.233.187.99) 1 fa-6-0.grps-edge-rtr-2.visp.net (208.74.128.9) 0 msec 4 msec 0 msec 2 c1-mdfd-s40-visp.mind.net (69.9.134.65) [AS 6296] 4 msec 0 msec 4 msec 3 so-2-1-0.ar2.SEA1.gblx.net (64.212.109.181) [AS 3549] 12 msec 16 msec 12 msec 4 ge9-2-1000M.ar5.SEA1.gblx.net (67.17.109.250) [AS 3549] 12 msec 16 msec 12 msec 5 * * * 6 * * * 7 * * * 8 * * * 9 * * * 10 216.239.49.222 [AS 15169] 92 msec * * 11 * * * 12 google.com (64.233.187.99) [AS 15169] 84 msec 84 msec * grps-edge-rtr-1#trace ip 64.233.187.99 source 207.109.251.253 Type escape sequence to abort. Tracing the route to jc-in-f99.google.com (64.233.187.99) 1 fa-6-0.grps-edge-rtr-2.visp.net (208.74.128.9) 0 msec 0 msec 0 msec 2 c1-mdfd-s40-visp.mind.net (69.9.134.65) [AS 6296] 0 msec 0 msec 0 msec 3 so-2-1-0.ar2.SEA1.gblx.net (64.212.109.181) [AS 3549] 16 msec 8 msec 8 msec 4 ge9-2-1000M.ar5.SEA1.gblx.net (67.17.109.250) [AS 3549] 12 msec 8 msec 8 msec 5 74.125.49.1 [AS 15169] 44 msec 20 msec 20 msec 6 209.85.255.63 [AS 15169] 20 msec 24 msec 20 msec 7 66.249.95.210 [AS 15169] 12 msec 12 msec 12 msec 8 209.85.242.255 [AS 15169] 84 msec 84 msec 108 msec 9 72.14.239.21 [AS 15169] 84 msec 84 msec 72.14.236.15 [AS 15169] 88 msec 10 216.239.43.249 [AS 15169] 96 msec 216.239.43.189 [AS 15169] 88 msec 216.239.43.249 [AS 15169] 88 msec 11 jc-in-f99.google.com (64.233.187.99) [AS 15169] 84 msec 92 msec 84 msec -- Kameron Gasso | Senior Systems Administrator | visp.net Direct: 541-955-6903 | Fax: 541-471-0821 From rand at meridian-enviro.com Fri Jun 20 14:25:48 2008 From: rand at meridian-enviro.com (Douglas K. Rand) Date: Fri, 20 Jun 2008 14:25:48 -0500 Subject: smstools and CDMA Message-ID: <87mylf7vsz.wl%rand@meridian-enviro.com> From the GMS point of view I live and work in the boondocks: Grand Forks, North Dakota. (OK, so there is a decent argument that the entire US is GSM boondocks.) Anyway, I'm trying to figure out a way of sending and receiving text messages using a tool like smstools and a CDMA modem. I've found the MultiTech CDMA modem (MTCBA-C-N3-NAM) but I can't seem to find any success stories to go along with it. I was wondering if anybody has had any luck with either this modem and smstools3 in particular, or with sending/receiving text messages with a CDMA modem. From regnauld at catpipe.net Fri Jun 20 14:30:13 2008 From: regnauld at catpipe.net (Phil Regnauld) Date: Fri, 20 Jun 2008 21:30:13 +0200 Subject: smstools and CDMA In-Reply-To: <87mylf7vsz.wl%rand@meridian-enviro.com> References: <87mylf7vsz.wl%rand@meridian-enviro.com> Message-ID: <20080620193012.GA7482@catpipe.net> Douglas K. Rand (rand) writes: > From the GMS point of view I live and work in the boondocks: Grand > Forks, North Dakota. (OK, so there is a decent argument that the > entire US is GSM boondocks.) > > Anyway, I'm trying to figure out a way of sending and receiving text > messages using a tool like smstools and a CDMA modem. > > I've found the MultiTech CDMA modem (MTCBA-C-N3-NAM) but I can't seem > to find any success stories to go along with it. (I gather you mean smstools.meinemullemaus.de) Does it support the AT command set ? But even if it did, I think that the first question in the FAQ says it all regarding requirements, but I may be wrong. Alternatively, have you considered a Nokia handset with Gnokii ? http://smstools.meinemullemaus.de/faq.html 1) What hardware do I need? You need a Computer with at least one serial port. It does not matter how fast the CPU is and how much memory you installed. An old 486DX processor with 32 MB memory is enough. You also need at least one GSM modem with SMS command set according to the european specifications GSM 07.05 (=ETSI TS 300 585) and GSM 03.38 (=ETSI TS 100 900). When a vendor writes "SMS command set" without giving the specification names, then the device typically supports a subset of this specification. In this case you can surely send 7bit text messages and you can probably receive them. But its not sure, if status reports, binary messages or unicode messages work. From kgasso-lists at visp.net Fri Jun 20 14:59:58 2008 From: kgasso-lists at visp.net (Kameron Gasso) Date: Fri, 20 Jun 2008 12:59:58 -0700 Subject: Ping: GLBX NOC In-Reply-To: <485BF5B3.8090200@visp.net> References: <485BF5B3.8090200@visp.net> Message-ID: <485C0C3E.2040000@visp.net> Kameron Gasso wrote: > Anyone from Global Crossing network engineering on-list? > > We're experiencing a connectivity issue from 63.228.227.0/24 to > 64.233.187.99 that appears to be originating in Global Crossing's > network. Other prefixes we announce from our AS (13941) such as > 207.109.251.0/24 aren't having the problem. Thanks to everyone who replied off-list (including the GBLX engineer who fixed it). -K -- Kameron Gasso | Senior Systems Administrator | visp.net Direct: 541-955-6903 | Fax: 541-471-0821 From andrey.gordon at gmail.com Fri Jun 20 15:43:08 2008 From: andrey.gordon at gmail.com (Andrey Gordon) Date: Fri, 20 Jun 2008 15:43:08 -0500 Subject: smstools and CDMA In-Reply-To: <87mylf7vsz.wl%rand@meridian-enviro.com> References: <87mylf7vsz.wl%rand@meridian-enviro.com> Message-ID: <90ccfc90806201343g25094c48mca53482b151d4a56@mail.gmail.com> Douglas, I have a RHEL server that I connected MultiTech CDMA modem (MTCBA-C-U-N3) and running smstools3 with it. Some hackery was needed and it still does not work ideally. What I mean by that, i had to modify the source code of smstools3 to work around GSM SMS message format. In the end it works except one thing: I believe, because of the way smstools addresses memory where the message to be sent is stored, it never releases that memory back. So as a result, it always retains the last message in memory and when a new one needs to be send and if it's shorted then then previous one, I see the new message and leftovers of the previous one at the end. Let me know if you want some documents that I wrote up when I was messing with it. Andrey Gordon [andrey.gordon at gmail.com] On Fri, Jun 20, 2008 at 2:25 PM, Douglas K. Rand wrote: > From the GMS point of view I live and work in the boondocks: Grand > Forks, North Dakota. (OK, so there is a decent argument that the > entire US is GSM boondocks.) > > Anyway, I'm trying to figure out a way of sending and receiving text > messages using a tool like smstools and a CDMA modem. > > I've found the MultiTech CDMA modem (MTCBA-C-N3-NAM) but I can't seem > to find any success stories to go along with it. > > I was wondering if anybody has had any luck with either this modem and > smstools3 in particular, or with sending/receiving text messages with > a CDMA modem. > > From rand at meridian-enviro.com Fri Jun 20 16:50:09 2008 From: rand at meridian-enviro.com (Douglas K. Rand) Date: Fri, 20 Jun 2008 16:50:09 -0500 Subject: smstools and CDMA In-Reply-To: <90ccfc90806201343g25094c48mca53482b151d4a56@mail.gmail.com> References: <87mylf7vsz.wl%rand@meridian-enviro.com> <90ccfc90806201343g25094c48mca53482b151d4a56@mail.gmail.com> Message-ID: <873an7hj3i.wl%rand@meridian-enviro.com> Andrey> I have a RHEL server that I connected MultiTech CDMA modem Andrey> (MTCBA-C-U-N3) and running smstools3 with it. Great! Andrey> Let me know if you want some documents that I wrote up when I Andrey> was messing with it. Yes, that'd be great. From rand at meridian-enviro.com Fri Jun 20 16:54:30 2008 From: rand at meridian-enviro.com (Douglas K. Rand) Date: Fri, 20 Jun 2008 16:54:30 -0500 Subject: smstools and CDMA In-Reply-To: <20080620193012.GA7482@catpipe.net> References: <87mylf7vsz.wl%rand@meridian-enviro.com> <20080620193012.GA7482@catpipe.net> Message-ID: <871w2rhiw9.wl%rand@meridian-enviro.com> Doug> Anyway, I'm trying to figure out a way of sending and receiving text Doug> messages using a tool like smstools and a CDMA modem. Doug> I've found the MultiTech CDMA modem (MTCBA-C-N3-NAM) but I can't Doug> seem to find any success stories to go along with it. Phil> (I gather you mean smstools.meinemullemaus.de) Yes, that seems to be a popular package. Phil> Does it support the AT command set ? But even if it did, I Phil> think that the first question in the FAQ says it all regarding Phil> requirements, but I may be wrong. Yes, it has the AT command set, and MultiTech also sells a GSM modem (MTCBA-G) that is supported by smstools3, but a fairly casual reading of the reference manuals for both show quite a bit of diversity in the command set between the CDMA and GSM modems. Phil> Alternatively, have you considered a Nokia handset with Gnokii ? No, not really. I was thinking that a "modem" would be a little more robust and easier to deal with in the rack than a handset would be. If I'm given a choice, I think I'd stay away from a handset, but I may not have a choice. :) From andrey.gordon at gmail.com Fri Jun 20 23:11:25 2008 From: andrey.gordon at gmail.com (Andrey Gordon) Date: Fri, 20 Jun 2008 23:11:25 -0500 Subject: smstools and CDMA In-Reply-To: <873an7hj3i.wl%rand@meridian-enviro.com> References: <87mylf7vsz.wl%rand@meridian-enviro.com> <90ccfc90806201343g25094c48mca53482b151d4a56@mail.gmail.com> <873an7hj3i.wl%rand@meridian-enviro.com> Message-ID: <90ccfc90806202111j1d5a800bl5961064963983705@mail.gmail.com> >From what I found is that smstools will only work with GSM AT command set, so if you are 'locked' into CDMA you are screwed in regards of using smstools. I'm attaching the html page that I wrote up after I got the modem working in case the server dies. I have to mention that i was only interested in sending sms, so that's the only part I was messing with. Andrey Gordon [andrey.gordon at gmail.com] On Fri, Jun 20, 2008 at 4:50 PM, Douglas K. Rand wrote: > Andrey> I have a RHEL server that I connected MultiTech CDMA modem > Andrey> (MTCBA-C-U-N3) and running smstools3 with it. > > Great! > > Andrey> Let me know if you want some documents that I wrote up when I > Andrey> was messing with it. > > Yes, that'd be great. > -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: Netmon2 CDMA modem notes.htm URL: From andrey.gordon at gmail.com Fri Jun 20 23:19:26 2008 From: andrey.gordon at gmail.com (Andrey Gordon) Date: Fri, 20 Jun 2008 23:19:26 -0500 Subject: smstools and CDMA In-Reply-To: <90ccfc90806202111j1d5a800bl5961064963983705@mail.gmail.com> References: <87mylf7vsz.wl%rand@meridian-enviro.com> <90ccfc90806201343g25094c48mca53482b151d4a56@mail.gmail.com> <873an7hj3i.wl%rand@meridian-enviro.com> <90ccfc90806202111j1d5a800bl5961064963983705@mail.gmail.com> Message-ID: <90ccfc90806202119k3cbffab4w41f7b968a12a23b6@mail.gmail.com> geesh, I made a lot typos there. Also, i should mention that i don't know C, so don't judge me to harsh on modding the source code Andrey Gordon [andrey.gordon at gmail.com] On Fri, Jun 20, 2008 at 11:11 PM, Andrey Gordon wrote: > From what I found is that smstools will only work with GSM AT command set, > so if you are 'locked' into CDMA you are screwed in regards of using > smstools. > I'm attaching the html page that I wrote up after I got the modem working > in case the server dies. I have to mention that i was only interested in > sending sms, so that's the only part I was messing with. > > Andrey Gordon [andrey.gordon at gmail.com] > > On Fri, Jun 20, 2008 at 4:50 PM, Douglas K. Rand > wrote: > >> Andrey> I have a RHEL server that I connected MultiTech CDMA modem >> Andrey> (MTCBA-C-U-N3) and running smstools3 with it. >> >> Great! >> >> Andrey> Let me know if you want some documents that I wrote up when I >> Andrey> was messing with it. >> >> Yes, that'd be great. >> > > From regnauld at catpipe.net Sat Jun 21 04:07:27 2008 From: regnauld at catpipe.net (Phil Regnauld) Date: Sat, 21 Jun 2008 11:07:27 +0200 Subject: smstools and CDMA In-Reply-To: <871w2rhiw9.wl%rand@meridian-enviro.com> References: <87mylf7vsz.wl%rand@meridian-enviro.com> <20080620193012.GA7482@catpipe.net> <871w2rhiw9.wl%rand@meridian-enviro.com> Message-ID: <20080621090725.GA8728@catpipe.net> Douglas K. Rand (rand) writes: > > Phil> Alternatively, have you considered a Nokia handset with Gnokii ? > > No, not really. I was thinking that a "modem" would be a little more > robust and easier to deal with in the rack than a handset would be. If > I'm given a choice, I think I'd stay away from a handset, but I may > not have a choice. :) Think about it: mobile handsets have built-in UPSes :) From rs at seastrom.com Sat Jun 21 06:42:20 2008 From: rs at seastrom.com (Robert E. Seastrom) Date: Sat, 21 Jun 2008 07:42:20 -0400 Subject: smstools and CDMA In-Reply-To: <87mylf7vsz.wl%rand@meridian-enviro.com> (Douglas K. Rand's message of "Fri, 20 Jun 2008 14:25:48 -0500") References: <87mylf7vsz.wl%rand@meridian-enviro.com> Message-ID: <86tzfnc8v7.fsf@seastrom.com> Just in case you were contemplating getting the USB one and using it with a Mac, be aware that the serial-over-usb drivers are early-alpha quality, and although they were supplied as a universal binary, once my boss pried the source code to the original driver out of TI it became clear to him that due to endian reasons they had no hope of working on a PPC mac. So much for the G5 XServe that has run Nagios cleanly for ages. Joe-Bob says "caveat emptor". -r "Douglas K. Rand" writes: > From the GMS point of view I live and work in the boondocks: Grand > Forks, North Dakota. (OK, so there is a decent argument that the > entire US is GSM boondocks.) > > Anyway, I'm trying to figure out a way of sending and receiving text > messages using a tool like smstools and a CDMA modem. > > I've found the MultiTech CDMA modem (MTCBA-C-N3-NAM) but I can't seem > to find any success stories to go along with it. > > I was wondering if anybody has had any luck with either this modem and > smstools3 in particular, or with sending/receiving text messages with > a CDMA modem. From ekagan at axsne.com Sat Jun 21 14:03:49 2008 From: ekagan at axsne.com (ekagan at axsne.com) Date: Sat, 21 Jun 2008 15:03:49 -0400 Subject: Level 3 Boston (Comcast NY) handoff packet loss since 11AM EST Message-ID: <42F2995AD6FA0C4CA1EFBFD0CD3E9ABE0128110E@exch01.axsdom.local> FYI In case someone can get this to a clue-ful individual. There was been severe packet loss at Hop 11 below since 11AM EST this morning leaving Comcast Mass network out through Level 3 NY/Boston. I tried to report to Comcast (Request Summary: ID: 6863600) and was met with less than pleasant clue. So much for being a good net'izen. I agreed my "connection" was fine, but past that there was an issue. If there is actually a way to report to Comcast NOC, please advise. I've also reported to Internap from my side so they can investigate as well. Thanks Eric Packets Pings Hostname %Loss Rcv Snt Last Best Avg Worst 1. 192.168.100.5 0% 47 47 0 0 0 1 2. c-3-0-ubr04.brockton.ma.boston.comcast.net 0% 47 47 7 6 8 16 3. ge-2-40-ur01.brockton.ma.boston.comcast.net 0% 47 47 7 6 8 13 4. 68.85.162.73 0% 47 47 10 8 10 16 5. 68.85.162.58 0% 47 47 15 11 13 32 6. 68.85.162.57 0% 47 47 14 11 13 19 7. te-0-10-0-5-cr01.newyork.ny.ibone.comcast.net 0% 46 46 46 45 46 53 8. xe-11-1-0.edge1.NewYork2.Level3.net 0% 46 46 45 44 52 175 9. vlan69.csw1.NewYork1.Level3.net 0% 46 46 52 44 52 60 10. ae-61-61.ebr1.NewYork1.Level3.net 0% 46 46 45 45 51 60 11. ae-1-8.bar2.Boston1.Level3.net 50% 23 46 51 49 54 104 12. ae-0-11.bar1.Boston1.Level3.net 0% 46 46 118 49 58 174 13. ae-7-7.car1.Boston1.Level3.net 0% 46 46 50 49 52 67 14. 63.211.175.26 0% 46 46 53 49 60 215 15. border7.ge6-2-bbnet2.bsn.pnap.net 0% 46 46 154 50 60 187 16. host-4-64-203-66.axsne.net 0% 46 46 52 51 54 93 Packets: Sent = 240, Received = 230, Lost = 10 (4% loss), Packets: Sent = 54, Received = 49, Lost = 5 (9% loss), Minimum = 54ms, Maximum = 227ms, Average = 62ms Eric Kagan Access Northeast 24 x 7 NOC: 508-281-7600 x4 From rs at seastrom.com Sat Jun 21 14:31:24 2008 From: rs at seastrom.com (Robert E. Seastrom) Date: Sat, 21 Jun 2008 15:31:24 -0400 Subject: Level 3 Boston (Comcast NY) handoff packet loss since 11AM EST In-Reply-To: <42F2995AD6FA0C4CA1EFBFD0CD3E9ABE0128110E@exch01.axsdom.local> (ekagan@axsne.com's message of "Sat, 21 Jun 2008 15:03:49 -0400") References: <42F2995AD6FA0C4CA1EFBFD0CD3E9ABE0128110E@exch01.axsdom.local> Message-ID: <86abhemvoz.fsf@seastrom.com> You'll notice that there is no loss beyond that router, only at that router. Routers are in the business of routing packets, not of responding to mtr, traceroute, ping, etc. More detailed clue is at http://www.broadbandreports.com/faq/toolquestion/Packet_Loss_Test__Line_Quality_#14068 I do not see a problem here, and neither will Comcast or Level(3). What made you think there was an issue in the first place? -r writes: > FYI In case someone can get this to a clue-ful individual. There was > been severe packet loss at Hop 11 below since 11AM EST this morning > leaving Comcast Mass network out through Level 3 NY/Boston. > > I tried to report to Comcast (Request Summary: ID: 6863600) and was met > with less than pleasant clue. So much for being a good net'izen. I > agreed my "connection" was fine, but past that there was an issue. If > there is actually a way to report to Comcast NOC, please advise. > > I've also reported to Internap from my side so they can investigate as > well. > > Thanks > Eric > > > Packets Pings > Hostname > %Loss Rcv Snt Last Best Avg Worst > 1. 192.168.100.5 > 0% 47 47 0 0 0 1 > 2. c-3-0-ubr04.brockton.ma.boston.comcast.net > 0% 47 47 7 6 8 16 > 3. ge-2-40-ur01.brockton.ma.boston.comcast.net > 0% 47 47 7 6 8 13 > 4. 68.85.162.73 > 0% 47 47 10 8 10 16 > 5. 68.85.162.58 > 0% 47 47 15 11 13 32 > 6. 68.85.162.57 > 0% 47 47 14 11 13 19 > 7. te-0-10-0-5-cr01.newyork.ny.ibone.comcast.net > 0% 46 46 46 45 46 53 > 8. xe-11-1-0.edge1.NewYork2.Level3.net > 0% 46 46 45 44 52 175 > 9. vlan69.csw1.NewYork1.Level3.net > 0% 46 46 52 44 52 60 > 10. ae-61-61.ebr1.NewYork1.Level3.net > 0% 46 46 45 45 51 60 > 11. ae-1-8.bar2.Boston1.Level3.net > 50% 23 46 51 49 54 104 > 12. ae-0-11.bar1.Boston1.Level3.net > 0% 46 46 118 49 58 174 > 13. ae-7-7.car1.Boston1.Level3.net > 0% 46 46 50 49 52 67 > 14. 63.211.175.26 > 0% 46 46 53 49 60 215 > 15. border7.ge6-2-bbnet2.bsn.pnap.net > 0% 46 46 154 50 60 187 > 16. host-4-64-203-66.axsne.net > 0% 46 46 52 51 54 93 > > > Packets: Sent = 240, Received = 230, Lost = 10 (4% loss), > > Packets: Sent = 54, Received = 49, Lost = 5 (9% loss), > Minimum = 54ms, Maximum = 227ms, Average = 62ms > > > Eric Kagan > Access Northeast > 24 x 7 NOC: 508-281-7600 x4 From ekagan at axsne.com Sat Jun 21 14:37:14 2008 From: ekagan at axsne.com (ekagan at axsne.com) Date: Sat, 21 Jun 2008 15:37:14 -0400 Subject: Level 3 Boston (Comcast NY) handoff packet loss since 11AM EST In-Reply-To: <86abhemvoz.fsf@seastrom.com> References: <42F2995AD6FA0C4CA1EFBFD0CD3E9ABE0128110E@exch01.axsdom.local> <86abhemvoz.fsf@seastrom.com> Message-ID: <42F2995AD6FA0C4CA1EFBFD0CD3E9ABE01281111@exch01.axsdom.local> I had just reset the MTR counters, sorry. I have been getting bounced out of apps all day. Here is an MTR running for the last 30 minutes. Smokeping is also showing 4.37 avg loss, 44.41 max loss and 9.53 current loss (png attached if it goes through ?) Thanks Eric Packets Pings Hostname %Loss Rcv Snt Last Best Avg Worst 1. 192.168.100.5 0% 1355 1355 1 0 0 7 2. c-3-0-ubr04.brockton.ma.boston.comcast.net 9% 1245 1355 9 5 11 405 3. ge-2-40-ur01.brockton.ma.boston.comcast.net 9% 1241 1355 11 5 12 803 4. 68.85.162.73 9% 1240 1355 211 7 14 741 5. 68.85.162.58 9% 1238 1355 146 10 16 678 6. 68.85.162.57 10% 1233 1355 84 10 16 615 7. te-0-10-0-5-cr01.newyork.ny.ibone.comcast.net 9% 1235 1355 55 43 50 589 8. xe-11-1-0.edge1.NewYork2.Level3.net 9% 1238 1355 92 43 54 986 9. vlan69.csw1.NewYork1.Level3.net 9% 1240 1355 47 44 55 921 10. ae-61-61.ebr1.NewYork1.Level3.net 9% 1237 1355 53 44 56 870 11. ae-1-8.bar2.Boston1.Level3.net 37% 862 1355 609 48 60 609 12. ae-0-11.bar1.Boston1.Level3.net 9% 1238 1355 51 48 60 734 13. ae-7-7.car1.Boston1.Level3.net 9% 1239 1355 484 48 63 671 14. 63.211.175.26 8% 1246 1354 420 49 66 607 15. border7.ge6-2-bbnet2.bsn.pnap.net 8% 1248 1354 355 49 64 550 16. host-4-64-203-66.axsne.net 9% 1240 1354 290 51 59 488 Eric > -----Original Message----- > From: Robert E. Seastrom [mailto:rs at seastrom.com] > Sent: Saturday, June 21, 2008 3:31 PM > To: Eric Kagan > Cc: outages at isotf.org; nanog at merit.edu > Subject: Re: Level 3 Boston (Comcast NY) handoff packet loss > since 11AM EST > > > You'll notice that there is no loss beyond that router, only > at that router. > > Routers are in the business of routing packets, not of responding to > mtr, traceroute, ping, etc. More detailed clue is at > http://www.broadbandreports.com/faq/toolquestion/Packet_Loss_T > est__Line_Quality_#14068 > > I do not see a problem here, and neither will Comcast or Level(3). > > What made you think there was an issue in the first place? > > -r > > > writes: > > > FYI In case someone can get this to a clue-ful individual. > There was > > been severe packet loss at Hop 11 below since 11AM EST this morning > > leaving Comcast Mass network out through Level 3 NY/Boston. > > > > I tried to report to Comcast (Request Summary: ID: > 6863600) and was met > > with less than pleasant clue. So much for being a good net'izen. I > > agreed my "connection" was fine, but past that there was an > issue. If > > there is actually a way to report to Comcast NOC, please advise. > > > > I've also reported to Internap from my side so they can > investigate as > > well. > > > > Thanks > > Eric > > > > > > Packets Pings > > Hostname > > %Loss Rcv Snt Last Best Avg Worst > > 1. 192.168.100.5 > > 0% 47 47 0 0 0 1 > > 2. c-3-0-ubr04.brockton.ma.boston.comcast.net > > 0% 47 47 7 6 8 16 > > 3. ge-2-40-ur01.brockton.ma.boston.comcast.net > > 0% 47 47 7 6 8 13 > > 4. 68.85.162.73 > > 0% 47 47 10 8 10 16 > > 5. 68.85.162.58 > > 0% 47 47 15 11 13 32 > > 6. 68.85.162.57 > > 0% 47 47 14 11 13 19 > > 7. te-0-10-0-5-cr01.newyork.ny.ibone.comcast.net > > 0% 46 46 46 45 46 53 > > 8. xe-11-1-0.edge1.NewYork2.Level3.net > > 0% 46 46 45 44 52 175 > > 9. vlan69.csw1.NewYork1.Level3.net > > 0% 46 46 52 44 52 60 > > 10. ae-61-61.ebr1.NewYork1.Level3.net > > 0% 46 46 45 45 51 60 > > 11. ae-1-8.bar2.Boston1.Level3.net > > 50% 23 46 51 49 54 104 > > 12. ae-0-11.bar1.Boston1.Level3.net > > 0% 46 46 118 49 58 174 > > 13. ae-7-7.car1.Boston1.Level3.net > > 0% 46 46 50 49 52 67 > > 14. 63.211.175.26 > > 0% 46 46 53 49 60 215 > > 15. border7.ge6-2-bbnet2.bsn.pnap.net > > 0% 46 46 154 50 60 187 > > 16. host-4-64-203-66.axsne.net > > 0% 46 46 52 51 54 93 > > > > > > Packets: Sent = 240, Received = 230, Lost = 10 (4% loss), > > > > Packets: Sent = 54, Received = 49, Lost = 5 (9% loss), > > Minimum = 54ms, Maximum = 227ms, Average = 62ms > > > > > > Eric Kagan > > Access Northeast > > 24 x 7 NOC: 508-281-7600 x4 > -------------- next part -------------- A non-text attachment was scrubbed... Name: Internap-Border-Peer_last_10800[1].png Type: image/png Size: 34668 bytes Desc: Internap-Border-Peer_last_10800[1].png URL: From rs at seastrom.com Sat Jun 21 14:41:23 2008 From: rs at seastrom.com (Robert E. Seastrom) Date: Sat, 21 Jun 2008 15:41:23 -0400 Subject: Level 3 Boston (Comcast NY) handoff packet loss since 11AM EST In-Reply-To: <42F2995AD6FA0C4CA1EFBFD0CD3E9ABE01281111@exch01.axsdom.local> (ekagan@axsne.com's message of "Sat, 21 Jun 2008 15:37:14 -0400") References: <42F2995AD6FA0C4CA1EFBFD0CD3E9ABE0128110E@exch01.axsdom.local> <86abhemvoz.fsf@seastrom.com> <42F2995AD6FA0C4CA1EFBFD0CD3E9ABE01281111@exch01.axsdom.local> Message-ID: <86y74ylgnw.fsf@seastrom.com> Your problem looks very local to me (as in, between you and your CMTS). Have you checked with your neighbors to see if they are having problems too? Also, please don't send PNG attachments to mailing lists. We are all capable of reading ascii. -r writes: > I had just reset the MTR counters, sorry. I have been getting bounced > out of apps all day. Here is an MTR running for the last 30 minutes. > Smokeping is also showing 4.37 avg loss, 44.41 max loss and 9.53 current > loss (png attached if it goes through ?) > > Thanks > Eric > > > Packets Pings > Hostname > %Loss Rcv Snt Last Best Avg Worst > 1. 192.168.100.5 > 0% 1355 1355 1 0 0 7 > 2. c-3-0-ubr04.brockton.ma.boston.comcast.net > 9% 1245 1355 9 5 11 405 > 3. ge-2-40-ur01.brockton.ma.boston.comcast.net > 9% 1241 1355 11 5 12 803 > 4. 68.85.162.73 > 9% 1240 1355 211 7 14 741 > 5. 68.85.162.58 > 9% 1238 1355 146 10 16 678 > 6. 68.85.162.57 > 10% 1233 1355 84 10 16 615 > 7. te-0-10-0-5-cr01.newyork.ny.ibone.comcast.net > 9% 1235 1355 55 43 50 589 > 8. xe-11-1-0.edge1.NewYork2.Level3.net > 9% 1238 1355 92 43 54 986 > 9. vlan69.csw1.NewYork1.Level3.net > 9% 1240 1355 47 44 55 921 > 10. ae-61-61.ebr1.NewYork1.Level3.net > 9% 1237 1355 53 44 56 870 > 11. ae-1-8.bar2.Boston1.Level3.net > 37% 862 1355 609 48 60 609 > 12. ae-0-11.bar1.Boston1.Level3.net > 9% 1238 1355 51 48 60 734 > 13. ae-7-7.car1.Boston1.Level3.net > 9% 1239 1355 484 48 63 671 > 14. 63.211.175.26 > 8% 1246 1354 420 49 66 607 > 15. border7.ge6-2-bbnet2.bsn.pnap.net > 8% 1248 1354 355 49 64 550 > 16. host-4-64-203-66.axsne.net > 9% 1240 1354 290 51 59 488 > > > Eric > > > >> -----Original Message----- >> From: Robert E. Seastrom [mailto:rs at seastrom.com] >> Sent: Saturday, June 21, 2008 3:31 PM >> To: Eric Kagan >> Cc: outages at isotf.org; nanog at merit.edu >> Subject: Re: Level 3 Boston (Comcast NY) handoff packet loss >> since 11AM EST >> >> >> You'll notice that there is no loss beyond that router, only >> at that router. >> >> Routers are in the business of routing packets, not of responding to >> mtr, traceroute, ping, etc. More detailed clue is at >> http://www.broadbandreports.com/faq/toolquestion/Packet_Loss_T >> est__Line_Quality_#14068 >> >> I do not see a problem here, and neither will Comcast or Level(3). >> >> What made you think there was an issue in the first place? >> >> -r >> >> >> writes: >> >> > FYI In case someone can get this to a clue-ful individual. >> There was >> > been severe packet loss at Hop 11 below since 11AM EST this morning >> > leaving Comcast Mass network out through Level 3 NY/Boston. >> > >> > I tried to report to Comcast (Request Summary: ID: >> 6863600) and was met >> > with less than pleasant clue. So much for being a good net'izen. I >> > agreed my "connection" was fine, but past that there was an >> issue. If >> > there is actually a way to report to Comcast NOC, please advise. >> > >> > I've also reported to Internap from my side so they can >> investigate as >> > well. >> > >> > Thanks >> > Eric >> > >> > >> > Packets Pings >> > Hostname >> > %Loss Rcv Snt Last Best Avg Worst >> > 1. 192.168.100.5 >> > 0% 47 47 0 0 0 1 >> > 2. c-3-0-ubr04.brockton.ma.boston.comcast.net >> > 0% 47 47 7 6 8 16 >> > 3. ge-2-40-ur01.brockton.ma.boston.comcast.net >> > 0% 47 47 7 6 8 13 >> > 4. 68.85.162.73 >> > 0% 47 47 10 8 10 16 >> > 5. 68.85.162.58 >> > 0% 47 47 15 11 13 32 >> > 6. 68.85.162.57 >> > 0% 47 47 14 11 13 19 >> > 7. te-0-10-0-5-cr01.newyork.ny.ibone.comcast.net >> > 0% 46 46 46 45 46 53 >> > 8. xe-11-1-0.edge1.NewYork2.Level3.net >> > 0% 46 46 45 44 52 175 >> > 9. vlan69.csw1.NewYork1.Level3.net >> > 0% 46 46 52 44 52 60 >> > 10. ae-61-61.ebr1.NewYork1.Level3.net >> > 0% 46 46 45 45 51 60 >> > 11. ae-1-8.bar2.Boston1.Level3.net >> > 50% 23 46 51 49 54 104 >> > 12. ae-0-11.bar1.Boston1.Level3.net >> > 0% 46 46 118 49 58 174 >> > 13. ae-7-7.car1.Boston1.Level3.net >> > 0% 46 46 50 49 52 67 >> > 14. 63.211.175.26 >> > 0% 46 46 53 49 60 215 >> > 15. border7.ge6-2-bbnet2.bsn.pnap.net >> > 0% 46 46 154 50 60 187 >> > 16. host-4-64-203-66.axsne.net >> > 0% 46 46 52 51 54 93 >> > >> > >> > Packets: Sent = 240, Received = 230, Lost = 10 (4% loss), >> > >> > Packets: Sent = 54, Received = 49, Lost = 5 (9% loss), >> > Minimum = 54ms, Maximum = 227ms, Average = 62ms >> > >> > >> > Eric Kagan >> > Access Northeast >> > 24 x 7 NOC: 508-281-7600 x4 >> From tony at lava.net Sat Jun 21 14:46:50 2008 From: tony at lava.net (Antonio Querubin) Date: Sat, 21 Jun 2008 09:46:50 -1000 (HST) Subject: Level 3 Boston (Comcast NY) handoff packet loss since 11AM EST In-Reply-To: <42F2995AD6FA0C4CA1EFBFD0CD3E9ABE01281111@exch01.axsdom.local> References: <42F2995AD6FA0C4CA1EFBFD0CD3E9ABE0128110E@exch01.axsdom.local> <86abhemvoz.fsf@seastrom.com> <42F2995AD6FA0C4CA1EFBFD0CD3E9ABE01281111@exch01.axsdom.local> Message-ID: On Sat, 21 Jun 2008, ekagan at axsne.com wrote: > I had just reset the MTR counters, sorry. I have been getting bounced > out of apps all day. Here is an MTR running for the last 30 minutes. > Smokeping is also showing 4.37 avg loss, 44.41 max loss and 9.53 current > loss (png attached if it goes through ?) > Packets Pings > Hostname > %Loss Rcv Snt Last Best Avg Worst > 1. 192.168.100.5 > 0% 1355 1355 1 0 0 7 > 2. c-3-0-ubr04.brockton.ma.boston.comcast.net > 9% 1245 1355 9 5 11 405 > 3. ge-2-40-ur01.brockton.ma.boston.comcast.net > 9% 1241 1355 11 5 12 803 > 4. 68.85.162.73 > 9% 1240 1355 211 7 14 741 > 5. 68.85.162.58 > 9% 1238 1355 146 10 16 678 > 6. 68.85.162.57 > 10% 1233 1355 84 10 16 615 > 7. te-0-10-0-5-cr01.newyork.ny.ibone.comcast.net > 9% 1235 1355 55 43 50 589 > 8. xe-11-1-0.edge1.NewYork2.Level3.net > 9% 1238 1355 92 43 54 986 > 9. vlan69.csw1.NewYork1.Level3.net > 9% 1240 1355 47 44 55 921 > 10. ae-61-61.ebr1.NewYork1.Level3.net > 9% 1237 1355 53 44 56 870 > 11. ae-1-8.bar2.Boston1.Level3.net > 37% 862 1355 609 48 60 609 > 12. ae-0-11.bar1.Boston1.Level3.net > 9% 1238 1355 51 48 60 734 > 13. ae-7-7.car1.Boston1.Level3.net > 9% 1239 1355 484 48 63 671 > 14. 63.211.175.26 > 8% 1246 1354 420 49 66 607 > 15. border7.ge6-2-bbnet2.bsn.pnap.net > 8% 1248 1354 355 49 64 550 > 16. host-4-64-203-66.axsne.net > 9% 1240 1354 290 51 59 488 Did you notice that the received packets and %loss at hop 12 drops back down to that at hop 10 and doesn't significantly change after that? The problem is probably between hops 1 and 2. Antonio Querubin whois: AQ7-ARIN From blackham at gmail.com Sat Jun 21 20:55:45 2008 From: blackham at gmail.com (Kevin Blackham) Date: Sat, 21 Jun 2008 21:55:45 -0400 Subject: smstools and CDMA In-Reply-To: <20080621090725.GA8728@catpipe.net> References: <87mylf7vsz.wl%rand@meridian-enviro.com> <20080620193012.GA7482@catpipe.net> <871w2rhiw9.wl%rand@meridian-enviro.com> <20080621090725.GA8728@catpipe.net> Message-ID: And in my experience (many years back), a nokia handset would start draining its ups as soon as it got a full charge, requiring daily reseat of the supply cord. YMMV so test and retest. On 6/21/08, Phil Regnauld wrote: > Douglas K. Rand (rand) writes: >> >> Phil> Alternatively, have you considered a Nokia handset with Gnokii ? >> >> No, not really. I was thinking that a "modem" would be a little more >> robust and easier to deal with in the rack than a handset would be. If >> I'm given a choice, I think I'd stay away from a handset, but I may >> not have a choice. :) > > Think about it: mobile handsets have built-in UPSes :) > > > From paul at blacknight.com Sun Jun 22 04:52:04 2008 From: paul at blacknight.com (Paul Kelly :: Blacknight) Date: Sun, 22 Jun 2008 10:52:04 +0100 Subject: Intrustion attempts from Amazon EC2 IPs Message-ID: Hi there, Have any of you recently noticed a lot of ssh scanning coming from amazons EC "cloud" IP blocks? Today alone I've seen approx 4m attempts from EC2 IPs on just 20 nodes on our network. Has anyone any experience with Amazons abuse people? Thanks, Paul Paul Kelly Technical Director Blacknight Internet Solutions ltd Hosting, Colocation, Dedicated servers IP Transit Services Tel: +353 (0) 59 9183072 Lo-call: 1850 929 929 DDI: +353 (0) 59 9183091 e-mail: paul at blacknight.ie web: http://www.blacknight.ie Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park, Sleaty Road, Graiguecullen, Carlow, Ireland Company No.: 370845 From ops.lists at gmail.com Sun Jun 22 08:28:16 2008 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Sun, 22 Jun 2008 06:28:16 -0700 Subject: Intrustion attempts from Amazon EC2 IPs In-Reply-To: References: Message-ID: <485e5370.rc9yKSzHqmm6r0VJ%ops.lists@gmail.com> Well, there's spam originating from there, and some cracked scripts generating part of it. So ok, someone's found that it makes a handy platform for ssh port probes and such as well. srs "Paul Kelly :: Blacknight" wrote: > Hi there, > > Have any of you recently noticed a lot of ssh scanning coming from amazons EC > "cloud" IP blocks? > > Today alone I've seen approx 4m attempts from EC2 IPs on just 20 nodes on our > network. > > Has anyone any experience with Amazons abuse people? > > Thanks, > > Paul From jlewis at lewis.org Sun Jun 22 10:09:00 2008 From: jlewis at lewis.org (Jon Lewis) Date: Sun, 22 Jun 2008 11:09:00 -0400 (EDT) Subject: Intrustion attempts from Amazon EC2 IPs In-Reply-To: References: Message-ID: On Sun, 22 Jun 2008, Paul Kelly :: Blacknight wrote: > Have any of you recently noticed a lot of ssh scanning coming from > amazons EC "cloud" IP blocks? > > Today alone I've seen approx 4m attempts from EC2 IPs on just 20 nodes > on our network. That's not too surprising, since any unix-like system that gets compromised can make a handy platform for extending the hacker's collection. > Has anyone any experience with Amazons abuse people? Yeah, if you can call them that. There is no abuse coming from Amazon's EC2 cluster. I got the impression the only thing Amazon considers abuse is use of their servers and not paying the bill. If you're a paying customer, you can do whatever you like. ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From tme at multicasttech.com Sun Jun 22 10:38:27 2008 From: tme at multicasttech.com (Marshall Eubanks) Date: Sun, 22 Jun 2008 11:38:27 -0400 Subject: Intrustion attempts from Amazon EC2 IPs In-Reply-To: References: Message-ID: <5EEC6778-7165-4931-89A6-C739DFAD9B23@multicasttech.com> On Jun 22, 2008, at 5:52 AM, Paul Kelly :: Blacknight wrote: > Hi there, > > Have any of you recently noticed a lot of ssh scanning coming from > amazons EC "cloud" IP blocks? > > Today alone I've seen approx 4m attempts from EC2 IPs on just 20 > nodes on our network. > > Has anyone any experience with Amazons abuse people? You are aware of the NANOG thread (68 messages) on spam coming from the Amazon cloud - thread title is "amazonaws.com?" and it started May 23rd ? I would scan it as it deals with responses (or lack thereof) from Amazon. Regards Marshall > > > Thanks, > > Paul > > Paul Kelly > Technical Director > Blacknight Internet Solutions ltd > Hosting, Colocation, Dedicated servers > IP Transit Services > Tel: +353 (0) 59 9183072 > Lo-call: 1850 929 929 > DDI: +353 (0) 59 9183091 > > e-mail: paul at blacknight.ie > web: http://www.blacknight.ie > > Blacknight Internet Solutions Ltd, > Unit 12A,Barrowside Business Park, > Sleaty Road, > Graiguecullen, > Carlow, > Ireland > > Company No.: 370845 > From jra at baylink.com Sun Jun 22 11:13:15 2008 From: jra at baylink.com (Jay R. Ashworth) Date: Sun, 22 Jun 2008 12:13:15 -0400 Subject: Best utilizing fat long pipes and large file transfer In-Reply-To: <4855D9B7.6040907@gdt.id.au> References: <1213313218_50122@mail1.tellurian.net> <20080613160112.9F8B545047@ptavv.es.net> <1213375252_14636@mail1.tellurian.net> <4855D9B7.6040907@gdt.id.au> Message-ID: <20080622161315.GI29045@cgi.jachomes.com> On Mon, Jun 16, 2008 at 12:40:47PM +0930, Glen Turner wrote: > "Enable TCP window scaling and time stamps by using the Registry Editor > to browse to location > [HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters] > and add the key > Tcp1323Opts > with value > 3" > > are "hard". If you think otherwise, pick up the phone, pretend to > work for an ISP Help Desk, and walk someone who doesn't work in IT > through the changes. For what it's worth, I did first-tier for about 4 years, and yes, I had to walk some people through that... and as long as they weren't the type to *get frustrated* whild doing things they didn't understand, it generally went swimmingly. While I was driving down the interstate. In my 21 year old *stickshift* BMW. With a Big Mac in the other hand. ;-) So as long as *you* know how to drive the tools, and you're not in a hurry, that's not "hard". Just "complex". Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com '87 e24 St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 Those who cast the vote decide nothing. Those who count the vote decide everything. -- (Joseph Stalin) From jra at baylink.com Sun Jun 22 11:13:15 2008 From: jra at baylink.com (Jay R. Ashworth) Date: Sun, 22 Jun 2008 12:13:15 -0400 Subject: Best utilizing fat long pipes and large file transfer In-Reply-To: <4855D9B7.6040907@gdt.id.au> References: <1213313218_50122@mail1.tellurian.net> <20080613160112.9F8B545047@ptavv.es.net> <1213375252_14636@mail1.tellurian.net> <4855D9B7.6040907@gdt.id.au> Message-ID: <20080622161315.GI29045@cgi.jachomes.com> On Mon, Jun 16, 2008 at 12:40:47PM +0930, Glen Turner wrote: > "Enable TCP window scaling and time stamps by using the Registry Editor > to browse to location > [HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters] > and add the key > Tcp1323Opts > with value > 3" > > are "hard". If you think otherwise, pick up the phone, pretend to > work for an ISP Help Desk, and walk someone who doesn't work in IT > through the changes. For what it's worth, I did first-tier for about 4 years, and yes, I had to walk some people through that... and as long as they weren't the type to *get frustrated* whild doing things they didn't understand, it generally went swimmingly. While I was driving down the interstate. In my 21 year old *stickshift* BMW. With a Big Mac in the other hand. ;-) So as long as *you* know how to drive the tools, and you're not in a hurry, that's not "hard". Just "complex". Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com '87 e24 St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 Those who cast the vote decide nothing. Those who count the vote decide everything. -- (Joseph Stalin) From vixie at isc.org Sun Jun 22 11:17:08 2008 From: vixie at isc.org (Paul Vixie) Date: 22 Jun 2008 16:17:08 +0000 Subject: EC2 and GAE means end of ip address reputation industry? (Re: Intrustion attempts from Amazon EC2 IPs) In-Reply-To: References: Message-ID: jlewis at lewis.org (Jon Lewis) writes: > On Sun, 22 Jun 2008, Paul Kelly :: Blacknight wrote: > > > Has anyone any experience with Amazons abuse people? > > Yeah, if you can call them that. There is no abuse coming from Amazon's > EC2 cluster. I got the impression the only thing Amazon considers abuse > is use of their servers and not paying the bill. If you're a paying > customer, you can do whatever you like. it seems that amazon has succeeded where google and microsoft failed. with e-mail only services like hotmail and gmail, it was still possible to treat an IP address as having a reputation, and to therefore blackhole hotmail and gmail (and other free e-mail services) due to the spam emanating from them, even though they are shared IP addresses and also emit much non-spam traffic. since EC2 (and eventually google app engine) are used for server side, and commerce, the mere fact that probes and spam and ddos comes from these shared IP addresses won't be sufficient grounds to reject all traffic from them. i await with interest the final result: will most IP reputation services simply whitelist EC2 and GAE and similar, and grit their teeth at their inability to react to abuse from those IP addresses? this is the end of an era. since the day i started the first RBL i have had to listen to operators of shared IP addresses whine at me about how they had many non-spamming customers and it wasn't fair that i blackholed them simply because they couldn't stop it all. we went for many years trying to find the equilibrium point between making sure IP address owners were doing everything they could do (no pink contracts, fully staffed abuse desk with the power to suspend or disconnect customers pending management's later review, etc) while lots of other whiners said "vixie's gone soft on spam, he's letting UUNET get away with murder, let's lynch him!" with EC2, it's game-over for the IP reputation industry, other than possibly lists of dynamic IP blocks (modems, DSL, etc) from which SMTP ought not come. but for the wider IP address space, we now return to content based filtering, and i predict a mighty increase in the number of pink contracts in colo rooms. (the silver lining is, this could reduce pressure on BGP piracy/injection.) as randy bush often says, "it's just business." amazon has solid business reasons for creating EC2 and there's no way it could be profitable if they can't scale the user base, and there's no way to scale the user base if they have to police it at the application or "intent" level. so, i'm not whining, just pointing out that this is a sea change, the end of an era. -- Paul Vixie From jcurran at mail.com Sun Jun 22 11:43:10 2008 From: jcurran at mail.com (John Curran) Date: Sun, 22 Jun 2008 12:43:10 -0400 Subject: EC2 and GAE means end of ip address reputation industry? (Re: Intrustion attempts from Amazon EC2 IPs) In-Reply-To: References: Message-ID: At 4:17 PM +0000 6/22/08, Paul Vixie wrote: >with EC2, it's game-over for the IP reputation industry, other than >possibly lists of dynamic IP blocks (modems, DSL, etc) from which SMTP >ought not come. but for the wider IP address space, we now return to >content based filtering, and i predict a mighty increase in the number of >pink contracts in colo rooms. (the silver lining is, this could reduce >pressure on BGP piracy/injection.) > >as randy bush often says, "it's just business." amazon has solid business >reasons for creating EC2 and there's no way it could be profitable if they >can't scale the user base, and there's no way to scale the user base if >they have to police it at the application or "intent" level. so, i'm not >whining, just pointing out that this is a sea change, the end of an era. I agree that it's going to be difficult to deal with this on an IP reputation basis (at least using IPv4 :-), but not certain that means that a total lack of policing will stand long-term. The litmus test will likely be subsequent to the first large scale P2P service appearing in the EC2 cloud and distributing quantities of copyright material... /John From andy at nosignal.org Sun Jun 22 11:55:22 2008 From: andy at nosignal.org (Andy Davidson) Date: Sun, 22 Jun 2008 17:55:22 +0100 Subject: EC2 and GAE means end of ip address reputation industry? (Re: Intrustion attempts from Amazon EC2 IPs) In-Reply-To: References: Message-ID: <764C3A66-CBE4-4FB9-B1A3-FBA6CD5F04B6@nosignal.org> On 22 Jun 2008, at 17:17, Paul Vixie wrote: > with EC2, it's game-over for the IP reputation industry, Hi, Paul I was discussing this on an e-commerce practitioners list earlier today, and argued basically that, from an abuse point of view, EC2 is the same as any other bad neighborhood, and that operators needing to make impact fast, will treat it as they do any other bad neighborhood. Best wishes Andy From paul at vix.com Sun Jun 22 12:34:32 2008 From: paul at vix.com (Paul Vixie) Date: Sun, 22 Jun 2008 17:34:32 +0000 Subject: EC2 and GAE means end of ip address reputation industry? (Re: Intrustion attempts from Amazon EC2 IPs) In-Reply-To: Your message of "Sun, 22 Jun 2008 17:55:22 +0100." <764C3A66-CBE4-4FB9-B1A3-FBA6CD5F04B6@nosignal.org> References: <764C3A66-CBE4-4FB9-B1A3-FBA6CD5F04B6@nosignal.org> Message-ID: <73609.1214156072@sa.vix.com> hi andy. > > with EC2, it's game-over for the IP reputation industry, > > I was discussing this on an e-commerce practitioners list earlier today, and > argued basically that, from an abuse point of view, EC2 is the same as any > other bad neighborhood, and that operators needing to make impact fast, will > treat it as they do any other bad neighborhood. i wish i agreed. a bad neighborhood that's mostly access customers or mostly small businesses can be dealt with by address. but if it's mostly services and most of those are things your own customers want to reach and many of those are large, then the leverage is on the wrong end of the stick. if we lived in an ipv6 world, such that every EC2/GAE customer had its own dedicated IP address, not to be reused within a five year span, then blocking by IP address would remain practical, even though blocking by IP prefix or ASN is still ruled out. but in an ipv4 world where IP addresses are too precious to dedicate or retire on a per-customer basis, i don't see any large eyeball network subscribing to any IP reputation service who lists any part of EC2's address space. the problem with this model change is deeper than "we'll all get more spam". in http://www.vix.com/personalcolo/ i wrote that: If you're an Internet user in a bad neighborhood -- as evidenced by your mail not getting through to a lot of people, who then tell you that they're blocking all mail from your ISP since there's effectively no abuse desk -- but you're unable/uninterested in operating your own secure computer in some remote facility, then you'll need to locate a provider who can offer you a suite of services like e-mail and web hosting, who does not also offer those services to spammers and script kiddies. ... It's worth pointing out that a "better neighborhood" might also have as its customers people whose content is objectionable to you, for example, it might also host a lot of web sites offering politics, or pornography, or alternative lifestyles, or alternative energy, or who knows what-all. Don't worry about this. Some of the neighborhoods on the Internet whose reputations are strongest, are the ones with the most diverse customer bases. The point is, don't let your local cable or DSL spam-haven offer you an e-mail account, or web publishing services, or anything else that they can't afford to support. As a rule of thumb, $40 per month is not enough money to pay for an abuse desk; and without a strong, well trained abuse desk, the neighborhood will be "bad". among the distinctions being blurred by the EC2/GAE model, there is no longer going to be a competitive advantage for companies with fully funded abuse desks. if i'm right AOL/COX/Comcast cannot afford to blackhole EC2/GAE or to subscribe to any IP reputation service who blackholes EC2/GAE, then the level of inbound abuse these networks will treat as inevitable is going to rise to the point where the effective difference between the IP reputation of an ISP who signs pink contracts and/or has no abuse desk vs. an ISP who keeps out the bad guys and fully funds their abuse desk will be approximately Nil. without the ability to differentiate on this basis, a new lowest common denominator will be found as "good" ISPs are driven out of the margin by "bad" ISP's. jcurran's point that amazon may be forced to police itself if it becomes home to P2P networks hosting DMCA-taggable content is interesting. this could mean that amazon will have to re-price EC2 to include some policing costs, just to protect its executives and shareholders. the devil will be in the details -- if this is the path we all go down together, then amazon will still have to control its costs, and that'll mean picking the smallest possible list of things they'll police, and i don't think SSH port knocking or botnet C&C or open proxies will make *that* list, because they can manage those underlying risks at lower cost on the back end than on the front end. so in addition to ending an era, EC2/GAE/similar are beginning a new one in which the debate about the definition of acceptable use becomes multilateral rather than just a series of bilateral or unilateral agreements and actions. that is the other "silver lining" in all this. if distributed computing is a necessary utility then it may become a public utility and so EC2/GAE could spawn an "internet public utilities commission" at the state or federal level. and while i wouldn't like to see FCC-style "morality policing" of content, i think that if big companies are going to create public nuisances for what are perfectly valid business reasons, they should either pre-regulate or expect to be post-regulated. paul From troy at yort.com Sun Jun 22 13:23:37 2008 From: troy at yort.com (Troy Davis) Date: Sun, 22 Jun 2008 11:23:37 -0700 Subject: EC2 and GAE means end of ip address reputation industry? (Re: Intrustion attempts from Amazon EC2 IPs) In-Reply-To: References: Message-ID: <485E98A9.3000302@yort.com> Paul Vixie wrote: > with EC2, it's game-over for the IP reputation industry, other than > possibly lists of dynamic IP blocks (modems, DSL, etc) from which SMTP > ought not come. but for the wider IP address space, we now return to > content based filtering, and i predict a mighty increase in the number of > pink contracts in colo rooms. (the silver lining is, this could reduce > pressure on BGP piracy/injection.) I'm not sure that shared resources are impossibly tied to anonymity, at least when connectivity goes through a single entity. That entity is motivated to increase usage, to help its customers expose their own reputation (good or bad), and to host more complex services where this concern comes up. AWS already tracks VM instances and their internal IP allocations. They recently added "elastic IPs," which are assigned to a customer rather than a specific instance. To the rest of the world, they're static IPs. AWS could expose rwhois for those elastic IPs, or delegate from different shared and elastic blocks. Folks who care about establishing trust would choose elastic IPs. And while tracking NAT state for every connection would be painful, a few thoughtful choices could go a long way -- Pareto principle or even 95/5. For example, track instances w/more than 50 open outbound connections to dport 25; those trying to transmit a packet with a spoofed source address (ever); and count or rate-limit SYNs per internal instance IP. I could also see AWS allowing customers to translate all outgoing traffic to single customer-specific elastic IP, or even requiring it in order to generate certain traffic profiles (quantity, velocity, protocol, content). There's big design considerations here - points of egress/translation, EC2 availability zones - but they aren't insurmountable. Since the IP is already allocated to the customer, AWS could allow them to set a reverse DNS entry under their domain (and forward would match). Though GAE's shared architecture creates a bit more of a challenge, it's still not impossible. As it happens, GAE doesn't currently support many of the features that are most useful to abusers (like raw sockets), and may never. So the problems that prevent identifying a source entity also prevent abuse in the first place. Anyway, Amazon and Google are motivated and innovative, so I wouldn't write it off. Troy From aiversonlists at spamresource.com Sun Jun 22 13:24:43 2008 From: aiversonlists at spamresource.com (Al Iverson) Date: Sun, 22 Jun 2008 13:24:43 -0500 Subject: EC2 and GAE means end of ip address reputation industry? (Re: Intrustion attempts from Amazon EC2 IPs) In-Reply-To: <764C3A66-CBE4-4FB9-B1A3-FBA6CD5F04B6@nosignal.org> References: <764C3A66-CBE4-4FB9-B1A3-FBA6CD5F04B6@nosignal.org> Message-ID: <7d6a0cac0806221124o66a473e3vaf41539ab97fdee@mail.gmail.com> On Sun, Jun 22, 2008 at 11:55 AM, Andy Davidson wrote: > > On 22 Jun 2008, at 17:17, Paul Vixie wrote: > >> with EC2, it's game-over for the IP reputation industry, > I was discussing this on an e-commerce practitioners list earlier today, and > argued basically that, from an abuse point of view, EC2 is the same as any > other bad neighborhood, and that operators needing to make impact fast, will > treat it as they do any other bad neighborhood. I have to agree with Andy. There's simple math involved of how much good mail versus how much bad mail is coming from a network, and very few ISPs seem shy about blocking IPs or netblocks that cross those thresholds. Even if Paul is somehow correct about this becoming game changing for the concept of IP reputation, good people (non-spammers) using the EC2 platform are going to run into a lot of delivery pain, as existing ISP and blacklist reputation mechanisms have yet to give EC2 users a free pass, from what I've observed so far. I'm not going to pretend I manage inbound mail service for thousands-to-millions of users (as most of the participants of other lists like SPAM-L are fond of imagining themselves), but I know enough about how IP reputation systems work at ISPs to know that if I did manage inbound mail for such a userbase, the EC2 IPs would be blocked repeatedly and often, and there would come a point where the blocks escalate to /24s and larger, and there would come a point where the blocks are removed slower and less often. How the EC2 space is managed is not really new or exciting, as far as outbound mail goes. Regards, Al Iverson -- Al Iverson on Spam and Deliverability, see http://www.spamresource.com News, stats, info, and commentary on blacklists: http://www.dnsbl.com My personal website: http://www.aliverson.com -- Chicago, IL, USA Remove "lists" from my email address to reach me faster and directly. From yahoo at jimpop.com Sun Jun 22 13:33:55 2008 From: yahoo at jimpop.com (Jim Popovitch) Date: Sun, 22 Jun 2008 14:33:55 -0400 Subject: EC2 and GAE means end of ip address reputation industry? (Re: Intrustion attempts from Amazon EC2 IPs) In-Reply-To: References: Message-ID: <7ff145960806221133o65634d02m9af18bf6ea195b93@mail.gmail.com> On Sun, Jun 22, 2008 at 12:17 PM, Paul Vixie wrote: > so, i'm not whining, just pointing out that this is a sea change, the end of an era. I think that era ended when RBLs became so difficult to maintain without hour-by-hour effort. The sad thing is that there is no inverse-RBLs and MTAs that work straight forward with them. In todays, and tomorrows, world there needs to be a process of vetting inbound SMTP connections. I would much rather deal with a process that requires "proof of need to participate" rather than having wide open doors and windows and only being able to use a fly swatter. The problem with an maintaining an inverse-RBL is that it would require a centralized and reliable entity, not just one or two joe schmoes -Jim P. From paul at vix.com Sun Jun 22 13:48:03 2008 From: paul at vix.com (Paul Vixie) Date: Sun, 22 Jun 2008 18:48:03 +0000 Subject: EC2 and GAE means end of ip address reputation industry? (Re: Intrustion attempts from Amazon EC2 IPs) In-Reply-To: Your message of "Sun, 22 Jun 2008 11:23:37 MST." <485E98A9.3000302@yort.com> References: <485E98A9.3000302@yort.com> Message-ID: <75967.1214160483@sa.vix.com> > From: Troy Davis > ... > AWS already tracks VM instances and their internal IP allocations. They > recently added "elastic IPs," which are assigned to a customer rather > than a specific instance. To the rest of the world, they're static IPs. abusers don't have specific identities. they will find out the minimum level of identity-checking they have to spoof, and spoof that. stolen credit cards, throwaway domains, free e-mail accounts, and so on. before they get disco'd they already have their next instance set up and ready to go. the game is to live in the time margin of the ISP's reaction time, so that each fake identity gets a predictable amount of time and resources before it's stopped/abandoned. this is why during my time running MAPS, i focused on fully funded abuse desks with the power to suspend or disconnect in real time, 24x7, pending management review. warning policies or management approval increased the guaranteed minimum useful lifetime of a fake hosting customer identity to the point where there was no benefit in sending that ISP complaints at all. some ISPs went to extreme lengths to tie fake identities together so as to increase the up-front costs of serial abusers, but this inevitably raised their overall costs and also their acquisition costs for non-abusive customers, and the only thing that kept those increased costs from making these ISPs noncompetitive was that their reputation would be better, and a better reputation had an offsetting benefit. given that an static IP's reputation has inertia, and it takes days or weeks or sometimes years for a "bad IP" to get its reputation cleaned up enough for it to be reused, there's a window here where the pool of IP's EC2 can churn through if it assigned them statically to potentially abusive customers may not be large enough to also accomodate the new non-abusive load during the period they want that churn-pool to cover. and they'll have clean-up costs in resetting the reputation of previously abused IP's, with a natural tendancy of IP reputation services to think that amazon, as a large company, is doing the absolute minimum work nec'y to prevent serial abuse, such that inertia for EC2 addresses is likely to be effectively higher than for non-EC2 addresses. > ... > Anyway, Amazon and Google are motivated and innovative, so I wouldn't write > it off. > > Troy amazon and google are also large and profitable, and they know how to manage their risks and costs to the maximum benefit of their shareholders and their customers. this is a variation on "good, fast, or cheap: choose two". for something like EC2 to be a financial success, it has to scale, and the trade- offs that make scale possible also create dark corners and loopholes in which abusers can thrive. reputation systems have generally not scaled well, but they'll still be possible, based on content, domain name, digital signatures, webs of trust, that kind of thing. just not IP addresses like in the old days. paul From scg at gibbard.org Sun Jun 22 14:43:48 2008 From: scg at gibbard.org (Steve Gibbard) Date: Sun, 22 Jun 2008 12:43:48 -0700 (PDT) Subject: EC2 and GAE means end of ip address reputation industry? (Re: Intrustion attempts from Amazon EC2 IPs) In-Reply-To: References: Message-ID: <20080622122847.B5412@sprockets.gibbard.org> On Sun, 22 Jun 2008, Paul Vixie wrote: > it seems that amazon has succeeded where google and microsoft failed. with > e-mail only services like hotmail and gmail, it was still possible to treat > an IP address as having a reputation, and to therefore blackhole hotmail > and gmail (and other free e-mail services) due to the spam emanating from > them, even though they are shared IP addresses and also emit much non-spam > traffic. Even assuming Amazon will do as bad a job of policing EC2 as Paul suspects they will, I'm not at all convinced that customers would miss EC2 more than they'd miss mail from Hotmail or GMail. Paul has said in the past that he refuses e-mail from the various free webmail services. If that works for him, great, but I suspect the typical e-mail service customer wouldn't consider the resulting spam savings worth the potential downside. If I did that on my own servers, I'd probably miss out on most of the e-mail I care most about receiving, since my friends and relatives seem to like free webmail services. Given the number of legitimate free webmail users out there, and the number of people who like getting mail from them, I suspect any service provider who tried to block them would end up with a lot of angry former customers. Likewise, anybody blocking EC2 would miss out on whatever bad stuff might be coming out of EC2, but would miss out on being able to access services hosted there as well. Would they miss it more than they'd miss their friends on GMail? That seems far from guaranteed. So yeah, if big shared services that include important stuff aren't being adequately policed, that's probably a problem for IP address reputation services. But that's not really a new problem being introduced by EC2. -Steve From vixie at isc.org Sun Jun 22 17:20:24 2008 From: vixie at isc.org (Paul Vixie) Date: 22 Jun 2008 22:20:24 +0000 Subject: EC2 and GAE means end of ip address reputation industry? (Re: In-Reply-To: <20080622122847.B5412@sprockets.gibbard.org> References: <20080622122847.B5412@sprockets.gibbard.org> Message-ID: scg at gibbard.org (Steve Gibbard) writes: > ... > So yeah, if big shared services that include important stuff aren't being > adequately policed, that's probably a problem for IP address reputation > services. But that's not really a new problem being introduced by EC2. this may be an argument that the process i speak of has already begun, or it may dovetail with my observation, since i know that some big ISP's have been in blackhole wars with some big freemail providers already, whereas i do not expect any blackhole wars involving EC2 or similar. it's one thing to reject connections from some segment of the eyeball population on the basis that "more ought to be done to keep abuse from coming from there" but quite another thing to reject connection from a global e-commerce network just because some shared IP's are sometimes used abusively. the interpretive choice between "IP repututation systems were already doomed" and "IP reputation services are now doomed" does not puzzle me overmuch. -- Paul Vixie From randy at psg.com Sun Jun 22 18:18:35 2008 From: randy at psg.com (Randy Bush) Date: Mon, 23 Jun 2008 08:18:35 +0900 Subject: EC2 and GAE means end of ip address reputation industry? (Re: Intrustion attempts from Amazon EC2 IPs) In-Reply-To: <7ff145960806221133o65634d02m9af18bf6ea195b93@mail.gmail.com> References: <7ff145960806221133o65634d02m9af18bf6ea195b93@mail.gmail.com> Message-ID: <485EDDCB.8040907@psg.com> Jim Popovitch wrote: > there is no inverse-RBLs and MTAs that work straight forward with > them. from my exim config # Reject messages from senders listed in these DNSBLs # except for dnswl whitelust drop condition = ${if isip4{$sender_host_address}} message = blocked because $sender_host_address is \ in blacklist at $dnslist_domain: $dnslist_text !dnslists = list.dnswl.org dnslists = dialups.mail-abuse.org \ : rbl-plus.mail-abuse.org \ : qil.mail-abuse.com logwrite = REJECT because $sender_host_address listed in $dnslist_domain note list.dnswl.org randy From ops.lists at gmail.com Sun Jun 22 20:15:43 2008 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Mon, 23 Jun 2008 06:45:43 +0530 Subject: EC2 and GAE means end of ip address reputation industry? (Re: Intrustion attempts from Amazon EC2 IPs) In-Reply-To: <20080622122847.B5412@sprockets.gibbard.org> References: <20080622122847.B5412@sprockets.gibbard.org> Message-ID: On Mon, Jun 23, 2008 at 1:13 AM, Steve Gibbard wrote: > Likewise, anybody blocking EC2 would miss out on whatever bad stuff might be > coming out of EC2, but would miss out on being able to access services > hosted there as well. Would they miss it more than they'd miss their > friends on GMail? That seems far from guaranteed. SMTP blocks, when most of what's on EC2 doesnt actually originate email? Access to it would be over http which isnt firewalled. Or maybe ssh gets firewalled off. Death by a thousand access lists. Ouch. This simply means there must be a lot more effort - from their upstreams, and from their peers (not in a "network sense" as much as "large network operators who are of a sufficient size to talk to amazon and ensure that they're heard". To convince them that some filtering at their end, and implementation of abuse handling best practices would be a good idea. --srs From rdobbins at cisco.com Sun Jun 22 21:19:36 2008 From: rdobbins at cisco.com (Roland Dobbins) Date: Mon, 23 Jun 2008 09:19:36 +0700 Subject: EC2 and GAE means end of ip address reputation industry? (Re: Intrustion attempts from Amazon EC2 IPs) In-Reply-To: References: Message-ID: <8F70CD2A-307B-46C5-A8F9-006B568F1827@cisco.com> On Jun 22, 2008, at 11:17 PM, Paul Vixie wrote: > so, i'm not whining, just pointing out that this is a sea change, > the end of an era. And it's even more significant in that large enterprise customers and others will have explicitly *whitelisted* the IP blocks associated with these services. While static IPs are available for EC2 and for the other services, as you point out, it can't last in an IPv4 world. Later on, as the technologies mature and standards emerge, we'll see automagic arbitraging of jobs/loads/tasks between clouds, so things will be even more diffuse in terms of pinpointing the actual sources of undesirable traffic or other antisocial behavior (e.g., a spam engine may be resident in one cloud and making use of network resources/proxies in another cloud, that kind of thing; 'botnets in the sky', as it were). This is far different from free email Google or Hotmail - these cloud services (EC2, Mosso, Slicehost, Terremark's Enterprise Cloud, Telstra's new service, AppEngine, et.al.) are where many popular new Internet applications will live, and, even more significantly, where an increasing amount large-scale enterprise computing (like banking, pharma, government, and so forth) will take place. I foresee interesting times ahead. ----------------------------------------------------------------------- Roland Dobbins // +66.83.266.6344 mobile History is a great teacher, but it also lies with impunity. -- John Robb From dustin at rseng.net Sun Jun 22 21:26:31 2008 From: dustin at rseng.net (Dustin Jurman) Date: Sun, 22 Jun 2008 22:26:31 -0400 Subject: EC2 and GAE means end of ip address reputation industry? (Re:Intrustion attempts from Amazon EC2 IPs) In-Reply-To: <8F70CD2A-307B-46C5-A8F9-006B568F1827@cisco.com> References: <8F70CD2A-307B-46C5-A8F9-006B568F1827@cisco.com> Message-ID: <88C02FA1FE8ACC4EB30940F4FF551132EC7CAE@RSOP1.rseng.net> We're golden! DSJ -----Original Message----- From: Roland Dobbins [mailto:rdobbins at cisco.com] Sent: Sunday, June 22, 2008 10:20 PM To: nanog at merit.edu Subject: Re: EC2 and GAE means end of ip address reputation industry? (Re:Intrustion attempts from Amazon EC2 IPs) On Jun 22, 2008, at 11:17 PM, Paul Vixie wrote: > so, i'm not whining, just pointing out that this is a sea change, > the end of an era. And it's even more significant in that large enterprise customers and others will have explicitly *whitelisted* the IP blocks associated with these services. While static IPs are available for EC2 and for the other services, as you point out, it can't last in an IPv4 world. Later on, as the technologies mature and standards emerge, we'll see automagic arbitraging of jobs/loads/tasks between clouds, so things will be even more diffuse in terms of pinpointing the actual sources of undesirable traffic or other antisocial behavior (e.g., a spam engine may be resident in one cloud and making use of network resources/proxies in another cloud, that kind of thing; 'botnets in the sky', as it were). This is far different from free email Google or Hotmail - these cloud services (EC2, Mosso, Slicehost, Terremark's Enterprise Cloud, Telstra's new service, AppEngine, et.al.) are where many popular new Internet applications will live, and, even more significantly, where an increasing amount large-scale enterprise computing (like banking, pharma, government, and so forth) will take place. I foresee interesting times ahead. ----------------------------------------------------------------------- Roland Dobbins // +66.83.266.6344 mobile History is a great teacher, but it also lies with impunity. -- John Robb From nanog at daork.net Mon Jun 23 00:41:07 2008 From: nanog at daork.net (Nathan Ward) Date: Mon, 23 Jun 2008 17:41:07 +1200 Subject: EC2 and GAE means end of ip address reputation industry? (Re: Intrustion attempts from Amazon EC2 IPs) In-Reply-To: References: Message-ID: <13F58B9E-D0CF-4235-9B56-05774593EDE7@daork.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 23/06/2008, at 4:17 AM, Paul Vixie wrote: > as randy bush often says, "it's just business." amazon has solid > business > reasons for creating EC2 and there's no way it could be profitable > if they > can't scale the user base, and there's no way to scale the user base > if > they have to police it at the application or "intent" level. so, > i'm not > whining, just pointing out that this is a sea change, the end of an > era. Seems to me that blocking outgoing messages to 22/TCP should be easy enough. I'm sure there's some convoluted case where might be needed, but my guess is that losing those few customers would be worth the return in "trust". Not that the case where this is legitimate is very small - we're talking about a web app connecting to SSH servers that are outside the administrative control of the owner of the web app, as if they were in the same administrative control it would be trivial to run it on alternative ports. Same goes for SMTP, but provide mail relays that let you send messages only from domains you have registered with EC2 - should be easy enough to validate ownership - scan whois for email addresses, and send them "Person X has asked to send mail from this domain, please pass this message on to them. $verification_url". Sure there's other bad things that people are going to use this service for, but these seem to be the obvious ones that are easy to limit without big disruptions. Do 'normal' web hosting providers allow customer created scripts to create TCP sessions out to arbitrary things? - -- Nathan Ward -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) iQEVAwUBSF83c6hXB4ariYS3AQIBzAgAqiWxzvBjTfjzuf1GyE+PM9doF2S11d94 eKlWGeSjzqob2onSYbm46ffUNTkLQdwkt/jKRDS9eIk7nR7/5OWH9Mg9xkBR5uyu KndZyJgToHSA50TcpCjop3EXACjnufod7ZxTW0PZgVjAYU8cD7qfvXEBzcNuBxKH nZfe0gRuNL/swcArseXUxkL1Sf0qPRykc5nJOPQ0LHcjdoyZoAKlCqPerFVYjldz lOcTFtWMbBDNAUxAy2/ue2hv+K8VGMjC4JPGFdpFqDcumex86sagRJBcA8VbGY25 RkgPdLG41AUDtTGwuAnC3BQclsBcwlZRp4l/DDQYl+CVfPfU9+kuDw== =m6z6 -----END PGP SIGNATURE----- From brandon.galbraith at gmail.com Mon Jun 23 00:45:03 2008 From: brandon.galbraith at gmail.com (Brandon Galbraith) Date: Mon, 23 Jun 2008 00:45:03 -0500 Subject: EC2 and GAE means end of ip address reputation industry? (Re: Intrustion attempts from Amazon EC2 IPs) In-Reply-To: <13F58B9E-D0CF-4235-9B56-05774593EDE7@daork.net> References: <13F58B9E-D0CF-4235-9B56-05774593EDE7@daork.net> Message-ID: <366100670806222245p5fa083daq17a9f6120a9ecee6@mail.gmail.com> On 6/23/08, Nathan Ward wrote: > > > Do 'normal' web hosting providers allow customer created scripts to create > TCP sessions out to arbitrary things? > Doesn't PHP provide a fair amount of TCP functionality that can be used simply by uploading the code you need to your shared web hosting account? -brandon From laird at pando.com Mon Jun 23 00:56:58 2008 From: laird at pando.com (Laird Popkin) Date: Mon, 23 Jun 2008 01:56:58 -0400 (EDT) Subject: EC2 and GAE means end of ip address reputation industry? (Re: Intrustion attempts from Amazon EC2 IPs) In-Reply-To: <1738574997.422321214200448057.JavaMail.root@dkny.pando.com> Message-ID: <181568777.422341214200618610.JavaMail.root@dkny.pando.com> Normal hosting facilities let you do pretty much anything you want, unless you start causing problems for the ISP or their customers. You pay them to provide bandwidth, space, power and cooling. There are more restrictions for shared virtual sites (i.e. the $10/month web sites). Usually they just let you upload PHP and HTML pages and access a MySQL database. But, as Brandon pointed out, even they usually let you do basic things in PHP such as sending email. - Laird Popkin, CTO, Pando Networks mobile: 646/465-0570 ----- Original Message ----- From: "Brandon Galbraith" To: "Nathan Ward" Cc: "nanog" Sent: Monday, June 23, 2008 1:45:03 AM (GMT-0500) America/New_York Subject: Re: EC2 and GAE means end of ip address reputation industry? (Re: Intrustion attempts from Amazon EC2 IPs) On 6/23/08, Nathan Ward wrote: > > > Do 'normal' web hosting providers allow customer created scripts to create > TCP sessions out to arbitrary things? > Doesn't PHP provide a fair amount of TCP functionality that can be used simply by uploading the code you need to your shared web hosting account? -brandon From list at satchell.net Mon Jun 23 01:14:24 2008 From: list at satchell.net (Stephen Satchell) Date: Sun, 22 Jun 2008 23:14:24 -0700 Subject: EC2 and GAE means end of ip address reputation industry? (Re: Intrustion attempts from Amazon EC2 IPs) In-Reply-To: <366100670806222245p5fa083daq17a9f6120a9ecee6@mail.gmail.com> References: <13F58B9E-D0CF-4235-9B56-05774593EDE7@daork.net> <366100670806222245p5fa083daq17a9f6120a9ecee6@mail.gmail.com> Message-ID: <485F3F40.40205@satchell.net> Brandon Galbraith wrote: > On 6/23/08, Nathan Ward wrote: >> >> Do 'normal' web hosting providers allow customer created scripts to create >> TCP sessions out to arbitrary things? >> > > Doesn't PHP provide a fair amount of TCP functionality that can be used > simply by uploading the code you need to your shared web hosting account? PHP, Perl, Python all provide the ability to generate Socket connections via TCP and UDP. At the Web hosting company I used to work at, they ran a "mostly open" policy when it came to outbound connections. This was particularly true of co-located-equipment and leased-equipment customers, much more so than the shared-equipment accounts. When I monitored traffic, I found that the most common port for outgoing TCP connections was on port 80. Investigation of TCP port-22 outbound traffic showed that most of that traffic was SCP and tunneled RSYNC traffic to single locations. We found our share of bad apples, such as the the guy who set up a tunnel between a leased server and his location in Texas, for the purpose of running a spammer Web site with the payload coming to the Web host's IP addresses instead of the spammer operators' addresses. Of more interest to me, though, was the monitoring of traffic on our currently unallocated IP addresses; *lots* of woodpeckering on a wide variety of ports. The reason I originally set up a server that would accept packets from all currently-unused IP addresses was to minimize the ARP flooding that occurred when someone would hammer on an IP address that wasn't in use. Once that was in place, it was a trivial matter to monitor abusive traffic and add to the local access control list as necessary when requests to the network operators of the source of abusive traffic would not take steps to remove the people who were not RFC 1855-compliant. The default server's logs proved to be an excellent way for us to detect compromised on-site dedicated servers, particularly those servers infected with mal-ware designed to "probe the immediate neighborhood" first. From nanog at daork.net Mon Jun 23 01:24:55 2008 From: nanog at daork.net (Nathan Ward) Date: Mon, 23 Jun 2008 18:24:55 +1200 Subject: EC2 and GAE means end of ip address reputation industry? (Re: Intrustion attempts from Amazon EC2 IPs) In-Reply-To: <485F3F40.40205@satchell.net> References: <13F58B9E-D0CF-4235-9B56-05774593EDE7@daork.net> <366100670806222245p5fa083daq17a9f6120a9ecee6@mail.gmail.com> <485F3F40.40205@satchell.net> Message-ID: <36075D75-CC71-46D9-9628-1B3ABBADD589@daork.net> On 23/06/2008, at 6:14 PM, Stephen Satchell wrote: > PHP, Perl, Python all provide the ability to generate Socket > connections via TCP and UDP. At the Web hosting company I used to > work at, they ran a "mostly open" policy when it came to outbound > connections. This was particularly true of co-located-equipment and > leased-equipment customers, much more so than the shared-equipment > accounts. > > When I monitored traffic, I found that the most common port for > outgoing TCP connections was on port 80. Investigation of TCP > port-22 outbound traffic showed that most of that traffic was SCP > and tunneled RSYNC traffic to single locations. > > We found our share of bad apples, such as the the guy who set up a > tunnel between a leased server and his location in Texas, for the > purpose of running a spammer Web site with the payload coming to the > Web host's IP addresses instead of the spammer operators' addresses. > > Of more interest to me, though, was the monitoring of traffic on our > currently unallocated IP addresses; *lots* of woodpeckering on a > wide variety of ports. The reason I originally set up a server that > would accept packets from all currently-unused IP addresses was to > minimize the ARP flooding that occurred when someone would hammer on > an IP address that wasn't in use. Once that was in place, it was a > trivial matter to monitor abusive traffic and add to the local > access control list as necessary when requests to the network > operators of the source of abusive traffic would not take steps to > remove the people who were not RFC 1855-compliant. > > The default server's logs proved to be an excellent way for us to > detect compromised on-site dedicated servers, particularly those > servers infected with mal-ware designed to "probe the immediate > neighborhood" first. Yep, darknets are a common way to detect that sort of thing, there's quite a few papers on them. I'd be pretty worried if my colo provider was limiting what I could do - but it seems silly to let your average web hosting customer (i.e. $10/mo php+mysql service) open outgoing TCP sessions to ports other than 80 and 443. I'm sure there are exceptions to the rule, and they should be exactly that - exceptions. -- Nathan Ward From lear at cisco.com Mon Jun 23 02:02:04 2008 From: lear at cisco.com (Eliot Lear) Date: Mon, 23 Jun 2008 09:02:04 +0200 Subject: EC2 and GAE means end of ip address reputation industry? (Re: Intrustion attempts from Amazon EC2 IPs) In-Reply-To: References: Message-ID: <485F4A6C.5080004@cisco.com> Hi Paul, Let's go back to the case and point: Amazon is claimed not to behave as a good Netizen.[*] In these circumstances we have to ask why the traditional system doesn't work. This is precisely the case when you want to ding someone's reputation. Your argument that many good applications will be running to counterbalance the bad depends on whether those running the good applications will tolerate intermittent outages because the bad applications cause the sites to get blacklisted. Also, let's remember that reputation means different things in different contexts. One could easily envision a cloud having a good web reputation and a lousy or at best neutral email reputation.[**] In addition, the risks of infection are also very different. In the web case, if a host connects to a known infected site, its risk of becoming infected is very high, compared to the risk of someone receiving an email message that points to spam. This means to me that end users who are protecting themselves with some sort of web reputation service are likely to guard against clouds and not quickly whitelist them. But there's also the possibility for web reputation services to improve granularity above and beyond the IP address, but this depends on quite a number of things, such as whether SSL is used and where and how information is collected by the services.[***] And so the question boils down to this: will Amazon and its ilk adapt to the current reputation services model or will it be the other way around? I think it will be both, but more the former than the latter. Eliot [*] Not my claim. [**] Email reputation is commonly applied to messages and to TCP/25. For our purposes, although it's overly simplistic, let's view web reputation as everything else. [***] Self-signed certs are a clearly interesting area to consider when it comes to THEIR reputations. The same can be said for any X.509 CA that itself doesn't do a good job of confirming the identity of a requestor. I don't suggest that this should be a sole input or even a significant discriminator in and of itself, of course. From mehmet at icann.org Mon Jun 23 04:15:25 2008 From: mehmet at icann.org (Mehmet Akcin) Date: Mon, 23 Jun 2008 02:15:25 -0700 Subject: Spamcop Message-ID: Hi If there are some members of Spamcop here, please contact me off-list Mehmet -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2228 bytes Desc: not available URL: From frnkblk at iname.com Mon Jun 23 07:31:20 2008 From: frnkblk at iname.com (Frank Bulk - iNAME) Date: Mon, 23 Jun 2008 07:31:20 -0500 Subject: Cloud service [was: RE: EC2 and GAE means end of ip address reputation industry? (Re: Intrustion attempts from Amazon EC2 IPs)] In-Reply-To: <8F70CD2A-307B-46C5-A8F9-006B568F1827@cisco.com> References: <8F70CD2A-307B-46C5-A8F9-006B568F1827@cisco.com> Message-ID: When I hear "cloud services" I think "in the network" even though it appears all these cloud services perform their work at a data center as an outsourced service. Is there a vendor that makes a product that perform spam/malware filtering literally in the network, i.e. as a service provider, can I provide spam filtering for the enterprises in my customer base by adding a piece of network gear? I'm not aware of one today except those who provide enterprise-oriented gateways like SonicWall. Frank -----Original Message----- From: Roland Dobbins [mailto:rdobbins at cisco.com] Sent: Sunday, June 22, 2008 9:20 PM To: nanog at merit.edu Subject: Re: EC2 and GAE means end of ip address reputation industry? (Re: Intrustion attempts from Amazon EC2 IPs) This is far different from free email Google or Hotmail - these cloud services (EC2, Mosso, Slicehost, Terremark's Enterprise Cloud, Telstra's new service, AppEngine, et.al.) are where many popular new Internet applications will live, and, even more significantly, where an increasing amount large-scale enterprise computing (like banking, pharma, government, and so forth) will take place. I foresee interesting times ahead. ----------------------------------------------------------------------- Roland Dobbins // +66.83.266.6344 mobile History is a great teacher, but it also lies with impunity. -- John Robb From paul at vix.com Mon Jun 23 08:38:29 2008 From: paul at vix.com (Paul Vixie) Date: Mon, 23 Jun 2008 13:38:29 +0000 Subject: EC2 and GAE means end of ip address reputation industry? (Re: Intrustion attempts from Amazon EC2 IPs) In-Reply-To: Your message of "Mon, 23 Jun 2008 09:02:04 +0200." <485F4A6C.5080004@cisco.com> References: <485F4A6C.5080004@cisco.com> Message-ID: <12109.1214228309@sa.vix.com> eliot wrote: > Let's go back to the case and point: Amazon is claimed not to behave as a > good Netizen.[*] In these circumstances we have to ask why the traditional > system doesn't work. This is precisely the case when you want to ding > someone's reputation. Your argument that many good applications will be > running to counterbalance the bad depends on whether those running the good > applications will tolerate intermittent outages because the bad applications > cause the sites to get blacklisted. my argument doesn't get that far, actually. i think there will be no outages because recipients of abuse won't feel that they can afford to toss out the good with the bad in this particular case. which is going to remind of me tom lehrer's quip, "feels like a christian scientist with appendicitis" once an EC2 customer instance gets infected with malware that then ddos's somebody. > But there's also the possibility for web reputation services to improve > granularity above and beyond the IP address, but this depends on quite a > number of things, such as whether SSL is used and where and how information > is collected by the services.[***] i suppose i have been too prolific here of late, since i predicted exactly that, but it's no doubt buried in some response of mine that you did not read. > And so the question boils down to this: will Amazon and its ilk adapt to > the current reputation services model or will it be the other way around? > I think it will be both, but more the former than the latter. i think it will be both, and more the latter than the former. i'm basing this prediction on leverage, risks, and costs. if amazon and google and anyone else who provides large scale virtualization (where "large scale" means there is no in-person meeting to kick off the relationship, no credit check on the customer, and so on) knows that their good customers are so valuable to the rest of the world that some number of bad customers mixed in will not matter, then their rational decision will be to discover the break point and enforce that much and no more. this is how big companies get big and stay big; it's what ISP's have always done wrt their abuse desks; it's the break point i sought to move with MAPS; and the basis for that break point is in a totally different place for (server-side large-scale no-fixed-ip). paul From patrick at zill.net Mon Jun 23 08:50:06 2008 From: patrick at zill.net (Patrick Giagnocavo) Date: Mon, 23 Jun 2008 09:50:06 -0400 Subject: EC2 and GAE means end of ip address reputation industry? (Re: Intrustion attempts from Amazon EC2 IPs) In-Reply-To: <12109.1214228309@sa.vix.com> References: <485F4A6C.5080004@cisco.com> <12109.1214228309@sa.vix.com> Message-ID: <485FAA0E.9000103@zill.net> Paul Vixie wrote: > my argument doesn't get that far, actually. i think there will be no outages > because recipients of abuse won't feel that they can afford to toss out the > good with the bad in this particular case. which is going to remind of me > tom lehrer's quip, "feels like a christian scientist with appendicitis" once > an EC2 customer instance gets infected with malware that then ddos's somebody. What has been missing from this entire thread, is the input/experiences of those who are actually using EC2 to run their web sites. If you look at places where people are actually running EC2 in either testing or production, you will find that they are concerned about legitimate email from their EC2 instances actually reaching their customers. See for instance, the many EC2 threads on Paul Graham's "Hacker News" site at http://news.ycombinator.com (best to use Google to search the site probably). What I think would/should happen is that EC2 is never assumed to be a legitimate source of email; and any EC2 instance that sends email will instead be relaying through a non-EC2 mail server. Cordially Patrick From ops.lists at gmail.com Mon Jun 23 09:15:20 2008 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Mon, 23 Jun 2008 19:45:20 +0530 Subject: EC2 and GAE means end of ip address reputation industry? (Re: Intrustion attempts from Amazon EC2 IPs) In-Reply-To: <485FAA0E.9000103@zill.net> References: <485F4A6C.5080004@cisco.com> <12109.1214228309@sa.vix.com> <485FAA0E.9000103@zill.net> Message-ID: On Mon, Jun 23, 2008 at 7:20 PM, Patrick Giagnocavo wrote: > What I think would/should happen is that EC2 is never assumed to be a > legitimate source of email; and any EC2 instance that sends email will > instead be relaying through a non-EC2 mail server. Mail / spam seems to be the least of ec2's problems though. This thread started off with ssh port probes. srs -- Suresh Ramasubramanian (ops.lists at gmail.com) From ops.lists at gmail.com Mon Jun 23 09:16:27 2008 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Mon, 23 Jun 2008 19:46:27 +0530 Subject: Cloud service [was: RE: EC2 and GAE means end of ip address reputation industry? (Re: Intrustion attempts from Amazon EC2 IPs)] In-Reply-To: References: <8F70CD2A-307B-46C5-A8F9-006B568F1827@cisco.com> Message-ID: On Mon, Jun 23, 2008 at 6:01 PM, Frank Bulk - iNAME wrote: > Is there a vendor that makes a product that perform spam/malware filtering > literally in the network, i.e. as a service provider, can I provide spam > filtering for the enterprises in my customer base by adding a piece of > network gear? I'm not aware of one today except those who provide > enterprise-oriented gateways like SonicWall. Symantec Mail Security / Turntide Mailchannels Traffic Control --srs -- Suresh Ramasubramanian (ops.lists at gmail.com) From becker at proxy.net Mon Jun 23 09:21:54 2008 From: becker at proxy.net (Bernard Becker) Date: Mon, 23 Jun 2008 10:21:54 -0400 Subject: Australian Co-Lo In-Reply-To: Message-ID: Looking for recommendations for carrier neutral co-lo facility for Melbourne Australia. Our searches so far seem to turn up sites either on Telstra or Optus affiliated co-lo facilities. We need to be in a carrier neutral space with access to any of the major providers. Searching for co-lo space in Australia from Toronto is somewhat challenging. Websites make lots of claims that can't be validated without going and seeing the place. Bernard Becker Senior Network Architect Filogix - A Davis & Henderson Company. Tel: 416-360-1777 x3341 Fax: 416-847-5816 Toll Free: 1-866-435-6165 From marty at supine.com Mon Jun 23 10:04:35 2008 From: marty at supine.com (Martin Barry) Date: Mon, 23 Jun 2008 17:04:35 +0200 Subject: Australian Co-Lo In-Reply-To: References: Message-ID: <20080623150435.GB29465@sprocket.mamista.net> $quoted_author = "Bernard Becker" ; > > Looking for recommendations for carrier neutral co-lo facility for Melbourne > Australia. Our searches so far seem to turn up sites either on Telstra or > Optus affiliated co-lo facilities. We need to be in a carrier neutral space > with access to any of the major providers. This was created by a SAGE-AU member in response to a similar request. http://maps.google.com/maps/ms?msa=0&msid=117984623075363696099.000439d39e1c7bd8d46c2&ie=UTF8&z=12 cheers Marty From skeeve at skeeve.org Mon Jun 23 10:10:01 2008 From: skeeve at skeeve.org (Skeeve Stevens) Date: Tue, 24 Jun 2008 01:10:01 +1000 Subject: Australian Co-Lo In-Reply-To: <20080623150435.GB29465@sprocket.mamista.net> References: <20080623150435.GB29465@sprocket.mamista.net> Message-ID: <072501c8d543$36ba18f0$a42e4ad0$@org> If it doesn't need to be Melbourne, there is a good selection in Sydney. The best being Equinix and Globalswitch ...Skeeve -- Skeeve Stevens, Managing Director eintellego Pty Ltd - The ISP Specialists skeeve at eintellego.net / www.eintellego.net Phone: (+612) 8197 2760, Fax: (+612) 8572 9954 Cell +61 (0)414 753 383 / skype://skeeve -- NOC, NOC, who's there? -----Original Message----- From: Martin Barry [mailto:marty at supine.com] Sent: Tuesday, 24 June 2008 1:05 AM To: nanog at nanog.org Subject: Re: Australian Co-Lo $quoted_author = "Bernard Becker" ; > > Looking for recommendations for carrier neutral co-lo facility for Melbourne > Australia. Our searches so far seem to turn up sites either on Telstra or > Optus affiliated co-lo facilities. We need to be in a carrier neutral space > with access to any of the major providers. This was created by a SAGE-AU member in response to a similar request. http://maps.google.com/maps/ms?msa=0&msid=117984623075363696099.000439d39e1c 7bd8d46c2&ie=UTF8&z=12 cheers Marty From karnaugh at karnaugh.za.net Mon Jun 23 10:17:55 2008 From: karnaugh at karnaugh.za.net (Colin Alston) Date: Mon, 23 Jun 2008 17:17:55 +0200 Subject: EC2 and GAE means end of ip address reputation industry? (Re: Intrustion attempts from Amazon EC2 IPs) In-Reply-To: References: Message-ID: <485FBEA3.6090506@karnaugh.za.net> On 2008/06/22 06:17 PM Paul Vixie wrote: > with EC2, it's game-over for the IP reputation industry Realistically speaking, did you not expect that to be inevitable? As access to the internet increases, the chances of SMTP scaling to prevent spam decreases. And as IP's become more numerous and 'chuckable' (so much more so with IPv6 around the corner), the idea of a blacklist becomes ever more useless. What we need is a new mail protocol.. [But people have been saying that for decades now] From herrin-nanog at dirtside.com Mon Jun 23 10:38:16 2008 From: herrin-nanog at dirtside.com (William Herrin) Date: Mon, 23 Jun 2008 11:38:16 -0400 Subject: EC2 and GAE means end of ip address reputation industry? (Re: Intrustion attempts from Amazon EC2 IPs) In-Reply-To: <764C3A66-CBE4-4FB9-B1A3-FBA6CD5F04B6@nosignal.org> References: <764C3A66-CBE4-4FB9-B1A3-FBA6CD5F04B6@nosignal.org> Message-ID: <3c3e3fca0806230838p245ca697pea1bc6aa02f2c593@mail.gmail.com> On Sun, Jun 22, 2008 at 12:55 PM, Andy Davidson wrote: > On 22 Jun 2008, at 17:17, Paul Vixie wrote: >> with EC2, it's game-over for the IP reputation industry, > I was discussing this on an e-commerce practitioners list earlier today, and > argued basically that, from an abuse point of view, EC2 is the same as any > other bad neighborhood, and that operators needing to make impact fast, will > treat it as they do any other bad neighborhood. Concur. From an address-reputation perspective EC2 is no different than, say, China. Connections from China start life much closer to my filtering threshold that connections from Europe because a far lower percentage of the connections from China are legitimate. EC2 will get the same treatment. As that starts to impact Amazon's ability to maintain and grow the service, they'll do something about it. Or let it wither. Either way, address reputation solves my problem. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From Valdis.Kletnieks at vt.edu Mon Jun 23 11:55:03 2008 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 23 Jun 2008 12:55:03 -0400 Subject: EC2 and GAE means end of ip address reputation industry? (Re: Intrustion attempts from Amazon EC2 IPs) In-Reply-To: Your message of "Mon, 23 Jun 2008 11:38:16 EDT." <3c3e3fca0806230838p245ca697pea1bc6aa02f2c593@mail.gmail.com> References: <764C3A66-CBE4-4FB9-B1A3-FBA6CD5F04B6@nosignal.org> <3c3e3fca0806230838p245ca697pea1bc6aa02f2c593@mail.gmail.com> Message-ID: <18680.1214240103@turing-police.cc.vt.edu> On Mon, 23 Jun 2008 11:38:16 EDT, William Herrin said: > Concur. From an address-reputation perspective EC2 is no different > than, say, China. Connections from China start life much closer to my > filtering threshold that connections from Europe because a far lower > percentage of the connections from China are legitimate. EC2 will get > the same treatment. As that starts to impact Amazon's ability to > maintain and grow the service, they'll do something about it. Or let > it wither. Either way, address reputation solves my problem. No, it only solves your problem *if* you can compute a trustable reputation for each address. For instance, "connections from China" loses if another /12 shows up in the routing table and isn't correctly tagged as "China". And this fails the other way too - I remember a *lot* of providers were blocking a /8 or so because it was "China", and didn't know that a chunk of that /8 was in fact Australia. Similarly, you lose if EC2 deploys another /16 and you don't pick up on it. There's a *reason* that Marcus Ranum listed "Trying to enumerate badness" as one of the 6 stupidest ideas in computer security.... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From paul at vix.com Mon Jun 23 12:01:48 2008 From: paul at vix.com (Paul Vixie) Date: Mon, 23 Jun 2008 17:01:48 +0000 Subject: EC2 and GAE means end of ip address reputation industry? (Re: Intrustion attempts from Amazon EC2 IPs) In-Reply-To: Your message of "Mon, 23 Jun 2008 17:17:55 +0200." <485FBEA3.6090506@karnaugh.za.net> References: <485FBEA3.6090506@karnaugh.za.net> Message-ID: <18899.1214240508@sa.vix.com> > > with EC2, it's game-over for the IP reputation industry > > Realistically speaking, did you not expect that to be inevitable? i didn't, no. when i unknowingly launched the IP reputation industry back in the mid 1990's, the risk i was managing was a spammer who planned to give away free T1 lines to anyone who would run a spam relay for them. everything in those days was fixed ip on wire lines. when the game changed to open relay and open proxy and then malware-botnets, i saw a great deal of pressure on the model since a given IP address could represent different endpoints at various times of the day, and each endpoint could be cleaned and reinfected many times in a month, but with short TTLs on the DNS RBL, it was still possible to keep the pressure on the infected endpoints and their ISPs, since they bore the greatest cost of their own misbehaviour, and reputation-entropy was a cheap component of the overall error rate. so, no. > As access to the internet increases, the chances of SMTP scaling to prevent > spam decreases. And as IP's become more numerous and 'chuckable' (so much > more so with IPv6 around the corner), the idea of a blacklist becomes ever > more useless. yes, but that was a shallow curve, whereas EC2/GAE/etc is a steep curve. > What we need is a new mail protocol.. [But people have been saying that for > decades now] several excellent, scalable replacements for smtp have been patented. all we have to do is globally agree to enrich those patent holders and our problems will be solved. From tomb at byrneit.net Mon Jun 23 12:13:20 2008 From: tomb at byrneit.net (Tomas L. Byrnes) Date: Mon, 23 Jun 2008 10:13:20 -0700 Subject: EC2 and GAE means end of ip address reputation industry? (Re:Intrustion attempts from Amazon EC2 IPs) In-Reply-To: <18680.1214240103@turing-police.cc.vt.edu> References: <764C3A66-CBE4-4FB9-B1A3-FBA6CD5F04B6@nosignal.org><3c3e3fca0806230838p245ca697pea1bc6aa02f2c593@mail.gmail.com> <18680.1214240103@turing-police.cc.vt.edu> Message-ID: <70D072392E56884193E3D2DE09C097A9F24A@pascal.zaphodb.org> Just because something doesn't solve all your problems doesn't mean it has no value. Anything that can reduce the amount of inspection you have to do @ content, and filters out the gross cruft, buys you additional network and systems capacity, using what you have now (firewall, mail relay). This is a good thing in a real-world network, and goes straight to the bottom line in reduced opex and capex. The process of detecting and blocking bad actors, for networks that have to allow access to/from anywhere, is better than doing nothing. Marcus also likes to light hay bales on fire. Methinks for the same reason he makes inflammatory statements: It gets people talking and thinking, which is a good thing. > -----Original Message----- > From: Valdis.Kletnieks at vt.edu [mailto:Valdis.Kletnieks at vt.edu] > Sent: Monday, June 23, 2008 9:55 AM > To: William Herrin > Cc: Paul Vixie; nanog at merit.edu > Subject: Re: EC2 and GAE means end of ip address reputation > industry? (Re:Intrustion attempts from Amazon EC2 IPs) > > On Mon, 23 Jun 2008 11:38:16 EDT, William Herrin said: > > > Concur. From an address-reputation perspective EC2 is no different > > than, say, China. Connections from China start life much > closer to my > > filtering threshold that connections from Europe because a > far lower > > percentage of the connections from China are legitimate. > EC2 will get > > the same treatment. As that starts to impact Amazon's ability to > > maintain and grow the service, they'll do something about > it. Or let > > it wither. Either way, address reputation solves my problem. > > No, it only solves your problem *if* you can compute a > trustable reputation for each address. For instance, > "connections from China" loses if another /12 shows up in the > routing table and isn't correctly tagged as "China". And > this fails the other way too - I remember a *lot* of > providers were blocking a /8 or so because it was "China", > and didn't know that a chunk of that /8 was in fact > Australia. Similarly, you lose if EC2 deploys another /16 > and you don't pick up on it. > > There's a *reason* that Marcus Ranum listed "Trying to > enumerate badness" > as one of the 6 stupidest ideas in computer security.... > > From tomb at byrneit.net Mon Jun 23 12:44:24 2008 From: tomb at byrneit.net (Tomas L. Byrnes) Date: Mon, 23 Jun 2008 10:44:24 -0700 Subject: Cloud service [was: RE: EC2 and GAE means end of ip addressreputation industry? (Re: Intrustion attempts from Amazon EC2 IPs)] In-Reply-To: References: <8F70CD2A-307B-46C5-A8F9-006B568F1827@cisco.com> Message-ID: <70D072392E56884193E3D2DE09C097A9F24D@pascal.zaphodb.org> Barracuda, or you could build the exact same thing using OSS. Procmail, Spamassasin, ClamAV, and your choice of RBLs (or use karmashpere to custom roll a hybrid one). > -----Original Message----- > From: Suresh Ramasubramanian [mailto:ops.lists at gmail.com] > Sent: Monday, June 23, 2008 7:16 AM > To: frnkblk at iname.com > Cc: nanog at merit.edu > Subject: Re: Cloud service [was: RE: EC2 and GAE means end of > ip addressreputation industry? (Re: Intrustion attempts from > Amazon EC2 IPs)] > > On Mon, Jun 23, 2008 at 6:01 PM, Frank Bulk - iNAME > wrote: > > Is there a vendor that makes a product that perform spam/malware > > filtering literally in the network, i.e. as a service > provider, can I > > provide spam filtering for the enterprises in my customer base by > > adding a piece of network gear? I'm not aware of one today except > > those who provide enterprise-oriented gateways like SonicWall. > > Symantec Mail Security / Turntide > Mailchannels Traffic Control > > --srs > > -- > Suresh Ramasubramanian (ops.lists at gmail.com) > > From tomb at byrneit.net Mon Jun 23 12:45:38 2008 From: tomb at byrneit.net (Tomas L. Byrnes) Date: Mon, 23 Jun 2008 10:45:38 -0700 Subject: EC2 and GAE means end of ip address reputation industry? (Re:Intrustion attempts from Amazon EC2 IPs) In-Reply-To: <485FBEA3.6090506@karnaugh.za.net> References: <485FBEA3.6090506@karnaugh.za.net> Message-ID: <70D072392E56884193E3D2DE09C097A9F24E@pascal.zaphodb.org> You can easily make IP reputation scale to IPV6 using the APL RRTYPE. See RFC3123 > -----Original Message----- > From: Colin Alston [mailto:karnaugh at karnaugh.za.net] > Sent: Monday, June 23, 2008 8:18 AM > To: Paul Vixie > Cc: nanog at merit.edu > Subject: Re: EC2 and GAE means end of ip address reputation > industry? (Re:Intrustion attempts from Amazon EC2 IPs) > > On 2008/06/22 06:17 PM Paul Vixie wrote: > > with EC2, it's game-over for the IP reputation industry > > Realistically speaking, did you not expect that to be inevitable? > > As access to the internet increases, the chances of SMTP > scaling to prevent spam decreases. And as IP's become more > numerous and 'chuckable' (so much more so with IPv6 around > the corner), the idea of a blacklist becomes ever more useless. > > What we need is a new mail protocol.. [But people have been > saying that for decades now] > > From schampeo at hesketh.com Mon Jun 23 13:28:04 2008 From: schampeo at hesketh.com (Steven Champeon) Date: Mon, 23 Jun 2008 14:28:04 -0400 Subject: EC2 and GAE means end of ip address reputation industry? (Re: Intrustion attempts from Amazon EC2 IPs) In-Reply-To: <7d6a0cac0806221124o66a473e3vaf41539ab97fdee@mail.gmail.com> References: <764C3A66-CBE4-4FB9-B1A3-FBA6CD5F04B6@nosignal.org> <7d6a0cac0806221124o66a473e3vaf41539ab97fdee@mail.gmail.com> Message-ID: <20080623182804.GC2693@hesketh.com> on Sun, Jun 22, 2008 at 01:24:43PM -0500, Al Iverson wrote: > I'm not going to pretend I manage inbound mail service for > thousands-to-millions of users (as most of the participants of other > lists like SPAM-L are fond of imagining themselves), but I know enough > about how IP reputation systems work at ISPs to know that if I did > manage inbound mail for such a userbase, the EC2 IPs would be blocked > repeatedly and often, and there would come a point where the blocks > escalate to /24s and larger, and there would come a point where the > blocks are removed slower and less often. I don't pretend to manage inbound mail service for more than dozens, but I do provide a service via enemieslist that is indirectly used by millions, and out of the over 32K rDNS naming conventions I've catalogued and classified, in terms of their dynamicity/staticity/etc., only four are related to Amazon/EC2. Now, if the entire 'Net moved to a cloud computing model, I could agree with Paul that this would be the end of IP reputation. But I'm only aware of two such services (Amazon EC2 and Media Temple's gridserver.com) in widespread use, so I haven't bothered to come up with a new classification for them, and treat them as essentially dynamic (with gridserver.com also classified as 'webhost'). I moved away from the strictly IP-based reputation model several years ago (though I still use DNSBLs as a practical tool), and instead treat classes of IPs as a set about which certain reputation-ish qualities can be asserted, which works very well in a scoring-style context. Steve -- hesketh.com/inc. v: +1(919)834-2552 f: +1(919)834-2553 w: http://hesketh.com/ antispam news, solutions for sendmail, exim, postfix: http://enemieslist.com/ From schampeo at hesketh.com Mon Jun 23 13:28:04 2008 From: schampeo at hesketh.com (Steven Champeon) Date: Mon, 23 Jun 2008 14:28:04 -0400 Subject: EC2 and GAE means end of ip address reputation industry? (Re: Intrustion attempts from Amazon EC2 IPs) In-Reply-To: <7d6a0cac0806221124o66a473e3vaf41539ab97fdee@mail.gmail.com> References: <764C3A66-CBE4-4FB9-B1A3-FBA6CD5F04B6@nosignal.org> <7d6a0cac0806221124o66a473e3vaf41539ab97fdee@mail.gmail.com> Message-ID: <20080623182804.GC2693@hesketh.com> on Sun, Jun 22, 2008 at 01:24:43PM -0500, Al Iverson wrote: > I'm not going to pretend I manage inbound mail service for > thousands-to-millions of users (as most of the participants of other > lists like SPAM-L are fond of imagining themselves), but I know enough > about how IP reputation systems work at ISPs to know that if I did > manage inbound mail for such a userbase, the EC2 IPs would be blocked > repeatedly and often, and there would come a point where the blocks > escalate to /24s and larger, and there would come a point where the > blocks are removed slower and less often. I don't pretend to manage inbound mail service for more than dozens, but I do provide a service via enemieslist that is indirectly used by millions, and out of the over 32K rDNS naming conventions I've catalogued and classified, in terms of their dynamicity/staticity/etc., only four are related to Amazon/EC2. Now, if the entire 'Net moved to a cloud computing model, I could agree with Paul that this would be the end of IP reputation. But I'm only aware of two such services (Amazon EC2 and Media Temple's gridserver.com) in widespread use, so I haven't bothered to come up with a new classification for them, and treat them as essentially dynamic (with gridserver.com also classified as 'webhost'). I moved away from the strictly IP-based reputation model several years ago (though I still use DNSBLs as a practical tool), and instead treat classes of IPs as a set about which certain reputation-ish qualities can be asserted, which works very well in a scoring-style context. Steve -- hesketh.com/inc. v: +1(919)834-2552 f: +1(919)834-2553 w: http://hesketh.com/ antispam news, solutions for sendmail, exim, postfix: http://enemieslist.com/ From joelja at bogus.com Mon Jun 23 14:19:49 2008 From: joelja at bogus.com (Joel Jaeggli) Date: Mon, 23 Jun 2008 12:19:49 -0700 Subject: Cloud service [was: RE: EC2 and GAE means end of ip address reputation industry? (Re: Intrustion attempts from Amazon EC2 IPs)] In-Reply-To: References: <8F70CD2A-307B-46C5-A8F9-006B568F1827@cisco.com> Message-ID: <485FF755.9030605@bogus.com> Frank Bulk - iNAME wrote: > When I hear "cloud services" I think "in the network" even though it appears > all these cloud services perform their work at a data center as an > outsourced service. > > Is there a vendor that makes a product that perform spam/malware filtering > literally in the network, i.e. as a service provider, can I provide spam > filtering for the enterprises in my customer base by adding a piece of > network gear? I'm not aware of one today except those who provide > enterprise-oriented gateways like SonicWall. dpi boxes from a number of vendors can do that sort of thing... whether they can do it fast enough to be inline with your compute cloud is another question entirely. That said the result is fairly perilous when rejecting a message involves forging packets. and of course tls supporting mta's will be opaque to the network traffic inspecting device. > Frank > > -----Original Message----- > From: Roland Dobbins [mailto:rdobbins at cisco.com] > Sent: Sunday, June 22, 2008 9:20 PM > To: nanog at merit.edu > Subject: Re: EC2 and GAE means end of ip address reputation industry? (Re: > Intrustion attempts from Amazon EC2 IPs) > > > > This is far different from free email Google or Hotmail - these cloud > services (EC2, Mosso, Slicehost, Terremark's Enterprise Cloud, > Telstra's new service, AppEngine, et.al.) are where many popular new > Internet applications will live, and, even more significantly, where > an increasing amount large-scale enterprise computing (like banking, > pharma, government, and so forth) will take place. > > I foresee interesting times ahead. > > ----------------------------------------------------------------------- > Roland Dobbins // +66.83.266.6344 mobile > > History is a great teacher, but it also lies with impunity. > > -- John Robb > > > > From frnkblk at iname.com Mon Jun 23 15:05:34 2008 From: frnkblk at iname.com (Frank Bulk) Date: Mon, 23 Jun 2008 15:05:34 -0500 Subject: Cloud service [was: RE: EC2 and GAE means end of ip address reputation industry? (Re: Intrustion attempts from Amazon EC2 IPs)] In-Reply-To: References: <8F70CD2A-307B-46C5-A8F9-006B568F1827@cisco.com> Message-ID: Interesting. I was more thinking of the Turntide approach which operates within the network stream than Mailchannels which appears to operate on the same server as the MTA, but in front of it. Frank -----Original Message----- From: Suresh Ramasubramanian [mailto:ops.lists at gmail.com] Sent: Monday, June 23, 2008 9:16 AM To: frnkblk at iname.com Cc: nanog at merit.edu Subject: Re: Cloud service [was: RE: EC2 and GAE means end of ip address reputation industry? (Re: Intrustion attempts from Amazon EC2 IPs)] On Mon, Jun 23, 2008 at 6:01 PM, Frank Bulk - iNAME wrote: > Is there a vendor that makes a product that perform spam/malware filtering > literally in the network, i.e. as a service provider, can I provide spam > filtering for the enterprises in my customer base by adding a piece of > network gear? I'm not aware of one today except those who provide > enterprise-oriented gateways like SonicWall. Symantec Mail Security / Turntide Mailchannels Traffic Control --srs -- Suresh Ramasubramanian (ops.lists at gmail.com) From frnkblk at iname.com Mon Jun 23 15:24:41 2008 From: frnkblk at iname.com (Frank Bulk) Date: Mon, 23 Jun 2008 15:24:41 -0500 Subject: Cloud service [was: RE: EC2 and GAE means end of ip address reputation industry? (Re: Intrustion attempts from Amazon EC2 IPs)] In-Reply-To: <485FF755.9030605@bogus.com> References: <8F70CD2A-307B-46C5-A8F9-006B568F1827@cisco.com> <485FF755.9030605@bogus.com> Message-ID: Thanks. Even with TLS, the destination port (either 25 or 365) is well-known, right, as is the source IP? At the minimum RBLs could be used for that encrypted traffic. Frank -----Original Message----- From: Joel Jaeggli [mailto:joelja at bogus.com] Sent: Monday, June 23, 2008 2:20 PM To: frnkblk at iname.com Cc: nanog at merit.edu Subject: Re: Cloud service [was: RE: EC2 and GAE means end of ip address reputation industry? (Re: Intrustion attempts from Amazon EC2 IPs)] dpi boxes from a number of vendors can do that sort of thing... whether they can do it fast enough to be inline with your compute cloud is another question entirely. That said the result is fairly perilous when rejecting a message involves forging packets. and of course tls supporting mta's will be opaque to the network traffic inspecting device. From babydr at baby-dragons.com Mon Jun 23 15:26:07 2008 From: babydr at baby-dragons.com (Mr. James W. Laferriere) Date: Mon, 23 Jun 2008 12:26:07 -0800 (AKDT) Subject: smstools and CDMA In-Reply-To: References: <87mylf7vsz.wl%rand@meridian-enviro.com> <20080620193012.GA7482@catpipe.net> <871w2rhiw9.wl%rand@meridian-enviro.com> <20080621090725.GA8728@catpipe.net> Message-ID: Hello Kevin , On Sat, 21 Jun 2008, Kevin Blackham wrote: > And in my experience (many years back), a nokia handset would start > draining its ups as soon as it got a full charge, requiring daily > reseat of the supply cord. YMMV so test and retest. > > On 6/21/08, Phil Regnauld wrote: >> Douglas K. Rand (rand) writes: >>> >>> Phil> Alternatively, have you considered a Nokia handset with Gnokii ? >>> >>> No, not really. I was thinking that a "modem" would be a little more >>> robust and easier to deal with in the rack than a handset would be. If >>> I'm given a choice, I think I'd stay away from a handset, but I may >>> not have a choice. :) >> >> Think about it: mobile handsets have built-in UPSes :) If that s/b the case try using a Power Timer ie: something like , http://www.simplyhydroponics.com/24hr_digital_timer.htm , And program it to turn off once a week for 2-3 minutes . Hth , JimL -- +------------------------------------------------------------------+ | James W. Laferriere | System Techniques | Give me VMS | | Network&System Engineer | 2133 McCullam Ave | Give me Linux | | babydr at baby-dragons.com | Fairbanks, AK. 99701 | only on AXP | +------------------------------------------------------------------+ From Valdis.Kletnieks at vt.edu Mon Jun 23 15:29:59 2008 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 23 Jun 2008 16:29:59 -0400 Subject: EC2 and GAE means end of ip address reputation industry? (Re: Intrustion attempts from Amazon EC2 IPs) In-Reply-To: Your message of "Mon, 23 Jun 2008 14:28:04 EDT." <20080623182804.GC2693@hesketh.com> References: <764C3A66-CBE4-4FB9-B1A3-FBA6CD5F04B6@nosignal.org> <7d6a0cac0806221124o66a473e3vaf41539ab97fdee@mail.gmail.com> <20080623182804.GC2693@hesketh.com> Message-ID: <29351.1214252999@turing-police.cc.vt.edu> On Mon, 23 Jun 2008 14:28:04 EDT, Steven Champeon said: > Now, if the entire 'Net moved to a cloud computing model, I could agree > with Paul that this would be the end of IP reputation. But I'm only > aware of two such services (Amazon EC2 and Media Temple's > gridserver.com) in widespread use, so I haven't bothered to come up with > a new classification for them, and treat them as essentially dynamic > (with gridserver.com also classified as 'webhost'). One could argue that the "botnets for rent" business model is in more widespread use than either EC2 or gridserver... I'm unclear whether that statement needs a smiley or not... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From ross at kallisti.us Mon Jun 23 15:32:16 2008 From: ross at kallisti.us (Ross Vandegrift) Date: Mon, 23 Jun 2008 16:32:16 -0400 Subject: Techniques for passive traffic capturing Message-ID: <20080623203216.GC18464@kallisti.us> Hello everyone, Over the past two years, there's been a trend toward doing more and more analysis and reporting based on passive traffic analysis. We started out using SPAN sessions to produce an extra copy of all of our transit links for these purposes. But the Cisco limits of two SPAN sessions per device (on our platforms) is a major limitation. Does anyone have a better soultion for more flexible data collection? I've been thinking about a move to a system based on optical taps of each of the links. I'd aggregate these links into something like a 3750 and use remote-span VLANs to pass the traffic onto servers that sniffing on their interface on that 3750. Do products like the NetOptics Matrix Switches offer a substantial advantage? Comments or suggestions? -- Ross Vandegrift ross at kallisti.us "The good Christian should beware of mathematicians, and all those who make empty prophecies. The danger already exists that the mathematicians have made a covenant with the devil to darken the spirit and to confine man in the bonds of Hell." --St. Augustine, De Genesi ad Litteram, Book II, xviii, 37 From joelja at bogus.com Mon Jun 23 16:06:23 2008 From: joelja at bogus.com (Joel Jaeggli) Date: Mon, 23 Jun 2008 14:06:23 -0700 Subject: Cloud service [was: RE: EC2 and GAE means end of ip address reputation industry? (Re: Intrustion attempts from Amazon EC2 IPs)] In-Reply-To: References: <8F70CD2A-307B-46C5-A8F9-006B568F1827@cisco.com> <485FF755.9030605@bogus.com> Message-ID: <4860104F.6030109@bogus.com> Frank Bulk wrote: > Thanks. Even with TLS, the destination port (either 25 or 365) is > well-known, right, as is the source IP? And 587 though that's generally your customers, who are going authenticate. > At the minimum RBLs could be used > for that encrypted traffic. Yeah, given that that point you're basically filtering by ip again, you can do that with a bgp community. That's not really smtp filtering anymore. > Frank > > -----Original Message----- > From: Joel Jaeggli [mailto:joelja at bogus.com] > Sent: Monday, June 23, 2008 2:20 PM > To: frnkblk at iname.com > Cc: nanog at merit.edu > Subject: Re: Cloud service [was: RE: EC2 and GAE means end of ip address > reputation industry? (Re: Intrustion attempts from Amazon EC2 IPs)] > > > > dpi boxes from a number of vendors can do that sort of thing... whether > they can do it fast enough to be inline with your compute cloud is > another question entirely. > > That said the result is fairly perilous when rejecting a message > involves forging packets. and of course tls supporting mta's will be > opaque to the network traffic inspecting device. > > From ksimpson at mailchannels.com Mon Jun 23 17:22:47 2008 From: ksimpson at mailchannels.com (Ken Simpson) Date: Mon, 23 Jun 2008 15:22:47 -0700 Subject: Cloud service [was: RE: EC2 and GAE means end of ip addressreputation industry? (Re: Intrustion attempts from Amazon EC2 IPs)] Message-ID: <1B54275E-B80A-49A4-8CA1-44751FD3C88D@mailchannels.com> > On Mon, Jun 23, 2008 at 6:01 PM, Frank Bulk - iNAME iname.com> wrote: > > Is there a vendor that makes a product that perform spam/malware > filtering > > literally in the network, i.e. as a service provider, can I > provide spam > > filtering for the enterprises in my customer base by adding a > piece of > > network gear? I'm not aware of one today except those who provide > > enterprise-oriented gateways like SonicWall. > > Symantec Mail Security / Turntide > Mailchannels Traffic Control > > --srs BTW, we CAN do "in the cloud" email traffic shaping - on EC2, ironically. But also on your own equipment if that's your preference. Regards, Ken -- Ken Simpson CEO MailChannels - Reliable Email Delivery http://mailchannels.com 604 685 7488 tel From vixie at isc.org Mon Jun 23 19:03:20 2008 From: vixie at isc.org (Paul Vixie) Date: 24 Jun 2008 00:03:20 +0000 Subject: EC2 and GAE means end of ip address reputation industry? (Re: In-Reply-To: <29351.1214252999@turing-police.cc.vt.edu> References: <29351.1214252999@turing-police.cc.vt.edu> Message-ID: Valdis.Kletnieks at vt.edu writes: > One could argue that the "botnets for rent" business model is in more > widespread use than either EC2 or gridserver... > > I'm unclear whether that statement needs a smiley or not... i'd say that since EC2 won't be shut down when it's found out about, that you need a smiley. "widespread use" is too narrow a term. none of us expects white-hat e-commerce business to move into rented botnets, and rented botnets aren't all going to be in the same address space or ASN. -- Paul Vixie From nanog at daork.net Mon Jun 23 20:19:03 2008 From: nanog at daork.net (Nathan Ward) Date: Tue, 24 Jun 2008 13:19:03 +1200 Subject: Techniques for passive traffic capturing In-Reply-To: <20080623203216.GC18464@kallisti.us> References: <20080623203216.GC18464@kallisti.us> Message-ID: On 24/06/2008, at 8:32 AM, Ross Vandegrift wrote: > I've been thinking about a move to a system based on optical taps of > each of the links. I'd aggregate these links into something like a > 3750 and use remote-span VLANs to pass the traffic onto servers that > sniffing on their interface on that 3750. Do products like the > NetOptics Matrix Switches offer a substantial advantage? > > Comments or suggestions? I see little point in aggregating tapped traffic, unless you have only a small amount of it and you're doing it to save cost on monitoring network interfaces - but is that saved cost still a saving when you factor in the cost of the extra 3750s in the middle? I'd guess no. Depending on how well saturated your circuits are, get double- or quad- GE network cards (Intel make some fixed ones, there are others that take SFPs and fat GBICs) and plug them directly in to the optical taps. If you need your monitoring equipment a distance from the optical taps, use netoptic's regeneration taps, which split 70/30 and then amplify the 30 before sending to your equipment on a different floor/whatever. There are other vendors, I like netoptics because they have cute purple optical patch leads, provide per-tap specs as tested at the factory, and they all worked beautifully out of the box - another vendor had a 50% failure rate, I've forgotten who they were though. A PC with 4 GE optical ports is much simpler and probably more cost effective than doing remote span complications. Note that for a single GE link, you'd need 2GE of remote span backhaul (one GE in each direction). Matrix switches aren't useful for your case, as you're talking about monitoring for trending etc. I think. Matrix switches are good when you have lots of links, and want to be able to switch between them. Is the cost of matrix switch ports worth the saving in GE interfaces on PCs? Netoptics have taps that aggregate several links in to one monitoring feed. Not really cost effective when the cost of a single GE network interface for a PC is so low. The above is based on the assumption you're using PCs for monitoring, the economics of aggregating tap traffic may make more sense if you're using some fancy monitoring platform. If you find that you need lots of GE interfaces per PC or something, and are saturating the PCI bus, look at DAG cards from Endace. They're designed for passive monitoring, and will send you only headers and do BPF in hardware. I looked at these for a similar project, but didn't bother as it was cheaper to buy more PC chassis' and commodity GE cards. They can do 10GE monitoring, so if you need several 10GE's per chassis I'd recommend these. -- Nathan Ward From nanog at studio442.com.au Mon Jun 23 20:34:21 2008 From: nanog at studio442.com.au (Julien Goodwin) Date: Tue, 24 Jun 2008 11:34:21 +1000 Subject: Australian Co-Lo In-Reply-To: <20080623150435.GB29465@sprocket.mamista.net> References: <20080623150435.GB29465@sprocket.mamista.net> Message-ID: <48604F1D.8000806@studio442.com.au> On 24/06/08 01:04, Martin Barry wrote: > $quoted_author = "Bernard Becker" ; >> Looking for recommendations for carrier neutral co-lo facility for Melbourne >> Australia. Our searches so far seem to turn up sites either on Telstra or >> Optus affiliated co-lo facilities. We need to be in a carrier neutral space >> with access to any of the major providers. > > This was created by a SAGE-AU member in response to a similar request. > > http://maps.google.com/maps/ms?msa=0&msid=117984623075363696099.000439d39e1c7bd8d46c2&ie=UTF8&z=12 In addition to those there's the PIPE and AAPT http://www.pipenetworks.com/Telehousing/locations.shtml http://aaptbusiness.com.au/business/products/Hosting/Co2DlocationServices.cfm?o=214 Both are ISP's, but have extensive cross connections. We currently use AAPT (10+ racks in Richmond), and I've previously used Global Center and been happy with both. From frnkblk at iname.com Mon Jun 23 21:31:46 2008 From: frnkblk at iname.com (Frank Bulk - iNAME) Date: Mon, 23 Jun 2008 21:31:46 -0500 Subject: Cloud service [was: RE: EC2 and GAE means end of ip address reputation industry? (Re: Intrustion attempts from Amazon EC2 IPs)] In-Reply-To: <1B54275E-B80A-49A4-8CA1-44751FD3C88D@mailchannels.com> References: <1B54275E-B80A-49A4-8CA1-44751FD3C88D@mailchannels.com> Message-ID: Ken: Thanks for the info, but that still requires the domain owner to change their MX records. I was wondering if there was something that could literally be placed in the flow of traffic, like an FWSM in transparent mode. Frank -----Original Message----- From: Ken Simpson [mailto:ksimpson at mailchannels.com] Sent: Monday, June 23, 2008 5:23 PM To: nanog at nanog.org Subject: Re: Cloud service [was: RE: EC2 and GAE means end of ip addressreputation industry? (Re: Intrustion attempts from Amazon EC2 IPs)] > On Mon, Jun 23, 2008 at 6:01 PM, Frank Bulk - iNAME iname.com> wrote: > > Is there a vendor that makes a product that perform spam/malware > > filtering literally in the network, i.e. as a service provider, > > can I provide spam filtering for the enterprises in my customer > > base by adding a piece of network gear? I'm not aware of one > > today except those who provide enterprise-oriented gateways like > > SonicWall. > > Symantec Mail Security / Turntide > Mailchannels Traffic Control > > --srs BTW, we CAN do "in the cloud" email traffic shaping - on EC2, ironically. But also on your own equipment if that's your preference. Regards, Ken -- Ken Simpson CEO MailChannels - Reliable Email Delivery http://mailchannels.com 604 685 7488 tel From frnkblk at iname.com Mon Jun 23 21:35:49 2008 From: frnkblk at iname.com (Frank Bulk - iNAME) Date: Mon, 23 Jun 2008 21:35:49 -0500 Subject: Cloud service [was: RE: EC2 and GAE means end of ip address reputation industry? (Re: Intrustion attempts from Amazon EC2 IPs)] In-Reply-To: <4860104F.6030109@bogus.com> References: <8F70CD2A-307B-46C5-A8F9-006B568F1827@cisco.com> <485FF755.9030605@bogus.com> <4860104F.6030109@bogus.com> Message-ID: Right, port 587 would require SMTP authentication. I'm no routing expert, but can tens of thousands of /32s be excluded using BGP communities? I don't know if spammers are going to be using TLS in a big way soon, though I'll admit I've not measured. As long TLS usage is low, examining TCP port 25 traffic would likely be effective without redirecting SMTP traffic and making it effective for all customers downstream. Frank -----Original Message----- From: Joel Jaeggli [mailto:joelja at bogus.com] Sent: Monday, June 23, 2008 4:06 PM To: frnkblk at iname.com Cc: nanog at merit.edu Subject: Re: Cloud service [was: RE: EC2 and GAE means end of ip address reputation industry? (Re: Intrustion attempts from Amazon EC2 IPs)] Frank Bulk wrote: > Thanks. Even with TLS, the destination port (either 25 or 365) is > well-known, right, as is the source IP? And 587 though that's generally your customers, who are going authenticate. > At the minimum RBLs could be used > for that encrypted traffic. Yeah, given that that point you're basically filtering by ip again, you can do that with a bgp community. That's not really smtp filtering anymore. > Frank > > -----Original Message----- > From: Joel Jaeggli [mailto:joelja at bogus.com] > Sent: Monday, June 23, 2008 2:20 PM > To: frnkblk at iname.com > Cc: nanog at merit.edu > Subject: Re: Cloud service [was: RE: EC2 and GAE means end of ip address > reputation industry? (Re: Intrustion attempts from Amazon EC2 IPs)] > > > > dpi boxes from a number of vendors can do that sort of thing... whether > they can do it fast enough to be inline with your compute cloud is > another question entirely. > > That said the result is fairly perilous when rejecting a message > involves forging packets. and of course tls supporting mta's will be > opaque to the network traffic inspecting device. > > From ops.lists at gmail.com Mon Jun 23 21:43:50 2008 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Tue, 24 Jun 2008 08:13:50 +0530 Subject: Cloud service [was: RE: EC2 and GAE means end of ip addressreputation industry? (Re: Intrustion attempts from Amazon EC2 IPs)] In-Reply-To: <70D072392E56884193E3D2DE09C097A9F24D@pascal.zaphodb.org> References: <8F70CD2A-307B-46C5-A8F9-006B568F1827@cisco.com> <70D072392E56884193E3D2DE09C097A9F24D@pascal.zaphodb.org> Message-ID: On Mon, Jun 23, 2008 at 11:14 PM, Tomas L. Byrnes wrote: > Barracuda, or you could build the exact same thing using OSS. > > Procmail, Spamassasin, ClamAV, and your choice of RBLs (or use > karmashpere to custom roll a hybrid one). Hate to point out the obvious, but ... That isnt "network gear" as such. It is an appliance that'll require repointing of MX records srs From d.thomas at its.uq.edu.au Mon Jun 23 21:54:43 2008 From: d.thomas at its.uq.edu.au (Danny Thomas) Date: Tue, 24 Jun 2008 12:54:43 +1000 Subject: APNIC dns glitch ? Message-ID: <9EE8C569-7346-4311-95E6-D7AE9DEA6596@its.uq.edu.au> I thought I'd sent this a couple of hours ago APNIC are aware of the problem and things have partially recovered though the arin and ripe name-servers still SERVFAIL the second run of our delegation-checking script this morning started complaining about our 203.in-addr zones and it seems there is an issue with apnic.net the delegation shows 4 entries spread across 3 domains which is good, albeit all are under the same registry. Sometimes cumin.apnic.net and innie.apnic.net. are not reachable, or give a REFUSED response, or give a response with no A records nor any additional section. Unfortunately both tinnie.arin.net and ns-sec.ripe.net return SERVFAIL, as if they had not been able to perform a zone transfer for a while (assuming AXFR is the replication mechanism). I don't have ipv6 connectivity, but that's not likely to help. I don't think this will significantly impact reverse dns lookups as I think the dns is spread across other RIR's seems there was a different type of issue in May http://www.bauani.org/thinkings/2008/05/issue-with-apnic-dns-nameservers.html Danny Thomas # dig @I.GTLD-SERVERS.net apnic.net +norec ; <<>> DiG 9.4.2 <<>> @I.GTLD-SERVERS.net apnic.net +norec ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5460 ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 5 ;; QUESTION SECTION: ;apnic.net. IN A ;; AUTHORITY SECTION: apnic.net. 172800 IN NS cumin.apnic.net. apnic.net. 172800 IN NS ns-sec.ripe.net. apnic.net. 172800 IN NS tinnie.apnic.net. apnic.net. 172800 IN NS tinnie.arin.net. ;; ADDITIONAL SECTION: cumin.apnic.net. 172800 IN A 202.12.29.59 ns-sec.ripe.net. 172800 IN A 193.0.0.196 ns-sec.ripe.net. 172800 IN AAAA 2001:610:240:0:53::4 tinnie.apnic.net. 172800 IN A 202.12.29.60 tinnie.arin.net. 172800 IN A 168.143.101.18 dig @202.12.29.59 apnic.net any +norec ; <<>> DiG 9.4.2 <<>> @202.12.29.59 apnic.net any +norec ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 33930 ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 # dig @202.12.29.59 apnic.net any ; <<>> DiG 9.4.2 <<>> @202.12.29.59 apnic.net any ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40744 ;; flags: qr aa rd; QUERY: 1, ANSWER: 8, AUTHORITY: 0, ADDITIONAL: 0 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;apnic.net. IN ANY ;; ANSWER SECTION: apnic.net. 3600 IN SOA cumin.apnic.net. dns-admin.apnic.net. 2008062101 3600 1800 604800 3600 apnic.net. 3600 IN NS cumin.apnic.net. apnic.net. 3600 IN NS ns-sec.ripe.net. apnic.net. 3600 IN NS tinnie.arin.net. apnic.net. 3600 IN NS tinnie.apnic.net. apnic.net. 3600 IN MX 10 kombu.apnic.net. apnic.net. 3600 IN MX 25 karashi.apnic.net. apnic.net. 3600 IN MX 35 fennel.apnic.net. ;; Query time: 3 msec ;; SERVER: 202.12.29.59#53(202.12.29.59) ;; WHEN: Tue Jun 24 10:35:13 2008 ;; MSG SIZE rcvd: 235 dig @193.0.0.196 apnic.net any +norec ; <<>> DiG 9.4.2 <<>> @193.0.0.196 apnic.net any +norec ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 37668 ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;apnic.net. IN ANY # dig @168.143.101.18 apnic.net ns ; <<>> DiG 9.4.2 <<>> @168.143.101.18 apnic.net ns ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 41014 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;apnic.net. IN NS From kkadow+pottedmeatproduct at gmail.com Mon Jun 23 22:00:06 2008 From: kkadow+pottedmeatproduct at gmail.com (Kevin Kadow) Date: Mon, 23 Jun 2008 22:00:06 -0500 Subject: Techniques for passive traffic capturing In-Reply-To: <20080623203216.GC18464@kallisti.us> References: <20080623203216.GC18464@kallisti.us> Message-ID: We started out with SPAN ports, then moved on to Netoptics taps. Lately we've been using a combination of Cisco Netflow (from remote routers), and native Argus flows (from local taps) where we need more details. Flows are useful to answer "What happened X minutes/hours/days ago?", and where you do not need/want to capture full packet bodies (though with Argus you can choose whether to include payload data). http://qosient.com/argus/ From adrian at creative.net.au Mon Jun 23 22:10:37 2008 From: adrian at creative.net.au (Adrian Chadd) Date: Tue, 24 Jun 2008 11:10:37 +0800 Subject: Cloud service [was: RE: EC2 and GAE means end of ip addressreputation industry? (Re: Intrustion attempts from Amazon EC2 IPs)] In-Reply-To: References: <8F70CD2A-307B-46C5-A8F9-006B568F1827@cisco.com> <70D072392E56884193E3D2DE09C097A9F24D@pascal.zaphodb.org> Message-ID: <20080624031037.GT3332@skywalker.creative.net.au> On Tue, Jun 24, 2008, Suresh Ramasubramanian wrote: > Hate to point out the obvious, but ... That isnt "network gear" as such. > > It is an appliance that'll require repointing of MX records Please don't tell my test kit at home; Cisco WCCPv2 redirects TCP/25 as easy as it does TCP/80(*1). No MX rejiggery required. Adrian *1: unless you're the lucky owner of specially crafted gems like the Catalyst 3550 - WCCPv2 is limited to port 80 only .. From hank at efes.iucc.ac.il Mon Jun 23 22:32:10 2008 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Tue, 24 Jun 2008 06:32:10 +0300 (IDT) Subject: Happy 25th birthday for DNS Message-ID: http://www.wired.com/science/discoveries/news/2008/06/dayintech_0623 June 23, 1983: DNS Test Sets Stage for Internet Growth 1983: Paul Mockapetris and Jon Postel run the first successful test of the automated, distributed Domain Name System. DNS will lay the foundation for the massive expansion, popularization and commercialization of the internet. ... Thanks Paul & Jon! -Hank From morrowc.lists at gmail.com Mon Jun 23 22:45:14 2008 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 23 Jun 2008 23:45:14 -0400 Subject: Cloud service [was: RE: EC2 and GAE means end of ip address reputation industry? (Re: Intrustion attempts from Amazon EC2 IPs)] In-Reply-To: References: <1B54275E-B80A-49A4-8CA1-44751FD3C88D@mailchannels.com> Message-ID: <75cb24520806232045j3cd8b15bp2c03eb55deee29d5@mail.gmail.com> On Mon, Jun 23, 2008 at 10:31 PM, Frank Bulk - iNAME wrote: > Ken: > > Thanks for the info, but that still requires the domain owner to change > their MX records. I was wondering if there was something that could > literally be placed in the flow of traffic, like an FWSM in transparent > mode. > That probably depends a lot on the topology in question... Doing it on 'ethernet' is far different from doing it on T1 over ATM or channelized oc-48... A Checkpoint FW can do this sort of thing with a 'security server' (though performance is certainly a question...). I think you're also always stuck in a store-and-forward mode so 'on the wire' isn't really helpful for SMTP, often you can't make a decision about an email without getting a large portion of it down, so snuffing connections mid-stream isn't going to help your email infra very much :( -Chris > Frank > > -----Original Message----- > From: Ken Simpson [mailto:ksimpson at mailchannels.com] > Sent: Monday, June 23, 2008 5:23 PM > To: nanog at nanog.org > Subject: Re: Cloud service [was: RE: EC2 and GAE means end of ip > addressreputation industry? (Re: Intrustion attempts from Amazon EC2 IPs)] > >> On Mon, Jun 23, 2008 at 6:01 PM, Frank Bulk - iNAME > iname.com> wrote: >> > Is there a vendor that makes a product that perform spam/malware >> > filtering literally in the network, i.e. as a service provider, >> > can I provide spam filtering for the enterprises in my customer >> > base by adding a piece of network gear? I'm not aware of one >> > today except those who provide enterprise-oriented gateways like >> > SonicWall. >> >> Symantec Mail Security / Turntide >> Mailchannels Traffic Control >> >> --srs > > BTW, we CAN do "in the cloud" email traffic shaping - on EC2, > ironically. But also on your own equipment if that's your preference. > > Regards, > Ken > > -- > Ken Simpson > CEO > > MailChannels - Reliable Email Delivery > http://mailchannels.com > 604 685 7488 tel > > > > > > > > From joelja at bogus.com Mon Jun 23 22:47:17 2008 From: joelja at bogus.com (Joel Jaeggli) Date: Mon, 23 Jun 2008 20:47:17 -0700 Subject: Cloud service [was: RE: EC2 and GAE means end of ip address reputation industry? (Re: Intrustion attempts from Amazon EC2 IPs)] In-Reply-To: References: <8F70CD2A-307B-46C5-A8F9-006B568F1827@cisco.com> <485FF755.9030605@bogus.com> <4860104F.6030109@bogus.com> Message-ID: <48606E45.8000100@bogus.com> Frank Bulk - iNAME wrote: > Right, port 587 would require SMTP authentication. > > I'm no routing expert, but can tens of thousands of /32s be excluded using > BGP communities? The sort of depends on how many fib entries you want to burn on not forwarding traffic... the argument in this thread however (which I more or less subcribe to) is that in the future an ip address is insufficient granularity for mail /badness filtering. Frankly it's not just computer clouds but also address pressure, a million hosts behind a /24 are going to be rather hard to pick out one at a time. ultimately the ability blackhole based on something as gross as the source ip address is going to be insufficiently fine grained for devices that must accept connections from the internet at large. > I don't know if spammers are going to be using TLS in a big way soon, though > I'll admit I've not measured. A couple years ago, when my former employer turned on tls support on the outwardly facing mta's about 10% of our incoming smtp connections immediately started using it after ehlo. That's not something I've kept track of but I imagine it's an issue. > As long TLS usage is low, examining TCP port > 25 traffic would likely be effective without redirecting SMTP traffic and > making it effective for all customers downstream. > > Frank > > -----Original Message----- > From: Joel Jaeggli [mailto:joelja at bogus.com] > Sent: Monday, June 23, 2008 4:06 PM > To: frnkblk at iname.com > Cc: nanog at merit.edu > Subject: Re: Cloud service [was: RE: EC2 and GAE means end of ip address > reputation industry? (Re: Intrustion attempts from Amazon EC2 IPs)] > > Frank Bulk wrote: >> Thanks. Even with TLS, the destination port (either 25 or 365) is >> well-known, right, as is the source IP? > > And 587 though that's generally your customers, who are going authenticate. > >> At the minimum RBLs could be used >> for that encrypted traffic. > > Yeah, given that that point you're basically filtering by ip again, you > can do that with a bgp community. That's not really smtp filtering anymore. > >> Frank >> >> -----Original Message----- >> From: Joel Jaeggli [mailto:joelja at bogus.com] >> Sent: Monday, June 23, 2008 2:20 PM >> To: frnkblk at iname.com >> Cc: nanog at merit.edu >> Subject: Re: Cloud service [was: RE: EC2 and GAE means end of ip address >> reputation industry? (Re: Intrustion attempts from Amazon EC2 IPs)] >> >> >> >> dpi boxes from a number of vendors can do that sort of thing... whether >> they can do it fast enough to be inline with your compute cloud is >> another question entirely. >> >> That said the result is fairly perilous when rejecting a message >> involves forging packets. and of course tls supporting mta's will be >> opaque to the network traffic inspecting device. >> >> > > From Joel.Snyder at Opus1.COM Mon Jun 23 23:32:18 2008 From: Joel.Snyder at Opus1.COM (Joel M Snyder) Date: Mon, 23 Jun 2008 21:32:18 -0700 Subject: Cloud service [was: RE: EC2 and GAE means end of ip In-Reply-To: References: Message-ID: <486078D2.5060404@opus1.com> > Date: Mon, 23 Jun 2008 20:47:17 -0700 > From: Joel Jaeggli > Subject: Re: Cloud service [was: RE: EC2 and GAE means end of ip > address reputation industry? (Re: Intrustion attempts from Amazon EC2 > IPs)] > To: frnkblk at iname.com > Cc: nanog at merit.edu > Message-ID: <48606E45.8000100 at bogus.com> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > the argument in this thread however (which I more or less subcribe to) > is that in the future an ip address is insufficient granularity for mail > /badness filtering. Frankly it's not just computer clouds but also > address pressure, a million hosts behind a /24 are going to be rather > hard to pick out one at a time. ultimately the ability blackhole based > on something as gross as the source ip address is going to be > insufficiently fine grained for devices that must accept connections > from the internet at large. Ummm, probably not as big of a problem as you might think it is. From the point of view of an email administrator, those million hosts behind the /24 are all going to be on the Spamhaus PBL (policy block list) and it doesn't matter whether there are 10 or 10,000 or 10,000,000 hosts if the ISP has said "these are residential subscribers and they shouldn't be sending mail." Whether you believe in PBL or not, generally, it's going to be end users who are clustered behind those NATs more so than MTAs. Similarly, I don't see a huge incentive for someone to move their MTA to services like EC2--although anti-spam services 'in the cloud' like Postini are very popular, but that's a different issue. In our month-by-month anti-spam testing over the past 3 years, the number of unique email senders (MTAs, not individuals mind you) has actually dropped a bit; if you use the domain name as exposed in HELO/EHLO, it's dropped even more. While there will always be small MTAs out there handling small numbers of people, the trend has been to throttle that mail through larger systems. Sometimes this is done transparently/semi-transparently by the ISP ("you will send your mail through our SMTP server") using either a simple port 25 block or something like transparent destination NAT/WCCP. In other cases, this happens because small companies are discovering that their oh-so-exciting Exchange server is more of a pain in the ass than using commercial Gmail or whatever. SMTP is a special case in this discussion, I'll immediately admit. The number of hosts offering up web pages (assuming you want to filter for malware of some sort) is going nothing but up. Reputation services will be more challenged in that environment than in the SMTP environment. > >> I don't know if spammers are going to be using TLS in a big way soon, though >> I'll admit I've not measured. > > A couple years ago, when my former employer turned on tls support on the > outwardly facing mta's about 10% of our incoming smtp connections > immediately started using it after ehlo. That's not something I've kept > track of but I imagine it's an issue. Today's number for delivery using SSL by our mail cluster is 7% of just shy of 80K messages. Goes up, goes down, but definitely non-zero. > >> As long TLS usage is low, examining TCP port >> 25 traffic would likely be effective without redirecting SMTP traffic and >> making it effective for all customers downstream. That actually turns out to be a non-problem from the SMTP point of view. A "mean" ISP could simply intercept the response to EHLO and drop out the TLS capability string. A "nice" ISP could simply make up a certificate on the fly. Since SMTP senders don't have a GUI box to click during the SMTP transaction when a certificate doesn't check out, most (read as: all configured with default settings) of them simply send anyway even if the certificate smells like week-old fish. Put it another way: I ran (accidentally) for two years with an expired certificate on one of our mail servers and didn't get a single peep about misbehaving mail. But most of this discussion has been about reputation services, and of course those operate beautifully with or without TLS in the SMTP case. jms -- Joel M Snyder, 1404 East Lind Road, Tucson, AZ, 85719 Senior Partner, Opus One Phone: +1 520 324 0494 jms at Opus1.COM http://www.opus1.com/jms From frnkblk at iname.com Mon Jun 23 23:44:37 2008 From: frnkblk at iname.com (Frank Bulk - iNAME) Date: Mon, 23 Jun 2008 23:44:37 -0500 Subject: Cloud service [was: RE: EC2 and GAE means end of ip address reputation industry? (Re: Intrustion attempts from Amazon EC2 IPs)] In-Reply-To: <75cb24520806232045j3cd8b15bp2c03eb55deee29d5@mail.gmail.com> References: <1B54275E-B80A-49A4-8CA1-44751FD3C88D@mailchannels.com> <75cb24520806232045j3cd8b15bp2c03eb55deee29d5@mail.gmail.com> Message-ID: Source IP blocking makes up a large portion of today's spam arrest approach, so we shouldn't discount the CPU benefits of that approach too quickly. I'm not sure where today's technology is in regards for caching the first 1 to 10kB of a session....once enough information is garnered to block, issue TCP RSETs. If it's good, free the contents of the cache. Frank -----Original Message----- From: christopher.morrow at gmail.com [mailto:christopher.morrow at gmail.com] On Behalf Of Christopher Morrow Sent: Monday, June 23, 2008 10:45 PM To: frnkblk at iname.com Cc: Ken Simpson; nanog at nanog.org Subject: Re: Cloud service [was: RE: EC2 and GAE means end of ip address reputation industry? (Re: Intrustion attempts from Amazon EC2 IPs)] On Mon, Jun 23, 2008 at 10:31 PM, Frank Bulk - iNAME wrote: > Ken: > > Thanks for the info, but that still requires the domain owner to change > their MX records. I was wondering if there was something that could > literally be placed in the flow of traffic, like an FWSM in transparent > mode. > That probably depends a lot on the topology in question... Doing it on 'ethernet' is far different from doing it on T1 over ATM or channelized oc-48... A Checkpoint FW can do this sort of thing with a 'security server' (though performance is certainly a question...). I think you're also always stuck in a store-and-forward mode so 'on the wire' isn't really helpful for SMTP, often you can't make a decision about an email without getting a large portion of it down, so snuffing connections mid-stream isn't going to help your email infra very much :( -Chris > Frank > > -----Original Message----- > From: Ken Simpson [mailto:ksimpson at mailchannels.com] > Sent: Monday, June 23, 2008 5:23 PM > To: nanog at nanog.org > Subject: Re: Cloud service [was: RE: EC2 and GAE means end of ip > addressreputation industry? (Re: Intrustion attempts from Amazon EC2 IPs)] > >> On Mon, Jun 23, 2008 at 6:01 PM, Frank Bulk - iNAME > iname.com> wrote: >> > Is there a vendor that makes a product that perform spam/malware >> > filtering literally in the network, i.e. as a service provider, >> > can I provide spam filtering for the enterprises in my customer >> > base by adding a piece of network gear? I'm not aware of one >> > today except those who provide enterprise-oriented gateways like >> > SonicWall. >> >> Symantec Mail Security / Turntide >> Mailchannels Traffic Control >> >> --srs > > BTW, we CAN do "in the cloud" email traffic shaping - on EC2, > ironically. But also on your own equipment if that's your preference. > > Regards, > Ken > > -- > Ken Simpson > CEO > > MailChannels - Reliable Email Delivery > http://mailchannels.com > 604 685 7488 tel > > > > > > > > From mcdonald.richards at gmail.com Tue Jun 24 00:02:39 2008 From: mcdonald.richards at gmail.com (McDonald Richards) Date: Tue, 24 Jun 2008 15:02:39 +1000 Subject: Australian Co-Lo In-Reply-To: <48604F1D.8000806@studio442.com.au> References: <20080623150435.GB29465@sprocket.mamista.net> <48604F1D.8000806@studio442.com.au> Message-ID: <8bde567b0806232202g123922bfqbe386e3dac95b83@mail.gmail.com> AAPT are pretty far from being carrier neutral these days.... On Tue, Jun 24, 2008 at 11:34 AM, Julien Goodwin wrote: > On 24/06/08 01:04, Martin Barry wrote: > > $quoted_author = "Bernard Becker" ; > >> Looking for recommendations for carrier neutral co-lo facility for > Melbourne > >> Australia. Our searches so far seem to turn up sites either on Telstra > or > >> Optus affiliated co-lo facilities. We need to be in a carrier neutral > space > >> with access to any of the major providers. > > > > This was created by a SAGE-AU member in response to a similar request. > > > > > http://maps.google.com/maps/ms?msa=0&msid=117984623075363696099.000439d39e1c7bd8d46c2&ie=UTF8&z=12 > > In addition to those there's the PIPE and AAPT > > http://www.pipenetworks.com/Telehousing/locations.shtml > > > http://aaptbusiness.com.au/business/products/Hosting/Co2DlocationServices.cfm?o=214 > > Both are ISP's, but have extensive cross connections. > > We currently use AAPT (10+ racks in Richmond), and I've previously used > Global Center and been happy with both. > > From hannigan at verneglobal.com Tue Jun 24 05:04:43 2008 From: hannigan at verneglobal.com (Martin Hannigan) Date: Tue, 24 Jun 2008 10:04:43 -0000 Subject: SV: APNIC dns glitch ? References: <9EE8C569-7346-4311-95E6-D7AE9DEA6596@its.uq.edu.au> Message-ID: APNIC made an announcement on an operator list this morning that is probably relevant to your issue: +++include Some services provided by APNIC were unavailable this morning due to a disruption to our international connectivity. This occurred between 07:00 Australian Eastern Standard Time (AEST) and approximately 11:20 AEST. Major services affected were: - www.apnic.net - MyAPNIC - email - Whois - Reverse DNS (partial) Services provided by ns3.apnic.net and sec3.apnic.net remained resolvable. Unfortunately, we were not able to announce this situation when it occurred due to the loss of connectivity. +++end -- Martin Hannigan hannigan at verneglobal.com Verne Global http://www.verneglobal.com Keflavik, Iceland ________________________________ Fra: Danny Thomas [mailto:d.thomas at its.uq.edu.au] Sendt: ma 23-jun-08 22:54 Til: nanog at merit.edu Emne: APNIC dns glitch ? I thought I'd sent this a couple of hours ago APNIC are aware of the problem and things have partially recovered though the arin and ripe name-servers still SERVFAIL the second run of our delegation-checking script this morning started complaining about our 203.in-addr zones and it seems there is an issue with apnic.net the delegation shows 4 entries spread across 3 domains which is good, albeit all are under the same registry. Sometimes cumin.apnic.net and innie.apnic.net. are not reachable, or give a REFUSED response, or give a response with no A records nor any additional section. Unfortunately both tinnie.arin.net and ns-sec.ripe.net return SERVFAIL, as if they had not been able to perform a zone transfer for a while (assuming AXFR is the replication mechanism). I don't have ipv6 connectivity, but that's not likely to help. I don't think this will significantly impact reverse dns lookups as I think the dns is spread across other RIR's seems there was a different type of issue in May http://www.bauani.org/thinkings/2008/05/issue-with-apnic-dns-nameservers.html Danny Thomas # dig @I.GTLD-SERVERS.net apnic.net +norec ; <<>> DiG 9.4.2 <<>> @I.GTLD-SERVERS.net apnic.net +norec ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5460 ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 5 ;; QUESTION SECTION: ;apnic.net. IN A ;; AUTHORITY SECTION: apnic.net. 172800 IN NS cumin.apnic.net. apnic.net. 172800 IN NS ns-sec.ripe.net. apnic.net. 172800 IN NS tinnie.apnic.net. apnic.net. 172800 IN NS tinnie.arin.net. ;; ADDITIONAL SECTION: cumin.apnic.net. 172800 IN A 202.12.29.59 ns-sec.ripe.net. 172800 IN A 193.0.0.196 ns-sec.ripe.net. 172800 IN AAAA 2001:610:240:0:53::4 tinnie.apnic.net. 172800 IN A 202.12.29.60 tinnie.arin.net. 172800 IN A 168.143.101.18 dig @202.12.29.59 apnic.net any +norec ; <<>> DiG 9.4.2 <<>> @202.12.29.59 apnic.net any +norec ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 33930 ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 # dig @202.12.29.59 apnic.net any ; <<>> DiG 9.4.2 <<>> @202.12.29.59 apnic.net any ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40744 ;; flags: qr aa rd; QUERY: 1, ANSWER: 8, AUTHORITY: 0, ADDITIONAL: 0 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;apnic.net. IN ANY ;; ANSWER SECTION: apnic.net. 3600 IN SOA cumin.apnic.net. dns-admin.apnic.net. 2008062101 3600 1800 604800 3600 apnic.net. 3600 IN NS cumin.apnic.net. apnic.net. 3600 IN NS ns-sec.ripe.net. apnic.net. 3600 IN NS tinnie.arin.net. apnic.net. 3600 IN NS tinnie.apnic.net. apnic.net. 3600 IN MX 10 kombu.apnic.net. apnic.net. 3600 IN MX 25 karashi.apnic.net. apnic.net. 3600 IN MX 35 fennel.apnic.net. ;; Query time: 3 msec ;; SERVER: 202.12.29.59#53(202.12.29.59) ;; WHEN: Tue Jun 24 10:35:13 2008 ;; MSG SIZE rcvd: 235 dig @193.0.0.196 apnic.net any +norec ; <<>> DiG 9.4.2 <<>> @193.0.0.196 apnic.net any +norec ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 37668 ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;apnic.net. IN ANY # dig @168.143.101.18 apnic.net ns ; <<>> DiG 9.4.2 <<>> @168.143.101.18 apnic.net ns ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 41014 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;apnic.net. IN NS From ksimpson at mailchannels.com Tue Jun 24 08:37:34 2008 From: ksimpson at mailchannels.com (Ken Simpson) Date: Tue, 24 Jun 2008 06:37:34 -0700 Subject: Cloud service [was: RE: EC2 and GAE means end of ip address reputation industry? (Re: Intrustion attempts from Amazon EC2 IPs)] In-Reply-To: References: <1B54275E-B80A-49A4-8CA1-44751FD3C88D@mailchannels.com> <75cb24520806232045j3cd8b15bp2c03eb55deee29d5@mail.gmail.com> Message-ID: > Source IP blocking makes up a large portion of today's spam arrest > approach, > so we shouldn't discount the CPU benefits of that approach too > quickly. > > I'm not sure where today's technology is in regards for caching the > first 1 > to 10kB of a session....once enough information is garnered to > block, issue > TCP RSETs. If it's good, free the contents of the cache. What's your interest in mopping up spam in the middle of the network? Usually spam is viewed as a leaf-node problem (much to the chagrin of receivers, actually). Regards, Ken -- Ken Simpson CEO MailChannels - Reliable Email Delivery http://mailchannels.com 604 685 7488 tel From ross at kallisti.us Tue Jun 24 09:22:04 2008 From: ross at kallisti.us (Ross Vandegrift) Date: Tue, 24 Jun 2008 10:22:04 -0400 Subject: Techniques for passive traffic capturing In-Reply-To: References: <20080623203216.GC18464@kallisti.us> Message-ID: <20080624142204.GB25708@kallisti.us> On Mon, Jun 23, 2008 at 10:00:06PM -0500, Kevin Kadow wrote: > We started out with SPAN ports, then moved on to Netoptics taps. > > Lately we've been using a combination of Cisco Netflow (from remote routers), > and native Argus flows (from local taps) where we need more details. > > Flows are useful to answer "What happened X minutes/hours/days ago?", > and where you do not need/want to capture full packet bodies > (though with Argus you can choose whether to include payload data). > > http://qosient.com/argus/ Cool - good to know that the Netoptics gear is good. Seems like there's a few resounding approvals of them. Netflow would be lovely to export from our border routers. Unfortunately, we are somewhat married to the 6500 platform which has absolutely awful netflow support. Very small TCAM, export is CPU expensive, and sampling makes both problems worse. So a mirrored copy of the transit link is being sent to a pmacct box for flow generation. -- Ross Vandegrift ross at kallisti.us "The good Christian should beware of mathematicians, and all those who make empty prophecies. The danger already exists that the mathematicians have made a covenant with the devil to darken the spirit and to confine man in the bonds of Hell." --St. Augustine, De Genesi ad Litteram, Book II, xviii, 37 From darden at armc.org Tue Jun 24 09:28:12 2008 From: darden at armc.org (Darden, Patrick S.) Date: Tue, 24 Jun 2008 10:28:12 -0400 Subject: easy way to scan for issues with path mtu discovery? Message-ID: Hi all, Does anyone know of an easy way to scan for issues with path mtu discovery along a hop path? E.g. if you think someone is ICMP black-holing along a route, or even on the endpoint host, could you use some obscure nmap flag to find out for sure, and also to identify the offending hop/router/host? What tool would you use to test for this, and how would you do such a test? Is there any probing tool that does checks like this automatically? Seems to me this happens often enough that someone has probably already figured it out, so I am trying not to reinvent the wheel. All I can think of would be to handcraft packets of steadily increasing sizes and look for replies from each hop on the route (which would be laborious at best). Google has not been kind to my researches so far. I appreciate any help! --Patrick Darden From if at xip.at Tue Jun 24 09:40:06 2008 From: if at xip.at (Ingo Flaschberger) Date: Tue, 24 Jun 2008 16:40:06 +0200 (CEST) Subject: easy way to scan for issues with path mtu discovery? In-Reply-To: References: Message-ID: Dear Patrick, > Does anyone know of an easy way to scan for issues with path mtu > discovery along a hop path? E.g. if you think someone is ICMP > black-holing along a route, or even on the endpoint host, could you use > some obscure nmap flag to find out for sure, and also to identify the > offending hop/router/host? What tool would you use to test for this, > and how would you do such a test? Is there any probing tool that does > checks like this automatically? > > Seems to me this happens often enough that someone has probably already > figured it out, so I am trying not to reinvent the wheel. All I can > think of would be to handcraft packets of steadily increasing sizes and > look for replies from each hop on the route (which would be laborious at > best). Google has not been kind to my researches so far. If you have a cisco router: ping Protocol [ip]: Target IP address: x.x.x.x Repeat count [5]: Datagram size [100]: 1500 Timeout in seconds [2]: 1 Extended commands [n]: y Source address or interface: Type of service [0]: Set DF bit in IP header? [no]: yes Validate reply data? [no]: yes Data pattern [0xABCD]: Loose, Strict, Record, Timestamp, Verbose[none]: Sweep range of sizes [n]: y Sweep min size [36]: Sweep max size [18024]: 1500 Sweep interval [1]: Kind regards, Ingo Flaschberger From justin at justinshore.com Tue Jun 24 09:42:33 2008 From: justin at justinshore.com (Justin Shore) Date: Tue, 24 Jun 2008 09:42:33 -0500 Subject: Techniques for passive traffic capturing In-Reply-To: <20080623203216.GC18464@kallisti.us> References: <20080623203216.GC18464@kallisti.us> Message-ID: <486107D9.1030104@justinshore.com> I stumbled across these last night. http://www.dovebid.com/assets/display.asp?ItemID=cne11811 I don't know anything about them and haven't done any research. The auction description would however lead me to believe that they might be useful in this case. There are many of them listed in the main auction catalog. Justin Ross Vandegrift wrote: > Hello everyone, > > Over the past two years, there's been a trend toward doing more and > more analysis and reporting based on passive traffic analysis. > > We started out using SPAN sessions to produce an extra copy of all of > our transit links for these purposes. But the Cisco limits of two > SPAN sessions per device (on our platforms) is a major limitation. > > Does anyone have a better soultion for more flexible data collection? > > I've been thinking about a move to a system based on optical taps of > each of the links. I'd aggregate these links into something like a > 3750 and use remote-span VLANs to pass the traffic onto servers that > sniffing on their interface on that 3750. Do products like the > NetOptics Matrix Switches offer a substantial advantage? > > Comments or suggestions? > > From ross at kallisti.us Tue Jun 24 09:44:33 2008 From: ross at kallisti.us (Ross Vandegrift) Date: Tue, 24 Jun 2008 10:44:33 -0400 Subject: Techniques for passive traffic capturing In-Reply-To: References: <20080623203216.GC18464@kallisti.us> Message-ID: <20080624144433.GC25708@kallisti.us> On Tue, Jun 24, 2008 at 01:19:03PM +1200, Nathan Ward wrote: > I see little point in aggregating tapped traffic, unless you have only > a small amount of it and you're doing it to save cost on monitoring > network interfaces - but is that saved cost still a saving when you > factor in the cost of the extra 3750s in the middle? I'd guess no. Thanks for all the info Nathan - lots of good leads in your email. Let me include some more information. The problem is finding a way to multiplex that traffic from the optical tap to multiple things that want to peek at it. The remote-span trick solves that, as well as integrating media converters. 3750 is nice since you can stack em up and mix/match the SFP and copper ports. For example - we have an FCP box from Internap. It wants to see mirrored traffic so it can watch for TCP setup problems and try to find blackholes. It takes 10G feeds of aggregated transit links. Then, we want to do some passive IDS analysis. But snort can only really only handle 600-800Mbps before it starts saturating CPU (not multithreaded...) - so one collector per gigE transit seems logical. We'd like to generate flow data out of our forwarding plane since we use 6500s to pull in border transit links. The Netflow on those boxes is terrible. pmacct does a much better job, but it needs to see all the traffic out of band. > Note that for a single GE link, you'd need 2GE of remote span backhaul > (one GE in each direction). We're mostly a content network, very few eyeballs. Our ingress traffic is negligable compared to egress, which makes the problem easier. > Matrix switches aren't useful for your case, as you're talking about > monitoring for trending etc. I think. Matrix switches are good when > you have lots of links, and want to be able to switch between them. Is > the cost of matrix switch ports worth the saving in GE interfaces on > PCs? I guess what made me look at them is their ability to multiplex the stream of data. Take it from an optical tap, spit the same data out of multiple ports. The remote-span trick seems to do the same thing, so I'm wondering where the gotcha is. If there's an advantage to using something like the Matrix switches, I'd love to know that now. > The above is based on the assumption you're using PCs for monitoring, > the economics of aggregating tap traffic may make more sense if you're > using some fancy monitoring platform. Yea - the fact that we have both makes the aggregation method look good. The FCP takes 10G aggregated feeds. The PCs will want single gig views of the transit links. > If you find that you need lots of GE interfaces per PC or something, > and are saturating the PCI bus, look at DAG cards from Endace. They're > designed for passive monitoring, and will send you only headers and do > BPF in hardware. I looked at these for a similar project, but didn't > bother as it was cheaper to buy more PC chassis' and commodity GE > cards. They can do 10GE monitoring, so if you need several 10GE's per > chassis I'd recommend these. Ah the Endace gear looks really interesting. Thanks for the pointer! -- Ross Vandegrift ross at kallisti.us "The good Christian should beware of mathematicians, and all those who make empty prophecies. The danger already exists that the mathematicians have made a covenant with the devil to darken the spirit and to confine man in the bonds of Hell." --St. Augustine, De Genesi ad Litteram, Book II, xviii, 37 From justin at justinshore.com Tue Jun 24 09:49:53 2008 From: justin at justinshore.com (Justin Shore) Date: Tue, 24 Jun 2008 09:49:53 -0500 Subject: easy way to scan for issues with path mtu discovery? In-Reply-To: References: Message-ID: <48610991.9050209@justinshore.com> Darden, Patrick S. wrote: > > Hi all, > > Does anyone know of an easy way to scan for issues with path mtu discovery along a hop path? E.g. if you think someone is ICMP black-holing along a route, or even on the endpoint host, could you use some obscure nmap flag to find out for sure, and also to identify the offending hop/router/host? What tool would you use to test for this, and how would you do such a test? Is there any probing tool that does checks like this automatically? > > Seems to me this happens often enough that someone has probably already figured it out, so I am trying not to reinvent the wheel. All I can think of would be to handcraft packets of steadily increasing sizes and look for replies from each hop on the route (which would be laborious at best). Google has not been kind to my researches so far. Take a look at tracepath. http://www.google.com/search?hl=en&q=tracepath&btnG=Google+Search I haven't done much of anything with it but it may be of use to you. Justin From frnkblk at iname.com Tue Jun 24 09:52:25 2008 From: frnkblk at iname.com (Frank Bulk - iNAME) Date: Tue, 24 Jun 2008 09:52:25 -0500 Subject: Cloud service [was: RE: EC2 and GAE means end of ip address reputation industry? (Re: Intrustion attempts from Amazon EC2 IPs)] In-Reply-To: References: <1B54275E-B80A-49A4-8CA1-44751FD3C88D@mailchannels.com> <75cb24520806232045j3cd8b15bp2c03eb55deee29d5@mail.gmail.com> Message-ID: For the reason you stated, "much to the chagrin of receivers". Easier to sell a service to customers downstream if it's being done in the network, without MX changing. Frank -----Original Message----- From: Ken Simpson [mailto:ksimpson at mailchannels.com] Sent: Tuesday, June 24, 2008 8:38 AM To: frnkblk at iname.com Cc: 'Christopher Morrow'; nanog at nanog.org Subject: Re: Cloud service [was: RE: EC2 and GAE means end of ip address reputation industry? (Re: Intrustion attempts from Amazon EC2 IPs)] > Source IP blocking makes up a large portion of today's spam arrest > approach, > so we shouldn't discount the CPU benefits of that approach too > quickly. > > I'm not sure where today's technology is in regards for caching the > first 1 > to 10kB of a session....once enough information is garnered to > block, issue > TCP RSETs. If it's good, free the contents of the cache. What's your interest in mopping up spam in the middle of the network? Usually spam is viewed as a leaf-node problem (much to the chagrin of receivers, actually). Regards, Ken -- Ken Simpson CEO MailChannels - Reliable Email Delivery http://mailchannels.com 604 685 7488 tel From frnkblk at iname.com Tue Jun 24 09:57:47 2008 From: frnkblk at iname.com (Frank Bulk - iNAME) Date: Tue, 24 Jun 2008 09:57:47 -0500 Subject: easy way to scan for issues with path mtu discovery? In-Reply-To: References: Message-ID: Look at mturoute: http://www.elifulkerson.com/projects/mturoute.php Frank -----Original Message----- From: Darden, Patrick S. [mailto:darden at armc.org] Sent: Tuesday, June 24, 2008 9:28 AM To: nanog at nanog.org Subject: easy way to scan for issues with path mtu discovery? Hi all, Does anyone know of an easy way to scan for issues with path mtu discovery along a hop path? E.g. if you think someone is ICMP black-holing along a route, or even on the endpoint host, could you use some obscure nmap flag to find out for sure, and also to identify the offending hop/router/host? What tool would you use to test for this, and how would you do such a test? Is there any probing tool that does checks like this automatically? Seems to me this happens often enough that someone has probably already figured it out, so I am trying not to reinvent the wheel. All I can think of would be to handcraft packets of steadily increasing sizes and look for replies from each hop on the route (which would be laborious at best). Google has not been kind to my researches so far. I appreciate any help! --Patrick Darden From etrdina at claytonkendall.com Tue Jun 24 10:18:02 2008 From: etrdina at claytonkendall.com (Edward A. Trdina III) Date: Tue, 24 Jun 2008 11:18:02 -0400 Subject: Comcast Message-ID: <21D39E119A720E42BA4A11ABF884D769B39BDA@Exchange1.CK1.DMN> Anyone from Comcast on-list? I'm getting hit with phishing emails that have a link to a Wachovia look alike page that's hosted on a comcast HSI account in South Bend Indiana.(At least thats what the SWIP says). Thanks! Ed From nenolod at systeminplace.net Tue Jun 24 10:31:44 2008 From: nenolod at systeminplace.net (William Pitcock) Date: Tue, 24 Jun 2008 10:31:44 -0500 Subject: Versaweb abuse contacts Message-ID: <1214321504.28127.403.camel@petrie.sacredspiral.co.uk> Hi, If someone on this list works for Versaweb and can handle a botnet situation, please contact me off list. William From jay at west.net Tue Jun 24 13:37:57 2008 From: jay at west.net (Jay Hennigan) Date: Tue, 24 Jun 2008 11:37:57 -0700 Subject: Level3 IPv6 availability? In-Reply-To: <3c3e3fca0710022020i6048971enfc0a0b5d897c7b94@mail.gmail.com> References: <200710011553.l91FrFMF016876@parsley.amaranth.net> <200710020747.01022.braaen@zcorum.com> <3c3e3fca0710020942q2b94707cx27e80ad7d597a5bc@mail.gmail.com> <3c3e3fca0710021425i6263b2adv1ab4b89a0eb55f2b@mail.gmail.com> <4702BEBB.30101@psg.com> <3c3e3fca0710022020i6048971enfc0a0b5d897c7b94@mail.gmail.com> Message-ID: <48613F05.3070606@west.net> Is anyone at Level3 who is familiar with IPv6, or anyone who is a Level3 IPv6 customer lurking here? We are a Level3 BGP customer and our contacts are giving us a deer-in-the-headlights stare when we want to bring up our /32, claiming that they don't do IPv6 at all. Not native, not tunneled, zip, nada. Yet, I see lots of AS3356 in the ipv6 routing tables, and there's this from three years ago... http://nanog.org/mtg-0510/bamford.html -- Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net Impulse Internet Service - http://www.impulse.net/ Your local telephone and internet company - 805 884-6323 - WB6RDV From simon at slimey.org Tue Jun 24 13:41:46 2008 From: simon at slimey.org (Simon Lockhart) Date: Tue, 24 Jun 2008 19:41:46 +0100 Subject: Level3 IPv6 availability? In-Reply-To: <48613F05.3070606@west.net> References: <200710011553.l91FrFMF016876@parsley.amaranth.net> <200710020747.01022.braaen@zcorum.com> <3c3e3fca0710020942q2b94707cx27e80ad7d597a5bc@mail.gmail.com> <3c3e3fca0710021425i6263b2adv1ab4b89a0eb55f2b@mail.gmail.com> <4702BEBB.30101@psg.com> <3c3e3fca0710022020i6048971enfc0a0b5d897c7b94@mail.gmail.com> <48613F05.3070606@west.net> Message-ID: <20080624184146.GF24372@virtual.bogons.net> On Tue Jun 24, 2008 at 11:37:57AM -0700, Jay Hennigan wrote: > Is anyone at Level3 who is familiar with IPv6, or anyone who is a Level3 > IPv6 customer lurking here? We are a Level3 BGP customer and our > contacts are giving us a deer-in-the-headlights stare when we want to > bring up our /32, claiming that they don't do IPv6 at all. Not native, > not tunneled, zip, nada. We've recently brought up IPv6 with Level3. It's done as an IPv6IP tunnel to their nearest IPv6 router. I may be able to dig out the form you need... Simon -- Simon Lockhart | * Sun Server Colocation * ADSL * Domain Registration * Director | * Domain & Web Hosting * Internet Consultancy * Bogons Ltd | * http://www.bogons.net/ * Email: info at bogons.net * From zaid at zaidali.com Tue Jun 24 13:55:40 2008 From: zaid at zaidali.com (Zaid Ali) Date: Tue, 24 Jun 2008 11:55:40 -0700 Subject: XO contact Message-ID: <87D89861-0ABD-4725-872A-8BA45018E5B8@zaidali.com> Can someone from XO who handles this neighbor 65.46.253.157 help me out with a BGP session going down? This is the second time within a week where a misconfiguration of an ACL on XO end is bringing down my BGP session with you and its frustrating to go through the normal tech support chain. Zaid From craigp at tozz.net Tue Jun 24 13:57:41 2008 From: craigp at tozz.net (Craig Pierantozzi) Date: Tue, 24 Jun 2008 14:57:41 -0400 Subject: Level3 IPv6 availability? In-Reply-To: <48613F05.3070606@west.net> References: <200710011553.l91FrFMF016876@parsley.amaranth.net> <200710020747.01022.braaen@zcorum.com> <3c3e3fca0710020942q2b94707cx27e80ad7d597a5bc@mail.gmail.com> <3c3e3fca0710021425i6263b2adv1ab4b89a0eb55f2b@mail.gmail.com> <4702BEBB.30101@psg.com> <3c3e3fca0710022020i6048971enfc0a0b5d897c7b94@mail.gmail.com> <48613F05.3070606@west.net> Message-ID: <20080624185740.GA26980@eagle.deardorff.com> Level 3 provides best effort IPv6 support with no SLA to current Internet customers. As mentioned IPv6 is currently being provided via tunnels to the customer's existing router. There is a simple service agreement addendum and form to fill out for relevant config bits. Sorry you get such a response from people that should know. *sigh* regards -Craig (Level 3 architecture) * Jay Hennigan was thought to have said: > Is anyone at Level3 who is familiar with IPv6, or anyone who is a Level3 > IPv6 customer lurking here? We are a Level3 BGP customer and our > contacts are giving us a deer-in-the-headlights stare when we want to > bring up our /32, claiming that they don't do IPv6 at all. Not native, > not tunneled, zip, nada. > > Yet, I see lots of AS3356 in the ipv6 routing tables, and there's this > from three years ago... > From brandon at bogons.net Tue Jun 24 14:13:37 2008 From: brandon at bogons.net (Brandon Butterworth) Date: Tue, 24 Jun 2008 20:13:37 +0100 Subject: Level3 IPv6 availability? Message-ID: <20080624191337.GG1678@virtual.bogons.net> > > Is anyone at Level3 who is familiar with IPv6, or anyone who is a Level3 > > IPv6 customer lurking here? We are a Level3 BGP customer and our > > contacts are giving us a deer-in-the-headlights stare when we want to > > bring up our /32, claiming that they don't do IPv6 at all. Not native, > > not tunneled, zip, nada. > > We've recently brought up IPv6 with Level3. It's done as an IPv6IP tunnel to > their nearest IPv6 router. I may be able to dig out the form you need... See http://www.bogons.net/dl/level3_ipv6.doc brandon From owens at nysernet.org Tue Jun 24 15:33:12 2008 From: owens at nysernet.org (Bill Owens) Date: Tue, 24 Jun 2008 16:33:12 -0400 Subject: easy way to scan for issues with path mtu discovery? In-Reply-To: References: Message-ID: <20080624203312.GA17561@nysernet.org> On Tue, Jun 24, 2008 at 10:28:12AM -0400, Darden, Patrick S. wrote: > > > Hi all, > > Does anyone know of an easy way to scan for issues with path mtu discovery along a hop path? E.g. if you think someone is ICMP black-holing along a route, or even on the endpoint host, could you use some obscure nmap flag to find out for sure, and also to identify the offending hop/router/host? What tool would you use to test for this, and how would you do such a test? Is there any probing tool that does checks like this automatically? > > Seems to me this happens often enough that someone has probably already figured it out, so I am trying not to reinvent the wheel. All I can think of would be to handcraft packets of steadily increasing sizes and look for replies from each hop on the route (which would be laborious at best). Google has not been kind to my researches so far. scamper is the best tool I've found: http://www.wand.net.nz/scamper/ Bill. From ksimpson at mailchannels.com Tue Jun 24 17:06:26 2008 From: ksimpson at mailchannels.com (Ken Simpson) Date: Tue, 24 Jun 2008 15:06:26 -0700 Subject: EC2 and GAE means end of ip address reputation industry? (Re: In-Reply-To: References: <29351.1214252999@turing-police.cc.vt.edu> Message-ID: <8FA3CC59-C528-4066-92ED-EBC563E2AFA7@mailchannels.com> >> One could argue that the "botnets for rent" business model is in more >> widespread use than either EC2 or gridserver... >> >> I'm unclear whether that statement needs a smiley or not... > > i'd say that since EC2 won't be shut down when it's found out about, > that > you need a smiley. "widespread use" is too narrow a term. none of us > expects white-hat e-commerce business to move into rented botnets, and > rented botnets aren't all going to be in the same address space or > ASN. IMHO, Amazon will eventually be forced to bifurcate their EC2 IP space into a section that is for "newbies" and a section for established customers. The newbie space will be widely black-listed, but will also have a lower rate of abuse complaint enforcement. The only scalable way to deal with a system like EC2 is to provide clear demarcations of where the crap is likely to originate from. Regards, Ken -- Ken Simpson CEO MailChannels - Reliable Email Delivery http://mailchannels.com 604 685 7488 tel From deepak at ai.net Tue Jun 24 17:12:24 2008 From: deepak at ai.net (Deepak Jain) Date: Tue, 24 Jun 2008 18:12:24 -0400 Subject: EC2 and GAE means end of ip address reputation industry? (Re: In-Reply-To: <8FA3CC59-C528-4066-92ED-EBC563E2AFA7@mailchannels.com> References: <29351.1214252999@turing-police.cc.vt.edu> <8FA3CC59-C528-4066-92ED-EBC563E2AFA7@mailchannels.com> Message-ID: <48617148.801@ai.net> > > IMHO, Amazon will eventually be forced to bifurcate their EC2 IP space > into a section that is for "newbies" and a section for established > customers. The newbie space will be widely black-listed, but will also > have a lower rate of abuse complaint enforcement. > > The only scalable way to deal with a system like EC2 is to provide clear > demarcations of where the crap is likely to originate from. > Or, more likely, two separate companies will tackle the problem... Ala Ironport or similar. Some clusters will provide a high degree of trust and certainty of the activities of its customers, and some won't. There is no reason to believe one company will do both equally well. Deepak Jain AiNET From Valdis.Kletnieks at vt.edu Tue Jun 24 17:29:12 2008 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 24 Jun 2008 18:29:12 -0400 Subject: EC2 and GAE means end of ip address reputation industry? (Re: In-Reply-To: Your message of "Tue, 24 Jun 2008 00:03:20 -0000." References: <29351.1214252999@turing-police.cc.vt.edu> Message-ID: <41354.1214346552@turing-police.cc.vt.edu> On Tue, 24 Jun 2008 00:03:20 -0000, Paul Vixie said: > Valdis.Kletnieks at vt.edu writes: > > > One could argue that the "botnets for rent" business model is in more > > widespread use than either EC2 or gridserver... > > > > I'm unclear whether that statement needs a smiley or not... > > i'd say that since EC2 won't be shut down when it's found out about, that > you need a smiley. "widespread use" is too narrow a term. none of us > expects white-hat e-commerce business to move into rented botnets, and Umm.. Paul? Take a reality check here - nobody actually *cares* where white-hat services come from. Which is bigger, the RBN or EC2's yearly revenues? > rented botnets aren't all going to be in the same address space or ASN. Hey - it ain't much of a "cloud" if it's all in one ASN. :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From fernando at gont.com.ar Wed Jun 25 02:55:42 2008 From: fernando at gont.com.ar (Fernando Gont) Date: Wed, 25 Jun 2008 04:55:42 -0300 Subject: IPv4 source routing options and IPv6 Type 0 Routing Header Message-ID: <200806250758.m5P7wen1027990@venus.xmundo.net> Hello, folks, Quite a few times it has been mentioned to me that some peering agreements require support for the IPv4 source routing options. I was wondering whether this is still the case for some ISPs, or it is not the case anymore. I was also wondering if it has ever been the case that IPv6 peering agreements have required support for Type 0 Routing Header and, if it has, whether that still happens nowadays. (I guess not, but....) Thanks so much! Kind regards, -- Fernando Gont e-mail: fernando at gont.com.ar || fgont at acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From jabley at ca.afilias.info Wed Jun 25 07:06:25 2008 From: jabley at ca.afilias.info (Joe Abley) Date: Wed, 25 Jun 2008 08:06:25 -0400 Subject: IPv4 source routing options and IPv6 Type 0 Routing Header In-Reply-To: <200806250758.m5P7wen1027990@venus.xmundo.net> References: <200806250758.m5P7wen1027990@venus.xmundo.net> Message-ID: On 25 Jun 2008, at 03:55, Fernando Gont wrote: > Quite a few times it has been mentioned to me that some peering > agreements require support for the IPv4 source routing options. I > was wondering whether this is still the case for some ISPs, or it is > not the case anymore. > > I was also wondering if it has ever been the case that IPv6 peering > agreements have required support for Type 0 Routing Header and, if > it has, whether that still happens nowadays. (I guess not, but....) I have never seen such a requirement for IPv6. Note also that type-0 routing headers were deprecated in RFC 5095, last year. > The functionality provided by IPv6's Type 0 Routing Header can be > exploited in order to achieve traffic amplification over a remote > path for the purposes of generating denial-of-service traffic. This > document updates the IPv6 specification to deprecate the use of IPv6 > Type 0 Routing Headers, in light of this security concern. Joe From mike at rockynet.com Wed Jun 25 10:51:33 2008 From: mike at rockynet.com (Mike Lewinski) Date: Wed, 25 Jun 2008 09:51:33 -0600 Subject: Seeking clue @ Cbeyond / ASN17184 and/or other suggestions In-Reply-To: <485BF1C5.5040807@rockynet.com> References: <485BF1C5.5040807@rockynet.com> Message-ID: <48626985.4@rockynet.com> I'm very happy to report that my post here found the necessary clue-holders and resolved both the lame DNS and stale email configuration issue. Also, one important followup wrt the whois for their ASN query: > Finally, as an additional note, the whois delegation for their ASN seems > to be broken: > > $ whois -h whois.arin.net 17184 > [Querying whois.arin.net] > [Redirected to rwhois.cbeyond.net:4321] > [Querying rwhois.cbeyond.net] > [rwhois.cbeyond.net] > %rwhois V-1.5:003eff:00 rwhois.cbeyond.net (by Network Solutions, Inc. > V-1.5.9.5) > %error 230 No Objects Found > $ It appears that the breakage is probably in my whois client (though, the exact problem has yet to be diagnosed). The standard whois client for CentOS 5.1 still returns the 230 error: $ whois -h whois.arin.net AS17184 [Querying whois.arin.net] [Redirected to rwhois.cbeyond.net:4321] [Querying rwhois.cbeyond.net] [rwhois.cbeyond.net] %rwhois V-1.5:003eff:00 rwhois.cbeyond.net (by Network Solutions, Inc. V-1.5.9.5) %error 230 No Objects Found I had one private reply pointing out that my original syntax was wrong in omitting the "AS" string, though I'd tried it every way I could imagine, and verified that the syntax worked for other ASNs. The whois client on my OS X 10.4 returns the desired results: $ whois -h whois.arin.net AS17184 OrgName: CBEYOND COMMUNICATIONS, LLC OrgID: CBEY Address: 320 Interstate North Parkway Address: Suite 300 City: Atlanta StateProv: GA PostalCode: 30339 Country: US On my ToDo is to dig deeper into the problem and figure out who needs a bug report to fix this. I'm guessing it lies with CentOS/RHEL, and has to do with a failure to use the custom whois port assignment @ Cbeyond. Thanks for all the private replies, especially the one that lead to this resolution! Mike From deepak at ai.net Wed Jun 25 15:43:46 2008 From: deepak at ai.net (Deepak Jain) Date: Wed, 25 Jun 2008 16:43:46 -0400 Subject: IPv4 source routing options and IPv6 Type 0 Routing Header In-Reply-To: <200806250758.m5P7wen1027990@venus.xmundo.net> References: <200806250758.m5P7wen1027990@venus.xmundo.net> Message-ID: <4862AE02.6030201@ai.net> > Quite a few times it has been mentioned to me that some peering > agreements require support for the IPv4 source routing options. I was > wondering whether this is still the case for some ISPs, or it is not the > case anymore. Before we decommissioned our last open peering fabric, source-routing was important to make sure your peer wasn't pointing default (or similar) to you. With the advent of private (and far more limited) bilateral peering as a preference to fabric based peering (at least among the ones who set peering policies globally) this has become less of an issue. RFC 5095 aside. Deepak From wozz at wookie.net Wed Jun 25 16:47:50 2008 From: wozz at wookie.net (Matt Cable) Date: Wed, 25 Jun 2008 21:47:50 +0000 (UTC) Subject: Techniques for passive traffic capturing References: <20080623203216.GC18464@kallisti.us> <20080624144433.GC25708@kallisti.us> Message-ID: Ross Vandegrift kallisti.us> writes: > > On Tue, Jun 24, 2008 at 01:19:03PM +1200, Nathan Ward wrote: > > I see little point in aggregating tapped traffic, unless you have only > > a small amount of it and you're doing it to save cost on monitoring > > network interfaces - but is that saved cost still a saving when you > > factor in the cost of the extra 3750s in the middle? I'd guess no. > > Thanks for all the info Nathan - lots of good leads in your email. > Let me include some more information. > > The problem is finding a way to multiplex that traffic from the > optical tap to multiple things that want to peek at it. The > remote-span trick solves that, as well as integrating media > converters. 3750 is nice since you can stack em up and mix/match the > SFP and copper ports. > http://www.gigamon.com. Taps+MultiPlexing+Filtering+Clustering+10g. I've been using them very successfully for exactly what you describe for the last 2 years. If they are a bit too pricey, look at http://www.vssmonitoring.com. Similar capabilities to Gigamon, slightly less flexibility (fixed hardware configurations vs Gigamon's modular configuration) and possibly cheaper depending on your needs. From joelja at bogus.com Wed Jun 25 18:07:23 2008 From: joelja at bogus.com (Joel Jaeggli) Date: Wed, 25 Jun 2008 16:07:23 -0700 Subject: IPv4 source routing options and IPv6 Type 0 Routing Header In-Reply-To: <200806250758.m5P7wen1027990@venus.xmundo.net> References: <200806250758.m5P7wen1027990@venus.xmundo.net> Message-ID: <4862CFAB.4040608@bogus.com> Fernando Gont wrote: > Hello, folks, > > Quite a few times it has been mentioned to me that some peering > agreements require support for the IPv4 source routing options. I was > wondering whether this is still the case for some ISPs, or it is not the > case anymore. I haven't observed it in the recent past. looking backwards I can see a handfull of operators that did it (LSR) by policy everywhere in 2002. > I was also wondering if it has ever been the case that IPv6 peering > agreements have required support for Type 0 Routing Header and, if it > has, whether that still happens nowadays. (I guess not, but....) I think you'd be hardpressed to find an operator that would knowingly honor rh(0) headers > Thanks so much! > > Kind regards, > > -- > Fernando Gont > e-mail: fernando at gont.com.ar || fgont at acm.org > PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 > > > > > From fernando at gont.com.ar Wed Jun 25 20:44:03 2008 From: fernando at gont.com.ar (Fernando Gont) Date: Wed, 25 Jun 2008 22:44:03 -0300 Subject: IPv4 source routing options and IPv6 Type 0 Routing Header In-Reply-To: <4862AE02.6030201@ai.net> References: <200806250758.m5P7wen1027990@venus.xmundo.net> <4862AE02.6030201@ai.net> Message-ID: <200806260208.m5Q28Gqq019433@venus.xmundo.net> At 05:43 p.m. 25/06/2008, Deepak Jain wrote: >>Quite a few times it has been mentioned to me that some peering >>agreements require support for the IPv4 source routing options. I >>was wondering whether this is still the case for some ISPs, or it >>is not the case anymore. > >Before we decommissioned our last open peering fabric, >source-routing was important to make sure your peer wasn't pointing >default (or similar) to you. With the advent of private (and far >more limited) bilateral peering as a preference to fabric based >peering (at least among the ones who set peering policies globally) >this has become >less of an issue. Thanks so much for your response! >RFC 5095 aside. Yes, sorry. The question should have been: Has IPv6 Type 0 Routing Header ever been a requirement in v6 peering agreements? (In any case, I guess Type 0 Routing Header could still be used, in the same way that v4 source-routing was still being used even after many IP implementations had decided to filter it by default?) Kind regards, -- Fernando Gont e-mail: fernando at gont.com.ar || fgont at acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From jabley at ca.afilias.info Wed Jun 25 21:15:19 2008 From: jabley at ca.afilias.info (Joe Abley) Date: Wed, 25 Jun 2008 22:15:19 -0400 Subject: IPv4 source routing options and IPv6 Type 0 Routing Header In-Reply-To: <200806260208.m5Q28Gqq019433@venus.xmundo.net> References: <200806250758.m5P7wen1027990@venus.xmundo.net> <4862AE02.6030201@ai.net> <200806260208.m5Q28Gqq019433@venus.xmundo.net> Message-ID: <35326997-420B-44F5-8C70-12B9AFD125A6@ca.afilias.info> On 25 Jun 2008, at 21:44, Fernando Gont wrote: > (In any case, I guess Type 0 Routing Header could still be used, in > the same way that v4 source-routing was still being used even after > many IP implementations had decided to filter it by default?) Between adjacent, consenting routers, you can surely expect to be able to do whatever the routers will let you do. Joe From randy at psg.com Thu Jun 26 01:44:34 2008 From: randy at psg.com (Randy Bush) Date: Thu, 26 Jun 2008 15:44:34 +0900 Subject: IPv4 source routing options and IPv6 Type 0 Routing Header In-Reply-To: <200806260208.m5Q28Gqq019433@venus.xmundo.net> References: <200806250758.m5P7wen1027990@venus.xmundo.net> <4862AE02.6030201@ai.net> <200806260208.m5Q28Gqq019433@venus.xmundo.net> Message-ID: <48633AD2.4040301@psg.com> sorry to pick this up so late. source routing is still requested and sometimes mandated at inter-as borders. for the reasons deepak stated. note that this does not expose any vulnerability. source routing is only dangerous to hosts. > Yes, sorry. The question should have been: Has IPv6 Type 0 Routing > Header ever been a requirement in v6 peering agreements? not of which i am aware. imiho, from ops pov extension headers are unneeded kink. randy From sneak at datavibe.net Thu Jun 26 04:22:04 2008 From: sneak at datavibe.net (Rev. Jeffrey Paul) Date: Thu, 26 Jun 2008 02:22:04 -0700 Subject: OS, Hardware, Network - Logging, Monitoring, and Alerting Message-ID: <20080626092204.GR24243@datavibe.net> Hi. I've a (theoretically) simple problem and I'm wondering how others solve it. I've recently deployed ~40 Linux instances on ~20 different Dell blades and PowerEdges (we're big on virtualization), a few 7204s and 3560s, and assorted switchable PDUs and whatnot. We need to monitor standard things like cpu, memory, disk usage on all OSes. This is straightforward with net-snmp. It would also be cool if I could monitor more esoteric things, like ntp synchronization status, i/o statistics, etc. Other stuff we really need to keep an eye on is hardware - redundant PSU status in our 7204s and Dells, temperatures and voltages (one of our colos in New York peaked at over 40C a few weeks ago, for instance), and disk array status (I'd like to know of a failed disk in a hardware RAID5 before I get calls about performance issues). Our blade chassis have DRACs in them and I think they export this data via SNMP (I'm trying to avoid the use of SNMP traps), but not all of our other PowerEdges have the DRACs in them so some of this information may need to be pulled via IPMI from within the host OS. Presumably the Cisco gear makes the temperature available via SNMP. Finally, service checks - standard stuff (dns, http, https, ssh, smtp). Now, to the questions. 1) Is SNMP the best way to do this? Obviously some of the data (service checks) will need to be collected other ways. 2) Is there any good solution that does both logging/trending of this data and also notification/monitoring/alerting? I've used both Nagios and Cacti in the past, and, due to the number of individual things being monitored (3-5 items per OS instance, 5-10 items per physical server, 10-50 things per network device), setting them both up independently seems like a huge pain. Also, I've never really liked Nagios that much. I recently entertained the idea of writing a CGI that output all of this information in a standard format (csv?), distributing and installing it, then collecting it periodically at a central location and doing all the rrd/notification myself, but then realized that this problem must've been solved a million times already. There's got to be a better way. What do you guys use? (I'm not opposed to non-free solutions, provided they work better.) Cheers, -jp -- -------------------------------------------------------- Rev. Jeffrey Paul -datavibe- sneak at datavibe.net aim:x736e65616b pgp:0xD9B3C17D phone:1-800-403-1126 9440 0C7F C598 01CA 2F17 D098 0A3A 4B8F D9B3 C17D "Virtue is its own punishment." -------------------------------------------------------- From regnauld at catpipe.net Thu Jun 26 04:31:54 2008 From: regnauld at catpipe.net (Phil Regnauld) Date: Thu, 26 Jun 2008 11:31:54 +0200 Subject: OS, Hardware, Network - Logging, Monitoring, and Alerting In-Reply-To: <20080626092204.GR24243@datavibe.net> References: <20080626092204.GR24243@datavibe.net> Message-ID: <20080626093153.GA24650@catpipe.net> Rev. Jeffrey Paul (sneak) writes: > > 1) Is SNMP the best way to do this? Obviously some of the data (service > checks) will need to be collected other ways. SNMP, the vendor MIBs + SNMP extensions for monitoring hardware specifics (PSU, etc...), and something like Nagios to do the TCP/network checks. > 2) Is there any good solution that does both logging/trending of this > data and also notification/monitoring/alerting? I've used both Nagios > and Cacti in the past, and, due to the number of individual things being > monitored (3-5 items per OS instance, 5-10 items per physical server, > 10-50 things per network device), setting them both up independently > seems like a huge pain. Also, I've never really liked Nagios that much. Well, you could look at Zabbix, Hyperic, ZenOSS, OpenNMS and see if they cut it better for you, but the trick with Nagios is to use a DB and generate the include files automatically, then have some other more user friendly tools to populate the DB. Or use templates extensively. Then make sure your plugins output performance data for perf.data monitoring, and use something like NagiosGraph http://nagiosgraph.wiki.sourceforge.net/ or PNP4Nagios: http://www.pnp4nagios.org/pnp/about#system_requirements http://nagiosplug.sourceforge.net/developer-guidelines.html#AEN203 http://www.pnp4nagios.org/pnp/screenshots > I recently entertained the idea of writing a CGI that output all of this > information in a standard format (csv?), distributing and installing it, then > collecting it periodically at a central location and doing all the > rrd/notification myself, but then realized that this problem must've > been solved a million times already. Yes :) But check out the above links, and with a bit of planning and a small amount of coding/adapting existing components, it will work out. > There's got to be a better way. What do you guys use? We rewrote our own NMS from scratch :) > (I'm not opposed to non-free solutions, provided they work better.) We sell our solution, so I'm biased, but do check out the Nagios route, it works well enough for small to medium, and larger installations with careful planning (problem with Nagios is how to make it perform with thousands of hosts). Hth, Phil From agirling at denetron.com Thu Jun 26 04:30:43 2008 From: agirling at denetron.com (Andrew Girling) Date: Thu, 26 Jun 2008 05:30:43 -0400 Subject: OS, Hardware, Network - Logging, Monitoring, and Alerting In-Reply-To: <20080626092204.GR24243@datavibe.net> References: <20080626092204.GR24243@datavibe.net> Message-ID: <8C978460-6B22-49FF-ADA5-37A9F836CAFC@denetron.com> On Jun 26, 2008, at 5:22 AM, Rev. Jeffrey Paul wrote: > Hi. I've a (theoretically) simple problem and I'm wondering how > others > solve it. > > I've recently deployed ~40 Linux instances on ~20 different Dell > blades > and PowerEdges (we're big on virtualization), a few 7204s and 3560s, > and > assorted switchable PDUs and whatnot. > > We need to monitor standard things like cpu, memory, disk usage on all > OSes. This is straightforward with net-snmp. It would also be cool > if > I could monitor more esoteric things, like ntp synchronization status, > i/o statistics, etc. > > Other stuff we really need to keep an eye on is hardware - redundant > PSU status in our 7204s and Dells, temperatures and voltages (one of > our colos in New York peaked at over 40C a few weeks ago, for > instance), and disk array status (I'd like to know of a failed disk > in a hardware RAID5 before I get calls about performance issues). Our > blade chassis have DRACs in them and I think they export this data via > SNMP (I'm trying to avoid the use of SNMP traps), but not all of our > other PowerEdges have the DRACs in them so some of this information > may > need to be pulled via IPMI from within the host OS. Presumably the > Cisco gear makes the temperature available via SNMP. > > Finally, service checks - standard stuff (dns, http, https, ssh, > smtp). > > Now, to the questions. > > 1) Is SNMP the best way to do this? Obviously some of the data > (service > checks) will need to be collected other ways. > > 2) Is there any good solution that does both logging/trending of this > data and also notification/monitoring/alerting? I've used both Nagios > and Cacti in the past, and, due to the number of individual things > being > monitored (3-5 items per OS instance, 5-10 items per physical server, > 10-50 things per network device), setting them both up independently > seems like a huge pain. Also, I've never really liked Nagios that > much. > > I recently entertained the idea of writing a CGI that output all of > this > information in a standard format (csv?), distributing and installing > it, then > collecting it periodically at a central location and doing all the > rrd/notification myself, but then realized that this problem must've > been solved a million times already. > > There's got to be a better way. What do you guys use? > > (I'm not opposed to non-free solutions, provided they work better.) You may want to have a look at Zenoss, http://www.zenoss.com/ Cheers, Andrew From tier1 at ncinet.de Thu Jun 26 04:43:34 2008 From: tier1 at ncinet.de (Tom Quilling) Date: Thu, 26 Jun 2008 11:43:34 +0200 Subject: AW: OS, Hardware, Network - Logging, Monitoring, and Alerting In-Reply-To: <20080626092204.GR24243@datavibe.net> References: <20080626092204.GR24243@datavibe.net> Message-ID: <8FCED1C8F49643E38DD803967CB371FC@tigerteam2> hi jeffrey I personally prefer hobbit over cacti and nagios http://sourceforge.net/projects/hobbitmon/ http://hobbitmon.sourceforge.net/ Thomas Quilling NCIR GmbH Network, Consulting & Internet Services Munich / Germany tier1 at ncinet.de -----Ursprungliche Nachricht----- Von: Rev. Jeffrey Paul [mailto:sneak at datavibe.net] Gesendet: Donnerstag, 26. Juni 2008 11:22 An: nanog at nanog.org Betreff: OS, Hardware, Network - Logging, Monitoring, and Alerting Hi. I've a (theoretically) simple problem and I'm wondering how others solve it. I've recently deployed ~40 Linux instances on ~20 different Dell blades and PowerEdges (we're big on virtualization), a few 7204s and 3560s, and assorted switchable PDUs and whatnot. We need to monitor standard things like cpu, memory, disk usage on all OSes. This is straightforward with net-snmp. It would also be cool if I could monitor more esoteric things, like ntp synchronization status, i/o statistics, etc. Other stuff we really need to keep an eye on is hardware - redundant PSU status in our 7204s and Dells, temperatures and voltages (one of our colos in New York peaked at over 40C a few weeks ago, for instance), and disk array status (I'd like to know of a failed disk in a hardware RAID5 before I get calls about performance issues). Our blade chassis have DRACs in them and I think they export this data via SNMP (I'm trying to avoid the use of SNMP traps), but not all of our other PowerEdges have the DRACs in them so some of this information may need to be pulled via IPMI from within the host OS. Presumably the Cisco gear makes the temperature available via SNMP. Finally, service checks - standard stuff (dns, http, https, ssh, smtp). Now, to the questions. 1) Is SNMP the best way to do this? Obviously some of the data (service checks) will need to be collected other ways. 2) Is there any good solution that does both logging/trending of this data and also notification/monitoring/alerting? I've used both Nagios and Cacti in the past, and, due to the number of individual things being monitored (3-5 items per OS instance, 5-10 items per physical server, 10-50 things per network device), setting them both up independently seems like a huge pain. Also, I've never really liked Nagios that much. I recently entertained the idea of writing a CGI that output all of this information in a standard format (csv?), distributing and installing it, then collecting it periodically at a central location and doing all the rrd/notification myself, but then realized that this problem must've been solved a million times already. There's got to be a better way. What do you guys use? (I'm not opposed to non-free solutions, provided they work better.) Cheers, -jp -- -------------------------------------------------------- Rev. Jeffrey Paul -datavibe- sneak at datavibe.net aim:x736e65616b pgp:0xD9B3C17D phone:1-800-403-1126 9440 0C7F C598 01CA 2F17 D098 0A3A 4B8F D9B3 C17D "Virtue is its own punishment." -------------------------------------------------------- From LarrySheldon at cox.net Thu Jun 26 08:59:02 2008 From: LarrySheldon at cox.net (Laurence F. Sheldon, Jr.) Date: Thu, 26 Jun 2008 08:59:02 -0500 Subject: OS, Hardware, Network - Logging, Monitoring, and Alerting In-Reply-To: <20080626092204.GR24243@datavibe.net> References: <20080626092204.GR24243@datavibe.net> Message-ID: <4863A0A6.5040105@cox.net> Rev. Jeffrey Paul wrote: > Hi. I've a (theoretically) simple problem and I'm wondering how others > solve it. Taken one at a time, mos of them are simple. Most of life is like that. > 1) Is SNMP the best way to do this? Obviously some of the data (service > checks) will need to be collected other ways. I've actually been out of the admin biz for some time but back in the day I was very found of SNMP tools for all sorts of reporting. For output I liked MRTG for most things, WhatsUpGold had some nice features if you would rather pay money. For alarms, I used some unix hack or another (home-made). I also used home-made hacks to gather data about things that did not have a suitable SNMP interface. > 2) Is there any good solution that does both logging/trending of this > data and also notification/monitoring/alerting? I've used both Nagios > and Cacti in the past, and, due to the number of individual things being > monitored (3-5 items per OS instance, 5-10 items per physical server, > 10-50 things per network device), setting them both up independently > seems like a huge pain. Also, I've never really liked Nagios that much. See MRTG, RRD, et al. > I recently entertained the idea of writing a CGI that output all of this > information in a standard format (csv?), distributing and installing it, then > collecting it periodically at a central location and doing all the > rrd/notification myself, but then realized that this problem must've > been solved a million times already. > > There's got to be a better way. What do you guys use? I had the luxury of management that thought managing was a good idea, so I had a machine pretty much dedicated to systems management and all the machines (including routers, bridges, hubs, and such) reported to it. We had a web interface to the MRTG and MRTG-like presentations. > (I'm not opposed to non-free solutions, provided they work better.) Just before the fired me for being too old, they bought all the HP and cisco stuff in the world. I do not recommend any of it. -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs From alex at blastro.com Thu Jun 26 11:14:37 2008 From: alex at blastro.com (Alex Thurlow) Date: Thu, 26 Jun 2008 11:14:37 -0500 Subject: OS, Hardware, Network - Logging, Monitoring, and Alerting In-Reply-To: <8C978460-6B22-49FF-ADA5-37A9F836CAFC@denetron.com> References: <20080626092204.GR24243@datavibe.net> <8C978460-6B22-49FF-ADA5-37A9F836CAFC@denetron.com> Message-ID: <4863C06D.4010406@blastro.com> Andrew Girling wrote: > > On Jun 26, 2008, at 5:22 AM, Rev. Jeffrey Paul wrote: > >> Hi. I've a (theoretically) simple problem and I'm wondering how others >> solve it. >> >> I've recently deployed ~40 Linux instances on ~20 different Dell blades >> and PowerEdges (we're big on virtualization), a few 7204s and 3560s, and >> assorted switchable PDUs and whatnot. >> >> We need to monitor standard things like cpu, memory, disk usage on all >> OSes. This is straightforward with net-snmp. It would also be cool if >> I could monitor more esoteric things, like ntp synchronization status, >> i/o statistics, etc. >> >> Other stuff we really need to keep an eye on is hardware - redundant >> PSU status in our 7204s and Dells, temperatures and voltages (one of >> our colos in New York peaked at over 40C a few weeks ago, for >> instance), and disk array status (I'd like to know of a failed disk >> in a hardware RAID5 before I get calls about performance issues). Our >> blade chassis have DRACs in them and I think they export this data via >> SNMP (I'm trying to avoid the use of SNMP traps), but not all of our >> other PowerEdges have the DRACs in them so some of this information may >> need to be pulled via IPMI from within the host OS. Presumably the >> Cisco gear makes the temperature available via SNMP. >> >> Finally, service checks - standard stuff (dns, http, https, ssh, smtp). >> >> Now, to the questions. >> >> 1) Is SNMP the best way to do this? Obviously some of the data (service >> checks) will need to be collected other ways. >> >> 2) Is there any good solution that does both logging/trending of this >> data and also notification/monitoring/alerting? I've used both Nagios >> and Cacti in the past, and, due to the number of individual things being >> monitored (3-5 items per OS instance, 5-10 items per physical server, >> 10-50 things per network device), setting them both up independently >> seems like a huge pain. Also, I've never really liked Nagios that much. >> >> I recently entertained the idea of writing a CGI that output all of this >> information in a standard format (csv?), distributing and installing >> it, then >> collecting it periodically at a central location and doing all the >> rrd/notification myself, but then realized that this problem must've >> been solved a million times already. >> >> There's got to be a better way. What do you guys use? >> >> (I'm not opposed to non-free solutions, provided they work better.) > > > You may want to have a look at Zenoss, http://www.zenoss.com/ > > Cheers, > Andrew > > I have to second the Zenoss recommendation. Fairly automatic setup for most things, great categorization and it will incorporate nagios plugins or any script that outputs in that format. It's free, but you can also buy support or install service from them. -- Alex Thurlow Technical Director Blastro Networks From yahoo at jimpop.com Thu Jun 26 15:09:30 2008 From: yahoo at jimpop.com (Jim Popovitch) Date: Thu, 26 Jun 2008 16:09:30 -0400 Subject: ICANN opens up Pandora's Box of new TLDs Message-ID: <7ff145960806261309u4eda28b7v8973556b983df63a@mail.gmail.com> Two years ago I posed the question here about the need for TLDs (http://www.mcabee.org/lists/nanog/May-06/msg00110.html). I summerizsed that companies IP (Intellectual Property) guidelines would never allow domain.org to exist if they owned domain.com (ibm.org vrs ibm.com). I felt that TLDs really represented a monetary harvesting scheme as every new TLD forced companies to "pay for yet another domain name" (slowly milking businesses). At that time several knowledgeable folks commented that TLDs were necessary in the beginning due to the need to distribute queries. Now it seems, ICANN has decided to add a new paradigm :-) How will a TLD like .ibm be handled now, and how is this different than what I proposed in 2006? -Jim P. From jra at baylink.com Thu Jun 26 15:33:34 2008 From: jra at baylink.com (Jay R. Ashworth) Date: Thu, 26 Jun 2008 16:33:34 -0400 Subject: ICANN opens up Pandora's Box of new TLDs In-Reply-To: <7ff145960806261309u4eda28b7v8973556b983df63a@mail.gmail.com> References: <7ff145960806261309u4eda28b7v8973556b983df63a@mail.gmail.com> Message-ID: <20080626203334.GA18237@cgi.jachomes.com> On Thu, Jun 26, 2008 at 04:09:30PM -0400, Jim Popovitch wrote: > Two years ago I posed the question here about the need for TLDs > (http://www.mcabee.org/lists/nanog/May-06/msg00110.html). I > summerizsed that companies IP (Intellectual Property) guidelines > would never allow domain.org to exist if they owned domain.com > (ibm.org vrs ibm.com). I felt that TLDs really represented a monetary > harvesting scheme as every new TLD forced companies to "pay for > yet another domain name" (slowly milking businesses). At that time > several knowledgeable folks commented that TLDs were necessary in the > beginning due to the need to distribute queries. Now it seems, ICANN > has decided to add a new paradigm :-) How will a TLD like .ibm be > handled now, and how is this different than what I proposed in 2006? Could someone point me to a reference (other than a very poorly written BBC article) that suggests that .ibm is even a valid possiblity in light of whatever ICANN actually *is* proposing? And no, companies *aren't* "forced to pay for another domain name" just because a new TLD appears -- they aren't doing it *now*, by and large, and thank ghod: a) it doesn't constitute a violation of Ford Motor's trademark that the Ford Foundation has ford.org or a Mustang club has ford.net and b) it's horrible DNS hygiene to do that in the first place; it re-flattens the TLD namespace. I certainly advise my clients not to do things that foolish. I'm sure Randy encourages me in this. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com '87 e24 St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 Those who cast the vote decide nothing. Those who count the vote decide everything. -- (Joseph Stalin) From ksimpson at mailchannels.com Thu Jun 26 15:34:22 2008 From: ksimpson at mailchannels.com (Ken Simpson) Date: Thu, 26 Jun 2008 13:34:22 -0700 Subject: ICANN opens up Pandora's Box of new TLDs In-Reply-To: <7ff145960806261309u4eda28b7v8973556b983df63a@mail.gmail.com> References: <7ff145960806261309u4eda28b7v8973556b983df63a@mail.gmail.com> Message-ID: <5429E6E0-382A-4711-8D8C-2A241B6E4F6A@mailchannels.com> > Two years ago I posed the question here about the need for TLDs > (http://www.mcabee.org/lists/nanog/May-06/msg00110.html). > I summerizsed that companies IP (Intellectual Property) guidelines > would never allow domain.org to exist if they owned domain.com > (ibm.org vrs ibm.com). I felt that TLDs really represented a > monetary harvesting scheme as every new TLD forced companies to "pay > for yet another domain name" (slowly milking businesses). At that > time several knowledgeable folks commented that TLDs were necessary > in the beginning due to the need to distribute queries. Now it > seems, ICANN has decided to add a new paradigm :-) How will a TLD > like .ibm be handled now, and how is this different than what I > proposed in 2006? How will ICANN be allocating these? An auction format? It will be a blood bath otherwise.. And for abuse and spam, this is a nightmare. From zaid at zaidali.com Thu Jun 26 15:54:00 2008 From: zaid at zaidali.com (Zaid Ali) Date: Thu, 26 Jun 2008 13:54:00 -0700 Subject: ICANN opens up Pandora's Box of new TLDs In-Reply-To: <5429E6E0-382A-4711-8D8C-2A241B6E4F6A@mailchannels.com> References: <7ff145960806261309u4eda28b7v8973556b983df63a@mail.gmail.com> <5429E6E0-382A-4711-8D8C-2A241B6E4F6A@mailchannels.com> Message-ID: <76DFB499-1474-49ED-AC92-6A028253661A@zaidali.com> I hear from my friend's attending ICANN in Paris that there are tons of business folks who want to scoop up a gTLD. I haven't heard of anything that will be structured so looks like it will be a blood bath. Zaid On Jun 26, 2008, at 1:34 PM, Ken Simpson wrote: >> Two years ago I posed the question here about the need for TLDs >> (http://www.mcabee.org/lists/nanog/May-06/msg00110.html). >> I summerizsed that companies IP (Intellectual Property) guidelines >> would never allow domain.org to exist if they owned domain.com >> (ibm.org vrs ibm.com). I felt that TLDs really represented a >> monetary harvesting scheme as every new TLD forced companies to "pay >> for yet another domain name" (slowly milking businesses). At that >> time several knowledgeable folks commented that TLDs were necessary >> in the beginning due to the need to distribute queries. Now it >> seems, ICANN has decided to add a new paradigm :-) How will a TLD >> like .ibm be handled now, and how is this different than what I >> proposed in 2006? > > How will ICANN be allocating these? An auction format? It will be a > blood bath otherwise.. And for abuse and spam, this is a nightmare. > From drc at virtualized.org Thu Jun 26 16:02:02 2008 From: drc at virtualized.org (David Conrad) Date: Thu, 26 Jun 2008 14:02:02 -0700 Subject: ICANN opens up Pandora's Box of new TLDs In-Reply-To: <5429E6E0-382A-4711-8D8C-2A241B6E4F6A@mailchannels.com> References: <7ff145960806261309u4eda28b7v8973556b983df63a@mail.gmail.com> <5429E6E0-382A-4711-8D8C-2A241B6E4F6A@mailchannels.com> Message-ID: On Jun 26, 2008, at 1:34 PM, Ken Simpson wrote: > How will ICANN be allocating these? https://par.icann.org/files/paris/GNSO-gTLD-Update-Paris22jun08.pdf Regards, -drc From jeroen at unfix.org Thu Jun 26 16:53:06 2008 From: jeroen at unfix.org (Jeroen Massar) Date: Thu, 26 Jun 2008 23:53:06 +0200 Subject: ICANN opens up Pandora's Box of new TLDs In-Reply-To: References: <7ff145960806261309u4eda28b7v8973556b983df63a@mail.gmail.com> <5429E6E0-382A-4711-8D8C-2A241B6E4F6A@mailchannels.com> Message-ID: <48640FC2.2000909@spaghetti.zurich.ibm.com> David Conrad wrote: > On Jun 26, 2008, at 1:34 PM, Ken Simpson wrote: >> How will ICANN be allocating these? > > > https://par.icann.org/files/paris/GNSO-gTLD-Update-Paris22jun08.pdf and http://www.circleid.com/posts/86262_launch_of_paris_domain_icann/ and http://www.circleid.com/posts/86269_icann_approves_overhaul_top_level_domains/#4133 and well the rest of CircleID. Some people are going to get very rich over this. I hope that they drown in the money just as the Internet will drown in all the crap TLD's, not even thinking of all the nice security issues which come along (home, mycomputer and .exe etc anyone ? :) And of course the people who like to grab typos will also have a field day with this. Thank you people doing all the ICANN politics for destroying the Internet. Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 187 bytes Desc: OpenPGP digital signature URL: From rirving at antient.org Thu Jun 26 17:07:55 2008 From: rirving at antient.org (R. Irving) Date: Thu, 26 Jun 2008 18:07:55 -0400 Subject: ICANN opens up Pandora's Box of new TLDs In-Reply-To: <48640FC2.2000909@spaghetti.zurich.ibm.com> References: <7ff145960806261309u4eda28b7v8973556b983df63a@mail.gmail.com> <5429E6E0-382A-4711-8D8C-2A241B6E4F6A@mailchannels.com> <48640FC2.2000909@spaghetti.zurich.ibm.com> Message-ID: <4864133B.5030409@antient.org> > Thank you people doing all the ICANN politics for destroying the > Internet. You know, last time someone ( Robert Metcalfe ) prophesied the death of the Internet, when it didn't come true... we made him eat his words. You up for a repeat ? :-P > Greets, > Jeroen From frnkblk at iname.com Thu Jun 26 17:51:42 2008 From: frnkblk at iname.com (Frank Bulk) Date: Thu, 26 Jun 2008 17:51:42 -0500 Subject: Possible explanations for a large hop in latency Message-ID: Our upstream provider has a connection to AT&T (12.88.71.13) where I relatively consistently measure with a RTT of 15 msec, but the next hop (12.122.112.22) comes in with a RTT of 85 msec. Unless AT&T is sending that traffic over a cable modem or to Europe and back, I can't see a reason why there is a consistent ~70 msec jump in RTT. Hops farther along the route are just a few msec more each hop, so it doesn't appear that 12.122.112.22 has some kind of ICMP rate-limiting. Is this a real performance issue, or is there some logical explanation? Frank From brandon at rd.bbc.co.uk Thu Jun 26 17:59:29 2008 From: brandon at rd.bbc.co.uk (Brandon Butterworth) Date: Thu, 26 Jun 2008 23:59:29 +0100 (BST) Subject: ICANN opens up Pandora's Box of new TLDs Message-ID: <200806262259.XAA10700@sunf10.rd.bbc.co.uk> > And no, companies *aren't* "forced to pay for another domain name" just > because a new TLD appears -- they aren't doing it *now* Oh yes we are brandon From hannigan at verneglobal.com Thu Jun 26 18:07:57 2008 From: hannigan at verneglobal.com (Martin Hannigan) Date: Thu, 26 Jun 2008 23:07:57 -0000 Subject: ICANN opens up Pandora's Box of new TLDs References: <7ff145960806261309u4eda28b7v8973556b983df63a@mail.gmail.com> <20080626203334.GA18237@cgi.jachomes.com> Message-ID: >And no, companies *aren't* "forced to pay for another domain name" just >because a new TLD appears -- they aren't doing it *now*, by and large, >and thank ghod: The last time I looked there were a few thousand companies protecting their intellectual property by using companies like Mark Monitor to insure that they had defensive registrations in all ccTLD's possible. -M< From owen at delong.com Thu Jun 26 18:17:45 2008 From: owen at delong.com (Owen DeLong) Date: Thu, 26 Jun 2008 16:17:45 -0700 Subject: ICANN opens up Pandora's Box of new TLDs In-Reply-To: References: <7ff145960806261309u4eda28b7v8973556b983df63a@mail.gmail.com> <20080626203334.GA18237@cgi.jachomes.com> Message-ID: On Jun 26, 2008, at 4:07 PM, Martin Hannigan wrote: > > >> And no, companies *aren't* "forced to pay for another domain name" >> just >> because a new TLD appears -- they aren't doing it *now*, by and >> large, >> and thank ghod: > > The last time I looked there were a few thousand companies > protecting their intellectual property by using companies like Mark > Monitor to insure that they had defensive registrations in all > ccTLD's possible. > > -M< > > Whether some choose to do that or not, I believe that the point is that: 1. Nobody is FORCING them to do so. 2. Most are _NOT_ doing so. 3. It is somewhat anti-social to do so, but, that has rarely been a constraint on corporate greed, especially amongst the Intelectual Property crowd. Owen From ksimpson at mailchannels.com Thu Jun 26 18:28:51 2008 From: ksimpson at mailchannels.com (Ken Simpson) Date: Thu, 26 Jun 2008 16:28:51 -0700 Subject: ICANN opens up Pandora's Box of new TLDs In-Reply-To: References: <7ff145960806261309u4eda28b7v8973556b983df63a@mail.gmail.com> <20080626203334.GA18237@cgi.jachomes.com> Message-ID: <27BB6AE4-006E-49DB-93ED-93834D1C0EF9@mailchannels.com> Has anyone been able to figure out what it will cost to secure a completely un-contested tld? I haven't been able to find proposed fees anywhere. I think it will be a practical necessity for all organizations to secure their own TLD at the outset, lest someone else secure it for them and leave it up to the court of arbitration. .. And where, pray-tell, will the mega cash from the TLD auctions be going? Surely ICANN doesn't need a multi-billion $ annual budget, but if these TLD auctions go the way of the cellular auctions, there's a good potential for that kind of an outcome. From williamsjj at digitar.com Thu Jun 26 18:30:29 2008 From: williamsjj at digitar.com (Jason Williams) Date: Thu, 26 Jun 2008 17:30:29 -0600 Subject: ICANN opens up Pandora's Box of new TLDs In-Reply-To: Message-ID: > 3. It is somewhat anti-social to do so, but, that has rarely been a > constraint on corporate greed, especially amongst the Intelectual > Property crowd. It doesn't seem to me to be "anti-social" behavior to ensure when your customers mistype your domain as a .net or .de (depending on the customer's locale) that they still end up at your site. Definitely, wouldn't ascribe it as corporate greed. -J ________________________ Jason J. W. Williams COO/CTO, DigiTar http://www.digitar.com Voice: 208.343.8520 Mobile: 208.863.0727 FAX: 208.322-8522 E-mail: williamsjj at digitar.com XMPP/Jabber: williamsjj at digitar.com From brandon at rd.bbc.co.uk Thu Jun 26 18:31:52 2008 From: brandon at rd.bbc.co.uk (Brandon Butterworth) Date: Fri, 27 Jun 2008 00:31:52 +0100 (BST) Subject: ICANN opens up Pandora's Box of new TLDs Message-ID: <200806262331.AAA15443@sunf10.rd.bbc.co.uk> > 1. Nobody is FORCING them to do so. scammers, squaters and click collectors > 3. It is somewhat anti-social to do so So are the abusers. If someone is going to it may as well be us (marginally less evil) brandon From tme at multicasttech.com Thu Jun 26 18:33:21 2008 From: tme at multicasttech.com (Marshall Eubanks) Date: Thu, 26 Jun 2008 19:33:21 -0400 Subject: ICANN opens up Pandora's Box of new TLDs In-Reply-To: <27BB6AE4-006E-49DB-93ED-93834D1C0EF9@mailchannels.com> References: <7ff145960806261309u4eda28b7v8973556b983df63a@mail.gmail.com> <20080626203334.GA18237@cgi.jachomes.com> <27BB6AE4-006E-49DB-93ED-93834D1C0EF9@mailchannels.com> Message-ID: Hello; On Jun 26, 2008, at 7:28 PM, Ken Simpson wrote: > Has anyone been able to figure out what it will cost to secure a > completely un-contested tld? I haven't been able to find proposed > fees anywhere. I think it will be a practical necessity for all > organizations to secure their own TLD at the outset, lest someone > else secure it for them and leave it up to the court of arbitration. > > .. And where, pray-tell, will the mega cash from the TLD auctions be > going? Surely ICANN doesn't need a multi-billion $ annual budget, > but if these TLD auctions go the way of the cellular auctions, > there's a good potential for that kind of an outcome. > This gives an (unofficial) estimate : .confusion: ICANN opens up Pandora's Box of new TLDs By Jacqui Cheng | Published: June 26, 2008 - 12:11PM CT Not every zany TLD will be immediately available to anyone who want to register a domain, however. Businesses must apply to register the TLD first, then go through a review process to ensure that it isn't offensive and doesn't infringe on anyone's intellectual property. If approved, registering the TLD will cost anywhere from $100,000 to $500,000, ICANN says, and the business or organization must prove that they are either capable of managing the TLD or can reach a deal with a company that will. This is no small beans?unless you're planning to fork over up to half a million dollars and put in the labor to manage everything that appears under the TLD, this task is probably best left to large organizations and governmental entities. The organization registering the TLD will also be responsible for determining whether it will be restricted to certain types of sites or open to the public. Regards Marshall From hannigan at verneglobal.com Thu Jun 26 18:47:42 2008 From: hannigan at verneglobal.com (Martin Hannigan) Date: Thu, 26 Jun 2008 23:47:42 -0000 Subject: ICANN opens up Pandora's Box of new TLDs References: <200806262331.AAA15443@sunf10.rd.bbc.co.uk> Message-ID: >> 1. Nobody is FORCING them to do so. >scammers, squaters and click collectors > 3. It is somewhat anti-social to do so >So are the abusers. If someone is going to it may as >well be us (marginally less evil) There are probably some variations based on the zone, languages, IDN'ability, etc., but it certainly is a good idea to be bankofamerica.* for reasons that I think are obvious to most of us. -M< From ksimpson at mailchannels.com Thu Jun 26 18:58:03 2008 From: ksimpson at mailchannels.com (Ken Simpson) Date: Thu, 26 Jun 2008 16:58:03 -0700 Subject: ICANN opens up Pandora's Box of new TLDs In-Reply-To: References: <7ff145960806261309u4eda28b7v8973556b983df63a@mail.gmail.com> <20080626203334.GA18237@cgi.jachomes.com> <27BB6AE4-006E-49DB-93ED-93834D1C0EF9@mailchannels.com> Message-ID: <13BCFAAA-D274-4969-B4D5-9D51A5B22979@mailchannels.com> > This gives an (unofficial) estimate : > > > > > .confusion: ICANN opens up Pandora's Box of new TLDs > By Jacqui Cheng | Published: June 26, 2008 - 12:11PM CT > > > Not every zany TLD will be immediately available to anyone who want > to register a domain, however. Businesses must apply to register the > TLD first, then go through a review process to ensure that it isn't > offensive and doesn't infringe on anyone's intellectual property. If > approved, registering the TLD will cost anywhere from $100,000 to > $500,000, ICANN says, and the business or organization must prove > that they are either capable of managing the TLD or can reach a deal > with a company that will. This is no small beans?unless you're > planning to fork over up to half a million dollars and put in the > labor to manage everything that appears under the TLD, this task is > probably best left to large organizations and governmental entities. > The organization registering the TLD will also be responsible for > determining whether it will be restricted to certain types of sites > or open to the public. > Thanks for the info. Okay, well that kind of pricing will prevent most of the fraudsters from obtaining TLDs. But of course it doesn't prevent shady operators from setting up a TLD with lenient abuse controls - such as .info or .to. Imagine 40 .infos spamming away... From james.cutler at consultant.com Thu Jun 26 18:58:53 2008 From: james.cutler at consultant.com (James R. Cutler) Date: Thu, 26 Jun 2008 19:58:53 -0400 Subject: Possible explanations for a large hop in latency In-Reply-To: References: Message-ID: <2732CC6A-24D9-46F3-A7D9-FCCDD23937C2@consultant.com> Deep Packet Inspection engine delay. On Jun 26, 2008, at 6:51 PM, Frank Bulk wrote: > Our upstream provider has a connection to AT&T (12.88.71.13) where I > relatively consistently measure with a RTT of 15 msec, but the next > hop > (12.122.112.22) comes in with a RTT of 85 msec. Unless AT&T is > sending that > traffic over a cable modem or to Europe and back, I can't see a > reason why > there is a consistent ~70 msec jump in RTT. Hops farther along the > route > are just a few msec more each hop, so it doesn't appear that > 12.122.112.22 > has some kind of ICMP rate-limiting. > > Is this a real performance issue, or is there some logical > explanation? > > Frank > > James R. Cutler james.cutler at consultant.com From john at fluidhosting.com Thu Jun 26 19:03:46 2008 From: john at fluidhosting.com (John T. Yocum) Date: Thu, 26 Jun 2008 17:03:46 -0700 Subject: Possible explanations for a large hop in latency In-Reply-To: References: Message-ID: <48642E62.70206@fluidhosting.com> When I asked ATT about the sudden latency jump I see in traceroutes, they told me it was due to how their MPLS network is setup. --John Frank Bulk wrote: > Our upstream provider has a connection to AT&T (12.88.71.13) where I > relatively consistently measure with a RTT of 15 msec, but the next hop > (12.122.112.22) comes in with a RTT of 85 msec. Unless AT&T is sending that > traffic over a cable modem or to Europe and back, I can't see a reason why > there is a consistent ~70 msec jump in RTT. Hops farther along the route > are just a few msec more each hop, so it doesn't appear that 12.122.112.22 > has some kind of ICMP rate-limiting. > > Is this a real performance issue, or is there some logical explanation? > > Frank > > From tme at multicasttech.com Thu Jun 26 19:11:33 2008 From: tme at multicasttech.com (Marshall Eubanks) Date: Thu, 26 Jun 2008 20:11:33 -0400 Subject: ICANN opens up Pandora's Box of new TLDs In-Reply-To: <13BCFAAA-D274-4969-B4D5-9D51A5B22979@mailchannels.com> References: <7ff145960806261309u4eda28b7v8973556b983df63a@mail.gmail.com> <20080626203334.GA18237@cgi.jachomes.com> <27BB6AE4-006E-49DB-93ED-93834D1C0EF9@mailchannels.com> <13BCFAAA-D274-4969-B4D5-9D51A5B22979@mailchannels.com> Message-ID: <79771919-2967-4458-8707-0E2496F01C31@multicasttech.com> On Jun 26, 2008, at 7:58 PM, Ken Simpson wrote: >> This gives an (unofficial) estimate : >> >> > > >> >> .confusion: ICANN opens up Pandora's Box of new TLDs >> By Jacqui Cheng | Published: June 26, 2008 - 12:11PM CT >> >> >> Not every zany TLD will be immediately available to anyone who want >> to register a domain, however. Businesses must apply to register >> the TLD first, then go through a review process to ensure that it >> isn't offensive and doesn't infringe on anyone's intellectual >> property. If approved, registering the TLD will cost anywhere from >> $100,000 to $500,000, ICANN says, and the business or organization >> must prove that they are either capable of managing the TLD or can >> reach a deal with a company that will. This is no small beans? >> unless you're planning to fork over up to half a million dollars >> and put in the labor to manage everything that appears under the >> TLD, this task is probably best left to large organizations and >> governmental entities. The organization registering the TLD will >> also be responsible for determining whether it will be restricted >> to certain types of sites or open to the public. >> > > Thanks for the info. Okay, well that kind of pricing will prevent > most of the fraudsters from obtaining TLDs. But of course it doesn't > prevent shady operators from setting up a TLD with lenient abuse > controls - such as .info or .to. Imagine 40 .infos spamming away... What I wonder is what that amount is going to ? Is that a fee, or is it an estimate of what it would take to set up a registrar ? If it is the latter, GoDaddy or Network Solutions may start offering TLDs for a lot less. I don't see much of an intrinsic reason why it should be more than 1 hour of person time to evaluate, thus a cost in the $ 100's of USDs, plus ongoing registry costs. This https://par.icann.org/files/paris/GNSO-gTLD-Update-Paris22jun08.pdf makes it look like much of the process could be automated. Regards Marshall From jeffshultz at wvi.com Thu Jun 26 18:56:14 2008 From: jeffshultz at wvi.com (Jeff Shultz) Date: Thu, 26 Jun 2008 16:56:14 -0700 Subject: ICANN opens up Pandora's Box of new TLDs In-Reply-To: References: <7ff145960806261309u4eda28b7v8973556b983df63a@mail.gmail.com> <20080626203334.GA18237@cgi.jachomes.com> Message-ID: <48642C9E.70806@wvi.com> Owen DeLong wrote: > Whether some choose to do that or not, I believe that the point is that: > > 1. Nobody is FORCING them to do so. > > 2. Most are _NOT_ doing so. > > 3. It is somewhat anti-social to do so, but, that has rarely been a > constraint on corporate greed, especially amongst the Intelectual > Property crowd. > > Owen > > On that note, it will be very interesting to see who manages to register the *.sucks TLD, and what they do with it. -- Jeff Shultz From ksimpson at mailchannels.com Thu Jun 26 19:16:52 2008 From: ksimpson at mailchannels.com (Ken Simpson) Date: Thu, 26 Jun 2008 17:16:52 -0700 Subject: ICANN opens up Pandora's Box of new TLDs In-Reply-To: <48642C9E.70806@wvi.com> References: <7ff145960806261309u4eda28b7v8973556b983df63a@mail.gmail.com> <20080626203334.GA18237@cgi.jachomes.com> <48642C9E.70806@wvi.com> Message-ID: <46610B65-23E5-466E-B1FF-FEB1C56D7774@mailchannels.com> > On that note, it will be very interesting to see who manages to > register the *.sucks TLD, and what they do with it. Oooh -- dibs on that one. And .some, so you can register awe.some, trouble.some, and fear.some. And .ous, which would allow humm.ous, seri.ous, fabul.ous, etc.. Oh - vomit - this is gonna hurt. Regards, Ken From tme at multicasttech.com Thu Jun 26 19:20:08 2008 From: tme at multicasttech.com (Marshall Eubanks) Date: Thu, 26 Jun 2008 20:20:08 -0400 Subject: ICANN opens up Pandora's Box of new TLDs In-Reply-To: <48642C9E.70806@wvi.com> References: <7ff145960806261309u4eda28b7v8973556b983df63a@mail.gmail.com> <20080626203334.GA18237@cgi.jachomes.com> <48642C9E.70806@wvi.com> Message-ID: I see an auction on that one. Marshall On Jun 26, 2008, at 7:56 PM, Jeff Shultz wrote: > Owen DeLong wrote: > >> Whether some choose to do that or not, I believe that the point is >> that: >> 1. Nobody is FORCING them to do so. >> 2. Most are _NOT_ doing so. >> 3. It is somewhat anti-social to do so, but, that has rarely >> been a >> constraint on corporate greed, especially amongst the Intelectual >> Property crowd. >> Owen > > On that note, it will be very interesting to see who manages to > register the *.sucks TLD, and what they do with it. > > -- > Jeff Shultz > From tomb at byrneit.net Thu Jun 26 19:28:24 2008 From: tomb at byrneit.net (Tomas L. Byrnes) Date: Thu, 26 Jun 2008 17:28:24 -0700 Subject: ICANN opens up Pandora's Box of new TLDs In-Reply-To: References: <7ff145960806261309u4eda28b7v8973556b983df63a@mail.gmail.com> <20080626203334.GA18237@cgi.jachomes.com> <48642C9E.70806@wvi.com> Message-ID: <70D072392E56884193E3D2DE09C097A9F28F@pascal.zaphodb.org> Followed by .bites And .rules and .rules And so the DNS descends into anarchy, and search engines become more empowered. Cacophony merely empowers those who control the amp. > -----Original Message----- > From: Marshall Eubanks [mailto:tme at multicasttech.com] > Sent: Thursday, June 26, 2008 5:20 PM > To: Jeff Shultz > Cc: NANOG list > Subject: Re: ICANN opens up Pandora's Box of new TLDs > > I see an auction on that one. > > Marshall > > On Jun 26, 2008, at 7:56 PM, Jeff Shultz wrote: > > > Owen DeLong wrote: > > > >> Whether some choose to do that or not, I believe that the point is > >> that: > >> 1. Nobody is FORCING them to do so. > >> 2. Most are _NOT_ doing so. > >> 3. It is somewhat anti-social to do so, but, that has rarely > >> been a > >> constraint on corporate greed, especially amongst the > Intelectual > >> Property crowd. > >> Owen > > > > On that note, it will be very interesting to see who manages to > > register the *.sucks TLD, and what they do with it. > > > > -- > > Jeff Shultz > > > > > From owen at delong.com Thu Jun 26 19:45:31 2008 From: owen at delong.com (Owen DeLong) Date: Thu, 26 Jun 2008 17:45:31 -0700 Subject: ICANN opens up Pandora's Box of new TLDs In-Reply-To: References: Message-ID: <35D23E15-AD3A-49D1-BFE6-E2CE69F438D5@delong.com> On Jun 26, 2008, at 4:30 PM, Jason Williams wrote: > >> 3. It is somewhat anti-social to do so, but, that has rarely been a >> constraint on corporate greed, especially amongst the Intelectual >> Property crowd. > > It doesn't seem to me to be "anti-social" behavior to ensure when your > customers mistype your domain as a .net or .de (depending on the > customer's > locale) that they still end up at your site. Definitely, wouldn't > ascribe it > as corporate greed. > You are welcome to ascribe it to whatever you want. I will note that very few Non-profit organizations engage in such behavior. Very few governments do so, either. In fact, absent a corporate profit motive, this behavior seems very rare. It is my considered opinion that turning control of the Domain Name system over to WIPO and allowing them to decide that domains and trademarks had common namespace to ill-defined levels of degree with different categorical mappings that also had undefined translations was one of the biggest mistakes in internet history. Owen From trejrco at gmail.com Thu Jun 26 19:48:08 2008 From: trejrco at gmail.com (TJ) Date: Thu, 26 Jun 2008 20:48:08 -0400 Subject: ICANN opens up Pandora's Box of new TLDs In-Reply-To: <200806262259.XAA10700@sunf10.rd.bbc.co.uk> References: <200806262259.XAA10700@sunf10.rd.bbc.co.uk> Message-ID: <004b01c8d7ef$813f3d20$83bdb760$@com> Ah, but some are ... for trademark or brand protection usually. I know _one_ company that paid $140k just for domain names related to a rebranding effort. /TJ -----Original Message----- From: Brandon Butterworth [mailto:brandon at rd.bbc.co.uk] Sent: Thursday, June 26, 2008 6:59 PM To: nanog at nanog.org Subject: Re: ICANN opens up Pandora's Box of new TLDs > And no, companies *aren't* "forced to pay for another domain name" > just because a new TLD appears -- they aren't doing it *now* From frnkblk at iname.com Thu Jun 26 19:54:42 2008 From: frnkblk at iname.com (Frank Bulk - iNAME) Date: Thu, 26 Jun 2008 19:54:42 -0500 Subject: Possible explanations for a large hop in latency In-Reply-To: <48642E62.70206@fluidhosting.com> References: <48642E62.70206@fluidhosting.com> Message-ID: Did that satisfy you? I guess with MPLS they could tag the traffic and send it around the country twice and I wouldn't see it at L3. Frank -----Original Message----- From: John T. Yocum [mailto:john at fluidhosting.com] Sent: Thursday, June 26, 2008 7:04 PM To: frnkblk at iname.com Cc: nanog list Subject: Re: Possible explanations for a large hop in latency When I asked ATT about the sudden latency jump I see in traceroutes, they told me it was due to how their MPLS network is setup. --John Frank Bulk wrote: > Our upstream provider has a connection to AT&T (12.88.71.13) where I > relatively consistently measure with a RTT of 15 msec, but the next hop > (12.122.112.22) comes in with a RTT of 85 msec. Unless AT&T is sending that > traffic over a cable modem or to Europe and back, I can't see a reason why > there is a consistent ~70 msec jump in RTT. Hops farther along the route > are just a few msec more each hop, so it doesn't appear that 12.122.112.22 > has some kind of ICMP rate-limiting. > > Is this a real performance issue, or is there some logical explanation? > > Frank > > From john at fluidhosting.com Thu Jun 26 20:09:25 2008 From: john at fluidhosting.com (John T. Yocum) Date: Thu, 26 Jun 2008 18:09:25 -0700 Subject: Possible explanations for a large hop in latency In-Reply-To: References: <48642E62.70206@fluidhosting.com> Message-ID: <48643DC5.1040208@fluidhosting.com> The explanation I got, was that the latency seen at the first hop was actually a reply from the last hop in the path across their MPLS network. Hence, all the following hops had very similar latency. Personally, I thought it was rather strange for them to do that. And, I've never seen that occur on any other network. Perhaps someone from ATT would like to chime in. --John Frank Bulk - iNAME wrote: > Did that satisfy you? I guess with MPLS they could tag the traffic and send > it around the country twice and I wouldn't see it at L3. > > Frank > > -----Original Message----- > From: John T. Yocum [mailto:john at fluidhosting.com] > Sent: Thursday, June 26, 2008 7:04 PM > To: frnkblk at iname.com > Cc: nanog list > Subject: Re: Possible explanations for a large hop in latency > > When I asked ATT about the sudden latency jump I see in traceroutes, > they told me it was due to how their MPLS network is setup. > > --John > > Frank Bulk wrote: >> Our upstream provider has a connection to AT&T (12.88.71.13) where I >> relatively consistently measure with a RTT of 15 msec, but the next hop >> (12.122.112.22) comes in with a RTT of 85 msec. Unless AT&T is sending > that >> traffic over a cable modem or to Europe and back, I can't see a reason why >> there is a consistent ~70 msec jump in RTT. Hops farther along the route >> are just a few msec more each hop, so it doesn't appear that 12.122.112.22 >> has some kind of ICMP rate-limiting. >> >> Is this a real performance issue, or is there some logical explanation? >> >> Frank >> >> > > From cmadams at hiwaay.net Thu Jun 26 20:13:01 2008 From: cmadams at hiwaay.net (Chris Adams) Date: Thu, 26 Jun 2008 20:13:01 -0500 Subject: ICANN opens up Pandora's Box of new TLDs In-Reply-To: <46610B65-23E5-466E-B1FF-FEB1C56D7774@mailchannels.com> References: <7ff145960806261309u4eda28b7v8973556b983df63a@mail.gmail.com> <20080626203334.GA18237@cgi.jachomes.com> <48642C9E.70806@wvi.com> <46610B65-23E5-466E-B1FF-FEB1C56D7774@mailchannels.com> Message-ID: <20080627011301.GA821217@hiwaay.net> Once upon a time, Ken Simpson said: > Oooh -- dibs on that one. And .some, so you can register awe.some, > trouble.some, and fear.some. And .ous, which would allow humm.ous, > seri.ous, fabul.ous, etc.. Somebody on /. mentioned .dot, so you could tell someone to go to: eych tee tee pee colon slash slash slash dot dot dot -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From swmike at swm.pp.se Thu Jun 26 20:16:09 2008 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Fri, 27 Jun 2008 03:16:09 +0200 (CEST) Subject: Possible explanations for a large hop in latency In-Reply-To: <48643DC5.1040208@fluidhosting.com> References: <48642E62.70206@fluidhosting.com> <48643DC5.1040208@fluidhosting.com> Message-ID: On Thu, 26 Jun 2008, John T. Yocum wrote: > The explanation I got, was that the latency seen at the first hop was > actually a reply from the last hop in the path across their MPLS > network. Hence, all the following hops had very similar latency. > > Personally, I thought it was rather strange for them to do that. And, > I've never seen that occur on any other network. This is standard for MPLS, the ICMP TTL expire message is sent along the LSP and returned via the router at the end of the LSP. -- Mikael Abrahamsson email: swmike at swm.pp.se From bobrmr at gmail.com Thu Jun 26 20:19:48 2008 From: bobrmr at gmail.com (Robert Richardson) Date: Thu, 26 Jun 2008 18:19:48 -0700 Subject: Possible explanations for a large hop in latency In-Reply-To: <48643DC5.1040208@fluidhosting.com> References: <48642E62.70206@fluidhosting.com> <48643DC5.1040208@fluidhosting.com> Message-ID: <4aebc7330806261819o6e5eda7aqd16faabfefdc5f1d@mail.gmail.com> They probably don't propagate TTL w/in their MPLS core. Depending on how they have MPLS implemented, you may only see 2 hops on the network; the ingress and egress routers. If the ingress router was in NYC and the egress in Seattle, you could understandably expect a large jump in RTT. Not an ATT customer but do know other providers run their MPLS core's this way... -Robert On Thu, Jun 26, 2008 at 6:09 PM, John T. Yocum wrote: > The explanation I got, was that the latency seen at the first hop was > actually a reply from the last hop in the path across their MPLS network. > Hence, all the following hops had very similar latency. > > Personally, I thought it was rather strange for them to do that. And, I've > never seen that occur on any other network. > > Perhaps someone from ATT would like to chime in. > > --John > > > Frank Bulk - iNAME wrote: > >> Did that satisfy you? I guess with MPLS they could tag the traffic and >> send >> it around the country twice and I wouldn't see it at L3. >> >> Frank >> >> -----Original Message----- >> From: John T. Yocum [mailto:john at fluidhosting.com] Sent: Thursday, June >> 26, 2008 7:04 PM >> To: frnkblk at iname.com >> Cc: nanog list >> Subject: Re: Possible explanations for a large hop in latency >> >> When I asked ATT about the sudden latency jump I see in traceroutes, >> they told me it was due to how their MPLS network is setup. >> >> --John >> >> Frank Bulk wrote: >> >>> Our upstream provider has a connection to AT&T (12.88.71.13) where I >>> relatively consistently measure with a RTT of 15 msec, but the next hop >>> (12.122.112.22) comes in with a RTT of 85 msec. Unless AT&T is sending >>> >> that >> >>> traffic over a cable modem or to Europe and back, I can't see a reason >>> why >>> there is a consistent ~70 msec jump in RTT. Hops farther along the route >>> are just a few msec more each hop, so it doesn't appear that >>> 12.122.112.22 >>> has some kind of ICMP rate-limiting. >>> >>> Is this a real performance issue, or is there some logical explanation? >>> >>> Frank >>> >>> >>> >> >> > > From ml at t-b-o-h.net Thu Jun 26 20:20:48 2008 From: ml at t-b-o-h.net (Tuc at T-B-O-H.NET) Date: Thu, 26 Jun 2008 21:20:48 -0400 (EDT) Subject: ICANN opens up Pandora's Box of new TLDs In-Reply-To: <7ff145960806261309u4eda28b7v8973556b983df63a@mail.gmail.com> Message-ID: <200806270120.m5R1KmGr023251@himinbjorg.tucs-beachin-obx-house.com> > > Two years ago I posed the question here about the need for TLDs > (http://www.mcabee.org/lists/nanog/May-06/msg00110.html). > This all should have been solved by allowing those who wanted/applied for TLDs to be granted them back in 1995 when originally requested : http://www.gtld-mou.org/gtld-discuss/mail-archive/00990.html There was a procedure, people followed it, and IANA decided to go other ways with it. Now years later there is all this red tape restricting things. And if the "powers that be" decide to go back to it, you can replace stormking.com with t-b-o-h.net and I look forward to it! ;) Tuc / Scott Ellentuch From ml at t-b-o-h.net Thu Jun 26 20:23:44 2008 From: ml at t-b-o-h.net (Tuc at T-B-O-H.NET) Date: Thu, 26 Jun 2008 21:23:44 -0400 (EDT) Subject: ICANN opens up Pandora's Box of new TLDs In-Reply-To: <20080627011301.GA821217@hiwaay.net> Message-ID: <200806270123.m5R1NiZG023276@himinbjorg.tucs-beachin-obx-house.com> > > Once upon a time, Ken Simpson said: > > Oooh -- dibs on that one. And .some, so you can register awe.some, > > trouble.some, and fear.some. And .ous, which would allow humm.ous, > > seri.ous, fabul.ous, etc.. > > Somebody on /. mentioned .dot, so you could tell someone to go to: > > eych tee tee pee colon slash slash slash dot dot dot > Yea, I thought that was funny when I owned www . wwwdotnet . net too....Lost a bit later on trying to explain to people. Then again TTSG (PPFG? TPSG? TPFG?) and "T dash B dash O dash H" aren't so fun either. Tuc From frnkblk at iname.com Thu Jun 26 20:32:30 2008 From: frnkblk at iname.com (Frank Bulk - iNAME) Date: Thu, 26 Jun 2008 20:32:30 -0500 Subject: Possible explanations for a large hop in latency In-Reply-To: <48643DC5.1040208@fluidhosting.com> References: <48642E62.70206@fluidhosting.com> <48643DC5.1040208@fluidhosting.com> Message-ID: Thanks for the added information. Even if their MPLS path went from the midwest (where I'm located) to San Francisco and then back to St. Louis (where 12.122.112.22 appears to be), I don't think that accounts for a 70 msec jump in traffic. And I don't think they would (intentionally) create such an inefficient MPLS path. Someone off-list told me they tried to trace to 12.88.71.13, but once they hit an AT&T router their ICMP traffic appeared to be blocked. Frank -----Original Message----- From: John T. Yocum [mailto:john at fluidhosting.com] Sent: Thursday, June 26, 2008 8:09 PM To: frnkblk at iname.com Cc: nanog list Subject: Re: Possible explanations for a large hop in latency The explanation I got, was that the latency seen at the first hop was actually a reply from the last hop in the path across their MPLS network. Hence, all the following hops had very similar latency. Personally, I thought it was rather strange for them to do that. And, I've never seen that occur on any other network. Perhaps someone from ATT would like to chime in. --John Frank Bulk - iNAME wrote: > Did that satisfy you? I guess with MPLS they could tag the traffic and send > it around the country twice and I wouldn't see it at L3. > > Frank > > -----Original Message----- > From: John T. Yocum [mailto:john at fluidhosting.com] > Sent: Thursday, June 26, 2008 7:04 PM > To: frnkblk at iname.com > Cc: nanog list > Subject: Re: Possible explanations for a large hop in latency > > When I asked ATT about the sudden latency jump I see in traceroutes, > they told me it was due to how their MPLS network is setup. > > --John > > Frank Bulk wrote: >> Our upstream provider has a connection to AT&T (12.88.71.13) where I >> relatively consistently measure with a RTT of 15 msec, but the next hop >> (12.122.112.22) comes in with a RTT of 85 msec. Unless AT&T is sending > that >> traffic over a cable modem or to Europe and back, I can't see a reason why >> there is a consistent ~70 msec jump in RTT. Hops farther along the route >> are just a few msec more each hop, so it doesn't appear that 12.122.112.22 >> has some kind of ICMP rate-limiting. >> >> Is this a real performance issue, or is there some logical explanation? >> >> Frank >> >> > > From peiffer at umn.edu Thu Jun 26 21:03:19 2008 From: peiffer at umn.edu (Tim Peiffer) Date: Thu, 26 Jun 2008 21:03:19 -0500 Subject: Possible explanations for a large hop in latency In-Reply-To: References: <48642E62.70206@fluidhosting.com> <48643DC5.1040208@fluidhosting.com> Message-ID: <48644A67.9030305@umn.edu> We had a similar situation going from Minneapolis to Kansas City via Chicago. Normal latency from Minneapolis to Chicago via Level3 MPLS network is about 14msec RTT. When the the circuit from Minneapolis to Chicago went out for one reason or another, our MPLS link went from Minneapolis to Tulsa, to Dallas, and then to Chicago.. That added a little latency in the path from Minneapolis to Chicago.. We didn't need to exceed the SLA in order to cry foul. They didn't intentionally create an inefficient path.. The problem was recognized and fixed the same day. Latency on an MPLS circuit is the cumulative latency on the Label Switch Path, and a number of the hops are invisible. The latency per hop is still the same... you just can't see that your traffic is travelling to say Denver or Dallas. Tim Peiffer Network Support Engineer Networking and Telecommunications Services University of Minnesota/NorthernLights GigaPOP Frank Bulk - iNAME wrote: > Thanks for the added information. > > Even if their MPLS path went from the midwest (where I'm located) to San > Francisco and then back to St. Louis (where 12.122.112.22 appears to be), I > don't think that accounts for a 70 msec jump in traffic. And I don't think > they would (intentionally) create such an inefficient MPLS path. > > Someone off-list told me they tried to trace to 12.88.71.13, but once they > hit an AT&T router their ICMP traffic appeared to be blocked. > > Frank > > -----Original Message----- > From: John T. Yocum [mailto:john at fluidhosting.com] > Sent: Thursday, June 26, 2008 8:09 PM > To: frnkblk at iname.com > Cc: nanog list > Subject: Re: Possible explanations for a large hop in latency > > The explanation I got, was that the latency seen at the first hop was > actually a reply from the last hop in the path across their MPLS > network. Hence, all the following hops had very similar latency. > > Personally, I thought it was rather strange for them to do that. And, > I've never seen that occur on any other network. > > Perhaps someone from ATT would like to chime in. > > --John > > Frank Bulk - iNAME wrote: > >> Did that satisfy you? I guess with MPLS they could tag the traffic and >> > send > >> it around the country twice and I wouldn't see it at L3. >> >> Frank >> >> -----Original Message----- >> From: John T. Yocum [mailto:john at fluidhosting.com] >> Sent: Thursday, June 26, 2008 7:04 PM >> To: frnkblk at iname.com >> Cc: nanog list >> Subject: Re: Possible explanations for a large hop in latency >> >> When I asked ATT about the sudden latency jump I see in traceroutes, >> they told me it was due to how their MPLS network is setup. >> >> --John >> >> Frank Bulk wrote: >> >>> Our upstream provider has a connection to AT&T (12.88.71.13) where I >>> relatively consistently measure with a RTT of 15 msec, but the next hop >>> (12.122.112.22) comes in with a RTT of 85 msec. Unless AT&T is sending >>> >> that >> >>> traffic over a cable modem or to Europe and back, I can't see a reason >>> > why > >>> there is a consistent ~70 msec jump in RTT. Hops farther along the route >>> are just a few msec more each hop, so it doesn't appear that >>> > 12.122.112.22 > >>> has some kind of ICMP rate-limiting. >>> >>> Is this a real performance issue, or is there some logical explanation? >>> >>> Frank >>> >>> >>> >> > > > From williamsjj at digitar.com Thu Jun 26 21:20:00 2008 From: williamsjj at digitar.com (Jason Williams) Date: Thu, 26 Jun 2008 20:20:00 -0600 Subject: ICANN opens up Pandora's Box of new TLDs In-Reply-To: <35D23E15-AD3A-49D1-BFE6-E2CE69F438D5@delong.com> Message-ID: >> > >> > You are welcome to ascribe it to whatever you want. I will note that >> > very few Non-profit organizations engage in such behavior. Very >> > few governments do so, either. In fact, absent a corporate profit >> > motive, this behavior seems very rare. > > Given the level of customer service most governmental agencies and non-profits > provide, they?ve got a lot of other usability holes to fill first before they > start worrying about their ?clients? going to the wrong website. Secondarily, > their clients going to the wrong location isn?t going to put them out of > existence. So on the level that profit=existence I?d agree it?s definitely > profit motivated. But greed is pejorative term. > > -J > ________________________ Jason J. W. Williams COO/CTO, DigiTar http://www.digitar.com Voice: 208.343.8520 Mobile: 208.863.0727 FAX: 208.322-8522 E-mail: williamsjj at digitar.com XMPP/Jabber: williamsjj at digitar.com From frnkblk at iname.com Thu Jun 26 21:27:29 2008 From: frnkblk at iname.com (Frank Bulk - iNAME) Date: Thu, 26 Jun 2008 21:27:29 -0500 Subject: Possible explanations for a large hop in latency In-Reply-To: <4aebc7330806261819o6e5eda7aqd16faabfefdc5f1d@mail.gmail.com> References: <48642E62.70206@fluidhosting.com> <48643DC5.1040208@fluidhosting.com> <4aebc7330806261819o6e5eda7aqd16faabfefdc5f1d@mail.gmail.com> Message-ID: Interestingly enough, when I trace from my Cisco router it seems to show some MPLS labels after the hop of interest (12.88.71.13 to 12.122.112.78, only 24 msec here!). I'm not sure how our Cisco box derives these from a foreign network. Router#traceroute 69.28.226.193 Type escape sequence to abort. Tracing the route to 69.28.226.193 1 sxct.sxcy.mtcnet.net (167.142.156.197) 0 msec 0 msec 0 msec 2 siouxcenter.sxcy.137.netins.net (167.142.180.137) 4 msec 4 msec 4 msec 3 ins-b12-et-4-0-112.desm.netins.net (167.142.57.106) 8 msec 8 msec 8 msec 4 ins-h2-et-1-10-127.desm.netins.net (167.142.57.129) 8 msec 8 msec 8 msec 5 ins-c2-et-pc2-0.desm.netins.net (167.142.57.142) 8 msec 8 msec 8 msec 6 12.88.71.13 28 msec 24 msec 28 msec 7 tbr2.sl9mo.ip.att.net (12.122.112.78) [MPLS: Label 30663 Exp 0] 52 msec 48 msec 52 msec 8 cr2.sl9mo.ip.att.net (12.122.18.69) [MPLS: Label 17306 Exp 0] 52 msec 52 msec 52 msec 9 cr2.cgcil.ip.att.net (12.122.2.21) [MPLS: Label 16558 Exp 0] 52 msec 52 msec 52 msec 10 cr1.cgcil.ip.att.net (12.122.2.53) [MPLS: Label 17002 Exp 0] 48 msec 52 msec 52 msec 11 cr1.n54ny.ip.att.net (12.122.1.189) [MPLS: Label 17033 Exp 0] 52 msec 52 msec 48 msec 12 tbr1.n54ny.ip.att.net (12.122.16.138) [MPLS: Label 32364 Exp 0] 52 msec 52 msec 52 msec 13 12.122.86.165 48 msec 48 msec 52 msec 14 12.118.100.58 60 msec 60 msec 64 msec 15 oc48-po2-0.tor-151f7-cor-2.peer1.net (216.187.115.125) 52 msec 52 msec 68 msec 16 oc48-po7-0.tor-151f-dis-1.peer1.net (216.187.114.149) 52 msec 52 msec 48 msec 17 tor-fe3-5a.ne.peer1.net (216.187.68.6) 52 msec 52 msec * Router# Wondering why the RTT dropped to 24 msec for that hop, I entered both 69.28.226.192 and the IP address that my customer has been complaining about (12.129.255.4) into PingPlotter and I see that those behave very differently. I'm now guessing that AT&T is routing back traffic sent to 12.129.255.4 in a different way (perhaps asymmetrically) than traffic sent to 69.28.226.192, but it doesn't show up until it hits 12.122.112.22. Perhaps it's all those 1's and 2'. ;) I notice that in the low RTT trace router 12.88.71.13 goes to tbr2.sl9mo.ip.att.net (12.122.112.78), but in the high RTT trace, roouter 12.88.71.13 goes to tbr1.sl9mo.ip.att.net (12.122.112.22). Must be something about the way AT&T gets to tbr1.sl9mo.ip.att.net (12.122.112.22). I can't traceroute to either of those networks directly. In fact, I don't appear to be able to traceroute to any of the 12.122.x.x or 12.129.x.x I see in my traceroutes, perhaps because AT&T uses some of that space internally and doesn't advertise it. Frank From: Robert Richardson [mailto:bobrmr at gmail.com] Sent: Thursday, June 26, 2008 8:20 PM To: John T. Yocum Cc: frnkblk at iname.com; nanog list Subject: Re: Possible explanations for a large hop in latency They probably don't propagate TTL w/in their MPLS core. Depending on how they have MPLS implemented, you may only see 2 hops on the network; the ingress and egress routers. If the ingress router was in NYC and the egress in Seattle, you could understandably expect a large jump in RTT. Not an ATT customer but do know other providers run their MPLS core's this way... -Robert On Thu, Jun 26, 2008 at 6:09 PM, John T. Yocum wrote: The explanation I got, was that the latency seen at the first hop was actually a reply from the last hop in the path across their MPLS network. Hence, all the following hops had very similar latency. Personally, I thought it was rather strange for them to do that. And, I've never seen that occur on any other network. Perhaps someone from ATT would like to chime in. --John Frank Bulk - iNAME wrote: Did that satisfy you? I guess with MPLS they could tag the traffic and send it around the country twice and I wouldn't see it at L3. Frank -----Original Message----- From: John T. Yocum [mailto:john at fluidhosting.com] Sent: Thursday, June 26, 2008 7:04 PM To: frnkblk at iname.com Cc: nanog list Subject: Re: Possible explanations for a large hop in latency When I asked ATT about the sudden latency jump I see in traceroutes, they told me it was due to how their MPLS network is setup. --John Frank Bulk wrote: Our upstream provider has a connection to AT&T (12.88.71.13 ) where I relatively consistently measure with a RTT of 15 msec, but the next hop (12.122.112.22 ) comes in with a RTT of 85 msec. Unless AT&T is sending that traffic over a cable modem or to Europe and back, I can't see a reason why there is a consistent ~70 msec jump in RTT. Hops farther along the route are just a few msec more each hop, so it doesn't appear that 12.122.112.22 has some kind of ICMP rate-limiting. Is this a real performance issue, or is there some logical explanation? Frank From rsk at gsp.org Thu Jun 26 21:49:41 2008 From: rsk at gsp.org (Rich Kulawiec) Date: Thu, 26 Jun 2008 22:49:41 -0400 Subject: ICANN opens up Pandora's Box of new TLDs In-Reply-To: <5429E6E0-382A-4711-8D8C-2A241B6E4F6A@mailchannels.com> References: <7ff145960806261309u4eda28b7v8973556b983df63a@mail.gmail.com> <5429E6E0-382A-4711-8D8C-2A241B6E4F6A@mailchannels.com> Message-ID: <20080627024941.GA29345@gsp.org> On Thu, Jun 26, 2008 at 01:34:22PM -0700, Ken Simpson wrote: > How will ICANN be allocating these? An auction format? It will be a > blood bath otherwise.. And for abuse and spam, this is a nightmare. There's no doubt this last will happen since it has *already* happened, as I pointed out in a note to Dave Farber's IP list earlier today. For example: the .info TLD is completely overrun with spammers, to the point where many people, including me, have simply blacklisted the whole thing. It simply became too onerous to maintain a blacklist with hundreds of thousands of individual domains and hundreds of additions per day. We never needed a .info TLD and soon its existence will be moot -- well, except for all the money wasted dealing with squatters and typosquatters and spammers and phishers and other abusers. This follows on the heels of .biz, which is so broadly blacklisted that not even spammers tend to use it much any more. And so on. So the outcome of this is inevitable: expense, litigation, hassle, spam, abuse, and oh-by-the-way massive profits for registrars, which had nothing at all to do with ICANN's decision. Of course not. ---Rsk From bensons at riot.queuefull.net Thu Jun 26 21:57:53 2008 From: bensons at riot.queuefull.net (bensons at riot.queuefull.net) Date: Fri, 27 Jun 2008 02:57:53 +0000 Subject: Possible explanations for a large hop in latency In-Reply-To: References: <48642E62.70206@fluidhosting.com> Message-ID: <1515795301-1214535524-cardhu_decombobulator_blackberry.rim.net-1850691846-@bxe036.bisx.prod.on.blackberry> Depending on whether TTL is propagated into MPLS, this could be true. Though it should also be pointed out that ICMP responses aren't exactly a precise scientific tool... The responding router could just be busy, and the response time could be reflective of load more than link latency etc. Similarly, failure to get any response at all from a router isn't necessarily indicative of packet loss... Cheers, -Benson Sent via BlackBerry from T-Mobile -----Original Message----- From: "Frank Bulk - iNAME" Date: Thu, 26 Jun 2008 19:54:42 To:"'John T. Yocum'" Cc:nanog list Subject: RE: Possible explanations for a large hop in latency Did that satisfy you? I guess with MPLS they could tag the traffic and send it around the country twice and I wouldn't see it at L3. Frank -----Original Message----- From: John T. Yocum [mailto:john at fluidhosting.com] Sent: Thursday, June 26, 2008 7:04 PM To: frnkblk at iname.com Cc: nanog list Subject: Re: Possible explanations for a large hop in latency When I asked ATT about the sudden latency jump I see in traceroutes, they told me it was due to how their MPLS network is setup. --John Frank Bulk wrote: > Our upstream provider has a connection to AT&T (12.88.71.13) where I > relatively consistently measure with a RTT of 15 msec, but the next hop > (12.122.112.22) comes in with a RTT of 85 msec. Unless AT&T is sending that > traffic over a cable modem or to Europe and back, I can't see a reason why > there is a consistent ~70 msec jump in RTT. Hops farther along the route > are just a few msec more each hop, so it doesn't appear that 12.122.112.22 > has some kind of ICMP rate-limiting. > > Is this a real performance issue, or is there some logical explanation? > > Frank > > From yahoo at jimpop.com Thu Jun 26 22:12:43 2008 From: yahoo at jimpop.com (Jim Popovitch) Date: Thu, 26 Jun 2008 23:12:43 -0400 Subject: ICANN opens up Pandora's Box of new TLDs In-Reply-To: <20080627024941.GA29345@gsp.org> References: <7ff145960806261309u4eda28b7v8973556b983df63a@mail.gmail.com> <5429E6E0-382A-4711-8D8C-2A241B6E4F6A@mailchannels.com> <20080627024941.GA29345@gsp.org> Message-ID: <7ff145960806262012r59a2ce9cmef40beb17b45f012@mail.gmail.com> On Thu, Jun 26, 2008 at 10:49 PM, Rich Kulawiec wrote: > So the outcome of this is inevitable: expense, litigation, hassle, > spam, abuse, and oh-by-the-way massive profits for registrars, which > had nothing at all to do with ICANN's decision. Of course not. Perhaps this is straying into OT land... (but I must push the envelope!) ;-) Is there any "full disclosure" clause in ICANN member contracts such that gifts from, or stock in, a Registrar would be declared? -Jim P. From johnl at iecc.com Thu Jun 26 22:29:58 2008 From: johnl at iecc.com (John Levine) Date: 27 Jun 2008 03:29:58 -0000 Subject: ICANN opens up Pandora's Box of new TLDs In-Reply-To: <7ff145960806262012r59a2ce9cmef40beb17b45f012@mail.gmail.com> Message-ID: <20080627032958.8188.qmail@simone.iecc.com> >Is there any "full disclosure" clause in ICANN member contracts such >that gifts from, or stock in, a Registrar would be declared? Since ICANN doesn't have members, no. R's, John From frnkblk at iname.com Thu Jun 26 22:31:50 2008 From: frnkblk at iname.com (Frank Bulk - iNAME) Date: Thu, 26 Jun 2008 22:31:50 -0500 Subject: Possible explanations for a large hop in latency In-Reply-To: References: <48642E62.70206@fluidhosting.com> <48643DC5.1040208@fluidhosting.com> <4aebc7330806261819o6e5eda7aqd16faabfefdc5f1d@mail.gmail.com> Message-ID: Just google "tbr1.sl9mo.ip.att.net" and it's clear that high latency through that point has occurred before. And guess what kind of customer complained to me about the latency? A gamer. Frank -----Original Message----- From: Frank Bulk - iNAME [mailto:frnkblk at iname.com] Sent: Thursday, June 26, 2008 9:27 PM To: 'Robert Richardson'; John T. Yocum Cc: nanog list Subject: RE: Possible explanations for a large hop in latency Wondering why the RTT dropped to 24 msec for that hop, I entered both 69.28.226.192 and the IP address that my customer has been complaining about (12.129.255.4) into PingPlotter and I see that those behave very differently. I'm now guessing that AT&T is routing back traffic sent to 12.129.255.4 in a different way (perhaps asymmetrically) than traffic sent to 69.28.226.192, but it doesn't show up until it hits 12.122.112.22. Perhaps it's all those 1's and 2'. ;) I notice that in the low RTT trace router 12.88.71.13 goes to tbr2.sl9mo.ip.att.net (12.122.112.78), but in the high RTT trace, roouter 12.88.71.13 goes to tbr1.sl9mo.ip.att.net (12.122.112.22). Must be something about the way AT&T gets to tbr1.sl9mo.ip.att.net (12.122.112.22). I can't traceroute to either of those networks directly. In fact, I don't appear to be able to traceroute to any of the 12.122.x.x or 12.129.x.x I see in my traceroutes, perhaps because AT&T uses some of that space internally and doesn't advertise it. Frank From: Robert Richardson [mailto:bobrmr at gmail.com] Sent: Thursday, June 26, 2008 8:20 PM To: John T. Yocum Cc: frnkblk at iname.com; nanog list Subject: Re: Possible explanations for a large hop in latency They probably don't propagate TTL w/in their MPLS core. Depending on how they have MPLS implemented, you may only see 2 hops on the network; the ingress and egress routers. If the ingress router was in NYC and the egress in Seattle, you could understandably expect a large jump in RTT. Not an ATT customer but do know other providers run their MPLS core's this way... -Robert On Thu, Jun 26, 2008 at 6:09 PM, John T. Yocum wrote: The explanation I got, was that the latency seen at the first hop was actually a reply from the last hop in the path across their MPLS network. Hence, all the following hops had very similar latency. Personally, I thought it was rather strange for them to do that. And, I've never seen that occur on any other network. Perhaps someone from ATT would like to chime in. --John Frank Bulk - iNAME wrote: Did that satisfy you? I guess with MPLS they could tag the traffic and send it around the country twice and I wouldn't see it at L3. Frank -----Original Message----- From: John T. Yocum [mailto:john at fluidhosting.com] Sent: Thursday, June 26, 2008 7:04 PM To: frnkblk at iname.com Cc: nanog list Subject: Re: Possible explanations for a large hop in latency When I asked ATT about the sudden latency jump I see in traceroutes, they told me it was due to how their MPLS network is setup. --John Frank Bulk wrote: Our upstream provider has a connection to AT&T (12.88.71.13 ) where I relatively consistently measure with a RTT of 15 msec, but the next hop (12.122.112.22 ) comes in with a RTT of 85 msec. Unless AT&T is sending that traffic over a cable modem or to Europe and back, I can't see a reason why there is a consistent ~70 msec jump in RTT. Hops farther along the route are just a few msec more each hop, so it doesn't appear that 12.122.112.22 has some kind of ICMP rate-limiting. Is this a real performance issue, or is there some logical explanation? Frank From randy at psg.com Thu Jun 26 22:36:14 2008 From: randy at psg.com (Randy Bush) Date: Fri, 27 Jun 2008 12:36:14 +0900 Subject: Possible explanations for a large hop in latency In-Reply-To: References: <48642E62.70206@fluidhosting.com> <48643DC5.1040208@fluidhosting.com> <4aebc7330806261819o6e5eda7aqd16faabfefdc5f1d@mail.gmail.com> Message-ID: <4864602E.6060308@psg.com> Frank Bulk - iNAME wrote: > Just google "tbr1.sl9mo.ip.att.net" and it's clear that high latency through > that point has occurred before. And guess what kind of customer complained > to me about the latency? A gamer. you can pay a lot of money for the net propagation anomaly detection services that gamers give you for free. randy From frnkblk at iname.com Thu Jun 26 22:37:34 2008 From: frnkblk at iname.com (Frank Bulk - iNAME) Date: Thu, 26 Jun 2008 22:37:34 -0500 Subject: ICANN opens up Pandora's Box of new TLDs In-Reply-To: <20080627024941.GA29345@gsp.org> References: <7ff145960806261309u4eda28b7v8973556b983df63a@mail.gmail.com> <5429E6E0-382A-4711-8D8C-2A241B6E4F6A@mailchannels.com> <20080627024941.GA29345@gsp.org> Message-ID: ...which is why it might be a strategy to blacklist all new TLDs (if this proposal gets through) and whitelist just .com, .net, etc. Frank -----Original Message----- From: Rich Kulawiec [mailto:rsk at gsp.org] Sent: Thursday, June 26, 2008 9:50 PM To: nanog at nanog.org Subject: Re: ICANN opens up Pandora's Box of new TLDs On Thu, Jun 26, 2008 at 01:34:22PM -0700, Ken Simpson wrote: > How will ICANN be allocating these? An auction format? It will be a > blood bath otherwise.. And for abuse and spam, this is a nightmare. There's no doubt this last will happen since it has *already* happened, as I pointed out in a note to Dave Farber's IP list earlier today. For example: the .info TLD is completely overrun with spammers, to the point where many people, including me, have simply blacklisted the whole thing. It simply became too onerous to maintain a blacklist with hundreds of thousands of individual domains and hundreds of additions per day. We never needed a .info TLD and soon its existence will be moot -- well, except for all the money wasted dealing with squatters and typosquatters and spammers and phishers and other abusers. This follows on the heels of .biz, which is so broadly blacklisted that not even spammers tend to use it much any more. And so on. So the outcome of this is inevitable: expense, litigation, hassle, spam, abuse, and oh-by-the-way massive profits for registrars, which had nothing at all to do with ICANN's decision. Of course not. ---Rsk From jfmezei at vaxination.ca Thu Jun 26 23:01:23 2008 From: jfmezei at vaxination.ca (=?ISO-8859-1?Q?Jean-Fran=E7ois_Mezei?=) Date: Fri, 27 Jun 2008 00:01:23 -0400 Subject: ICANN opens up Pandora's Box of new TLDs In-Reply-To: <7ff145960806261309u4eda28b7v8973556b983df63a@mail.gmail.com> References: <7ff145960806261309u4eda28b7v8973556b983df63a@mail.gmail.com> Message-ID: <48646613.8020409@vaxination.ca> A while ago, there was come debate about the introduction of a .XXX gTLD with some of the folks objecting to its formation. Does anyone know how if the new gTLD system will still give some "veto" power to some people over some domain names that are morally objectable to some people ? I am not thinking of only .SEX but perhaps also .GOD .GAY .ALLAH .BI .CHRISTIAN .LESBIAN .MORMON .JEW .JEWISH .ISLAM etc. Religions will be interesting especially in cases where there is no central representative for a religion who can make the official registration. And in the case where there would be global conflicts, what happens ? For instance, in the USA "ABC" is the american broadcasting companies, but in australia, it is the Australian Broadcasting Corporation. Is it fair to hand .ABC to either one of the two ? (highest bidder) or will ICANN "lock" .ABC out so that neither can get to it ? I am sure there are many such gTLDs around the world that would conflict across countries. Finally, will there be any performance impact on DNS servers around the world (thinking of caching issues) ? From drc at virtualized.org Thu Jun 26 23:18:54 2008 From: drc at virtualized.org (David Conrad) Date: Thu, 26 Jun 2008 21:18:54 -0700 Subject: ICANN opens up Pandora's Box of new TLDs In-Reply-To: <7ff145960806262012r59a2ce9cmef40beb17b45f012@mail.gmail.com> References: <7ff145960806261309u4eda28b7v8973556b983df63a@mail.gmail.com> <5429E6E0-382A-4711-8D8C-2A241B6E4F6A@mailchannels.com> <20080627024941.GA29345@gsp.org> <7ff145960806262012r59a2ce9cmef40beb17b45f012@mail.gmail.com> Message-ID: <7976C0A3-19E4-4F1C-8CCD-1F4CEEC345EB@virtualized.org> On Jun 26, 2008, at 8:12 PM, Jim Popovitch wrote: > Is there any "full disclosure" clause in ICANN member contracts such > that gifts from, or stock in, a Registrar would be declared? Not sure who an "ICANN member" would be. ICANN as a California 501c(3) has to publish all it's financial details. The ICANN Board of Trustees (who makes the final decision within ICANN on TLD-related matters) must abide by a Conflict of Interest Policy (http://www.icann.org/committees/coi/coi-policy-04mar99.htm ). Regards, -drc From drc at virtualized.org Thu Jun 26 23:28:30 2008 From: drc at virtualized.org (David Conrad) Date: Thu, 26 Jun 2008 21:28:30 -0700 Subject: ICANN opens up Pandora's Box of new TLDs In-Reply-To: <48646613.8020409@vaxination.ca> References: <7ff145960806261309u4eda28b7v8973556b983df63a@mail.gmail.com> <48646613.8020409@vaxination.ca> Message-ID: <3AF701D8-9EE9-424A-BF71-DB9019119E51@virtualized.org> On Jun 26, 2008, at 9:01 PM, Jean-Fran?ois Mezei wrote: > Does anyone know how if the new gTLD system will still give some > "veto" > power to some people over some domain names that are morally > objectable > to some people ? See pages 17 - 20 of https://par.icann.org/files/paris/gTLDUpdateParis-23jun08.pdf > Is it fair to hand .ABC to either one of the two ? (highest bidder) or > will ICANN "lock" .ABC out so that neither can get to it ? I am sure > there are many such gTLDs around the world that would conflict across > countries. See pages 22 - 25 of https://par.icann.org/files/paris/gTLDUpdateParis-23jun08.pdf > Finally, will there be any performance impact on DNS servers around > the > world (thinking of caching issues) ? Extremely unlikely (IMHO). Regards, -drc From psa at otoh.org Fri Jun 27 00:34:18 2008 From: psa at otoh.org (Paul Armstrong) Date: Fri, 27 Jun 2008 05:34:18 +0000 Subject: OS, Hardware, Network - Logging, Monitoring, and Alerting In-Reply-To: <20080626092204.GR24243@datavibe.net> References: <20080626092204.GR24243@datavibe.net> Message-ID: <20080627053418.GC5466@suricate.otoh.org> At 2008-06-26T02:22-0700, Rev. Jeffrey Paul wrote: > Other stuff we really need to keep an eye on is hardware - redundant > PSU status in our 7204s and Dells, temperatures and voltages Do yourself a favor, monitor temp in C. Most stuff only does C, people burn routers if there's a mix of C and F (I set the alarm to 90, why didn't it shut down? Well, you should have set it to 30, the router only understands C). > 1) Is SNMP the best way to do this? Obviously some of the data (service > checks) will need to be collected other ways. Pretty much. Particularly with NetSNMP, you can hook in external commands etc. Check out http://www.net-snmp.org/docs/man/snmpd.conf.html Arbitrary Extension Commands If you don't use SNMP for everything, you're going to be stuck with hooking SNMP into whatever you do use so that all your networking kit and environmental monitors can be monitored. > 2) Is there any good solution that does both logging/trending of this > data and also notification/monitoring/alerting? I've used both Nagios > and Cacti in the past, and, due to the number of individual things being > monitored (3-5 items per OS instance, 5-10 items per physical server, > 10-50 things per network device), setting them both up independently > seems like a huge pain. Also, I've never really liked Nagios that much. Take a look at OpenNMS.... > There's got to be a better way. What do you guys use? We wrote our own, but that's a company culture thing. Paul -- End dual-measurement, let's finish going metric! http://gometric.us/ http://www.metric.org/ From randy at psg.com Fri Jun 27 00:51:25 2008 From: randy at psg.com (Randy Bush) Date: Fri, 27 Jun 2008 14:51:25 +0900 Subject: ICANN opens up Pandora's Box of new TLDs In-Reply-To: <3AF701D8-9EE9-424A-BF71-DB9019119E51@virtualized.org> References: <7ff145960806261309u4eda28b7v8973556b983df63a@mail.gmail.com> <48646613.8020409@vaxination.ca> <3AF701D8-9EE9-424A-BF71-DB9019119E51@virtualized.org> Message-ID: <48647FDD.2090505@psg.com> hi drc, does anyone find it droll that the jr high school like clique of root server operators is gonna bear the burden of this, while billy et alia sank the iana usefully signing the root? randy From swmike at swm.pp.se Fri Jun 27 01:50:52 2008 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Fri, 27 Jun 2008 08:50:52 +0200 (CEST) Subject: Possible explanations for a large hop in latency In-Reply-To: References: <48642E62.70206@fluidhosting.com> <48643DC5.1040208@fluidhosting.com> <4aebc7330806261819o6e5eda7aqd16faabfefdc5f1d@mail.gmail.com> Message-ID: On Thu, 26 Jun 2008, Frank Bulk - iNAME wrote: > Interestingly enough, when I trace from my Cisco router it seems to show > some MPLS labels after the hop of interest (12.88.71.13 to 12.122.112.78, > only 24 msec here!). I'm not sure how our Cisco box derives these from a > foreign network. The ICMP packet (TTL exceeded in transit) contains a copy of the packet which TTL expired, including the labels, so label information is available to traceroute. -- Mikael Abrahamsson email: swmike at swm.pp.se From michael.dillon at bt.com Fri Jun 27 02:43:51 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Fri, 27 Jun 2008 08:43:51 +0100 Subject: ICANN opens up Pandora's Box of new TLDs In-Reply-To: <48640FC2.2000909@spaghetti.zurich.ibm.com> Message-ID: > Some people are going to get very rich over this. How do you know this? Judging by the past experience of TLDs there will not be a rush of customers but there will be a rush of people trying to make a buck. In such a scenario, nobody makes much money unless they somehow link the TLD product to something else which is profitable. --Michael Dillon From michael.dillon at bt.com Fri Jun 27 02:47:48 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Fri, 27 Jun 2008 08:47:48 +0100 Subject: ICANN opens up Pandora's Box of new TLDs In-Reply-To: <200806262259.XAA10700@sunf10.rd.bbc.co.uk> Message-ID: > > And no, companies *aren't* "forced to pay for another domain name" > > just because a new TLD appears -- they aren't doing it *now* > > Oh yes we are Looking at bbc.org and bbc.tv suggests that you are not. --Michael Dillon From michael.dillon at bt.com Fri Jun 27 02:55:37 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Fri, 27 Jun 2008 08:55:37 +0100 Subject: ICANN opens up Pandora's Box of new TLDs In-Reply-To: Message-ID: > There are probably some variations based on the zone, > languages, IDN'ability, etc., but it certainly is a good idea > to be bankofamerica.* for reasons that I think are obvious to > most of us. To make it hard for your customers to figure out whether a URL is legitimately owned by the bank? To make it easier for evil guys to steal from your customers by registering bonkofamerica.*? Back to language examples. It would be perfectly legitimate for BBC.ru to be owned by someone other than the well-known broadcaster because in Russian, BBC is the abbreviation for the air force. Probably this applies even more to BBC.aero. IMHO things work better when you have a home TLD and then only use other TLDs when it relates to your business operations. For instance example.com is the home TLD, example.net is used by their consumer broadband division, example.co.uk by their UK sales branch and example.cn by their manufacturing division in Shanghai. --Michael Dillon From lbalazs at lib.unideb.hu Fri Jun 27 03:28:33 2008 From: lbalazs at lib.unideb.hu (Balazs Laszlo) Date: Fri, 27 Jun 2008 10:28:33 +0200 Subject: ICANN opens up Pandora's Box of new TLDs In-Reply-To: References: Message-ID: <4864A4B1.2060505@lib.unideb.hu> michael.dillon at bt.com i'rta: >> There are probably some variations based on the zone, >> languages, IDN'ability, etc., but it certainly is a good idea >> to be bankofamerica.* for reasons that I think are obvious to >> most of us. >> > > To make it hard for your customers to figure out whether a URL > is legitimately owned by the bank? To make it easier for evil guys > to steal from your customers by registering bonkofamerica.* Maybe somebody start a trusted service under a new TLD, and you can block all the others. Laszlo Balazs From jeroen at unfix.org Fri Jun 27 03:50:39 2008 From: jeroen at unfix.org (Jeroen Massar) Date: Fri, 27 Jun 2008 10:50:39 +0200 Subject: ICANN opens up Pandora's Box of new TLDs In-Reply-To: <4864A4B1.2060505@lib.unideb.hu> References: <4864A4B1.2060505@lib.unideb.hu> Message-ID: <4864A9DF.9040603@spaghetti.zurich.ibm.com> Balazs Laszlo wrote: > michael.dillon at bt.com i'rta: >>> There are probably some variations based on the zone, languages, >>> IDN'ability, etc., but it certainly is a good idea to be >>> bankofamerica.* for reasons that I think are obvious to most of us. >>> >> >> To make it hard for your customers to figure out whether a URL >> is legitimately owned by the bank? To make it easier for evil guys >> to steal from your customers by registering bonkofamerica.* > Maybe somebody start a trusted service under a new TLD, > and you can block all the others. For three seconds I thought it was maybe a nice idea for this DNS thing to be cleansed, just stick everything under this new 'trusted' TLD, but then I realized that it can't work, as who is going to decide on what is 'trusted' or not? There is a root (even per TLD and per domain) where delegations come from, as such, there is a central authority and thus a couple of people who say 'trusted' and 'untrusted', or actually 'good' and 'evil'. This was also the whole point of having ccTLDs, so that every country at least could have their own share of the tree (hoping that the root had truly trusted people who would not just kick a part of the tree out (Russia would like to kick out .es now I guess ;) If you want trust, a trust-metric (eg PGP) could partially work. Still, that is not true trust, as it is only an attestation that at the point you said 'good' or 'evil' you found it to be like that. The internet (un)fortunately has this great dynamics factor, as such, now it might be good, all of a sudden some Russian hackers own www.ipv6.elmundo.es (which will then report on Russian winning and Spain loosing) and even though everybody trusts that site for the purpose of 'good domain' and maybe 'good reporting' it will actually be evil. Countering this is going to be extremely difficult, as you need to get everybody who trusts it to update their opinion. Or how do you get a committee to decide 'that site/side is evil'. Difficult. Currently people just trust Google and Mozilla and a various of other vendors to do this for them. This seems to work in some ways, but still on mostly static lists inside the browser, which only updates once in a while thus not very quick either. And how good is Google in not doing evil in just putting all the Russian sites on the list and blocking them off? You don't know. Evil is just what one perceives, and what is good for you, might not be good for others. If you are 'good', it is just because some people you know like you, while when you are 'evil' it is just because you are on the 'wrong' side. Thus no, I don't see '.trusted' actually being trusted, as it simply will exclude businesses which are not trusted by the other ones who control .trusted and thus will be very nice for the anti-competition laws that exist. Only real solution that I currently see seems to be: - pick a search engine you think you can trust (to degrees of etc) - type in what you are looking for, hit search if the ranking of a site is not high enough then either the site is not trusted enough because there are no links there or because tracking software didn't find enough people going there and all the other factors they use they just fail. - let the search engine warn you "that site might be evil" - go to the page. Don't care about the URL though, the search engine already and all their trust made sure it is a 'good' site. - Use it. That of course only covers web, but that is what most general population folks are using anyway. Thus DNS is here only used for where it was supposed to, converting a hostname into an IP address, in the background, with the user not caring about what the hostname is. As such the only thing what matters about host/domainnames will be how pretty they look, nothing more, nothing less. I still don't get why ever movie needs their own domainname, which means that there have to be a lot of sites actually referring to that new domain to be actually able to find the movie in the first place, that while the company that produces it could easily put a subpage on their website or eek a subdomain, and it will all work like a charm including keeping ones PageRank intact and local without having to pay any amount of cash. Then again, domaincapers will register it and get a few hits for it, because people apparently still trust in typing in URL's... Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 187 bytes Desc: OpenPGP digital signature URL: From tme at multicasttech.com Fri Jun 27 04:12:57 2008 From: tme at multicasttech.com (Marshall Eubanks) Date: Fri, 27 Jun 2008 05:12:57 -0400 Subject: ICANN opens up Pandora's Box of new TLDs In-Reply-To: <200806270120.m5R1KmGr023251@himinbjorg.tucs-beachin-obx-house.com> References: <200806270120.m5R1KmGr023251@himinbjorg.tucs-beachin-obx-house.com> Message-ID: <5647AFE5-D11E-496C-A8FC-647BD98BB9C0@multicasttech.com> On Jun 26, 2008, at 9:20 PM, Tuc at T-B-O-H.NET wrote: >> >> Two years ago I posed the question here about the need for TLDs >> (http://www.mcabee.org/lists/nanog/May-06/msg00110.html). >> > This all should have been solved by allowing those who > wanted/applied for TLDs to be granted them back in 1995 when > originally requested : > > http://www.gtld-mou.org/gtld-discuss/mail-archive/00990.html The SNR in the gtld WG was very low, which I think may have been an influencing factor. I do have to wonder, however, what Eugene Kashpureff thinks about this. Regards Marshall > > > There was a procedure, people followed it, and IANA > decided to go other ways with it. Now years later there is > all this red tape restricting things. > > And if the "powers that be" decide to go back to > it, you can replace stormking.com with t-b-o-h.net and I > look forward to it! ;) > > Tuc / Scott Ellentuch > From hannigan at verneglobal.com Fri Jun 27 04:10:42 2008 From: hannigan at verneglobal.com (Martin Hannigan) Date: Fri, 27 Jun 2008 09:10:42 -0000 Subject: ICANN opens up Pandora's Box of new TLDs References: <7ff145960806261309u4eda28b7v8973556b983df63a@mail.gmail.com><48646613.8020409@vaxination.ca> <3AF701D8-9EE9-424A-BF71-DB9019119E51@virtualized.org> Message-ID: >See pages 17 - 20 of https://par.icann.org/files/paris/gTLDUpdateParis-23jun08.pdf >See pages 22 - 25 of https://par.icann.org/files/paris/gTLDUpdateParis-23jun08.pdf I think that this is a good read as well, especially the comments by Dave Wodeley, Susan Crawford, and Wendy Seltzer. https://par.icann.org/files/paris/BoardMeeting_26June08.txt Best, Martin From Jon.Kibler at aset.com Fri Jun 27 04:20:48 2008 From: Jon.Kibler at aset.com (Jon Kibler) Date: Fri, 27 Jun 2008 05:20:48 -0400 Subject: ICANN opens up Pandora's Box of new TLDs In-Reply-To: <48642C9E.70806@wvi.com> References: <7ff145960806261309u4eda28b7v8973556b983df63a@mail.gmail.com> <20080626203334.GA18237@cgi.jachomes.com> <48642C9E.70806@wvi.com> Message-ID: <4864B0F0.4070203@aset.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jeff Shultz wrote: > Owen DeLong wrote: > > On that note, it will be very interesting to see who manages to register > the *.sucks TLD, and what they do with it. > Well, I guess this shoots in the foot Microsoft's name server best practices of setting up your AD domain as foo.LOCAL, using the logic that .LOCAL is safe because it cannot be resolved by the root name servers. Who wants to be the first to try to register *.local? Jon - -- Jon R. Kibler Chief Technical Officer Advanced Systems Engineering Technology, Inc. Charleston, SC USA o: 843-849-8214 c: 843-224-2494 s: 843-564-4224 My PGP Fingerprint is: BAA2 1F2C 5543 5D25 4636 A392 515C 5045 CF39 4253 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkhksPAACgkQUVxQRc85QlMeBACfdWAQcIvJl/CGsi099BDHtFfn i/cAnAwA/VJoraiGJVgEb+7Xu5ZoHDvr =h1Jn -----END PGP SIGNATURE----- From tme at multicasttech.com Fri Jun 27 05:02:21 2008 From: tme at multicasttech.com (Marshall Eubanks) Date: Fri, 27 Jun 2008 06:02:21 -0400 Subject: ICANN opens up Pandora's Box of new TLDs In-Reply-To: <4864B0F0.4070203@aset.com> References: <7ff145960806261309u4eda28b7v8973556b983df63a@mail.gmail.com> <20080626203334.GA18237@cgi.jachomes.com> <48642C9E.70806@wvi.com> <4864B0F0.4070203@aset.com> Message-ID: <3C82C988-8F56-4CF4-A8D5-7A333E7E1812@multicasttech.com> On Jun 27, 2008, at 5:20 AM, Jon Kibler wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Jeff Shultz wrote: >> Owen DeLong wrote: >> >> On that note, it will be very interesting to see who manages to >> register >> the *.sucks TLD, and what they do with it. >> > > > Well, I guess this shoots in the foot Microsoft's name server best > practices of setting up your AD domain as foo.LOCAL, using the logic > that .LOCAL is safe because it cannot be resolved by the root name > servers. > > Who wants to be the first to try to register *.local? They should have been following RFC 2606. Regards Marshall > > > Jon > - -- > Jon R. Kibler > Chief Technical Officer > Advanced Systems Engineering Technology, Inc. > Charleston, SC USA > o: 843-849-8214 > c: 843-224-2494 > s: 843-564-4224 > > My PGP Fingerprint is: > BAA2 1F2C 5543 5D25 4636 A392 515C 5045 CF39 4253 > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.8 (Darwin) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iEYEARECAAYFAkhksPAACgkQUVxQRc85QlMeBACfdWAQcIvJl/CGsi099BDHtFfn > i/cAnAwA/VJoraiGJVgEb+7Xu5ZoHDvr > =h1Jn > -----END PGP SIGNATURE----- > > From jeroen at unfix.org Fri Jun 27 05:17:08 2008 From: jeroen at unfix.org (Jeroen Massar) Date: Fri, 27 Jun 2008 12:17:08 +0200 Subject: ICANN opens up Pandora's Box of new TLDs In-Reply-To: <4864133B.5030409@antient.org> References: <7ff145960806261309u4eda28b7v8973556b983df63a@mail.gmail.com> <5429E6E0-382A-4711-8D8C-2A241B6E4F6A@mailchannels.com> <48640FC2.2000909@spaghetti.zurich.ibm.com> <4864133B.5030409@antient.org> Message-ID: <4864BE24.4060408@spaghetti.zurich.ibm.com> R. Irving wrote: > >> Thank you people doing all the ICANN politics for destroying the >> Internet. > > You know, last time someone ( Robert Metcalfe > ) prophesied the death of > the Internet, when it didn't > come true... we made him eat his words. You up for a repeat ? Wow, you are comparing a nobody like me to a person like Dr. Metcalfe, I am honored, though I don't even start to think that I even compare to him in any way, thus why you come up with that comparison? Just amazing. That said, 'destroying' is not 'death at 11', also I am not so silly to do bets on things. Nice try, but it doesn't work for me. I guess you better stick to the lurking. As for destroying the Internet, it is going to work out that way, as the .com as we know it won't exist any more, and most people only think ".com" when they think Internet. Then again they also only know WWW and nothing else, which is why I really don't like this DNS change which is already solved with search engines. Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 187 bytes Desc: OpenPGP digital signature URL: From Jon.Kibler at aset.com Fri Jun 27 05:44:00 2008 From: Jon.Kibler at aset.com (Jon Kibler) Date: Fri, 27 Jun 2008 06:44:00 -0400 Subject: ICANN opens up Pandora's Box of new TLDs In-Reply-To: <3C82C988-8F56-4CF4-A8D5-7A333E7E1812@multicasttech.com> References: <7ff145960806261309u4eda28b7v8973556b983df63a@mail.gmail.com> <20080626203334.GA18237@cgi.jachomes.com> <48642C9E.70806@wvi.com> <4864B0F0.4070203@aset.com> <3C82C988-8F56-4CF4-A8D5-7A333E7E1812@multicasttech.com> Message-ID: <4864C470.6060400@aset.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Marshall Eubanks wrote: > > On Jun 27, 2008, at 5:20 AM, Jon Kibler wrote: > > Jeff Shultz wrote: >>>> Owen DeLong wrote: >>>> >>>> On that note, it will be very interesting to see who manages to register >>>> the *.sucks TLD, and what they do with it. >>>> > > > Well, I guess this shoots in the foot Microsoft's name server best > practices of setting up your AD domain as foo.LOCAL, using the logic > that .LOCAL is safe because it cannot be resolved by the root name > servers. > > Who wants to be the first to try to register *.local? > >> They should have been following RFC 2606. > >> Regards >> Marshall Thinking about it a little more, what about the common use of 'localhost.localdomain' for 127.0.0.1 in most versions of *nix? I can just imagine the chaos that registering a *.localdomain TLD will cause. Methinks it is time to update RFC2606 to reflect common practices before the new ICANN policies take effect. Jon - -- Jon R. Kibler Chief Technical Officer Advanced Systems Engineering Technology, Inc. Charleston, SC USA o: 843-849-8214 c: 843-224-2494 s: 843-564-4224 My PGP Fingerprint is: BAA2 1F2C 5543 5D25 4636 A392 515C 5045 CF39 4253 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkhkxHAACgkQUVxQRc85QlPfmgCgiIUv7KYOz/U2vdk2DyA04D/O 8Q4An2wK8vilUCJne06qIn/67erB2rkt =ih+F -----END PGP SIGNATURE----- From brunner at nic-naa.net Fri Jun 27 05:57:15 2008 From: brunner at nic-naa.net (Eric Brunner-Williams) Date: Fri, 27 Jun 2008 12:57:15 +0200 Subject: ICANN opens up Pandora's Box of new TLDs In-Reply-To: References: <7ff145960806261309u4eda28b7v8973556b983df63a@mail.gmail.com><48646613.8020409@vaxination.ca> <3AF701D8-9EE9-424A-BF71-DB9019119E51@virtualized.org> Message-ID: <4864C78B.9070900@nic-naa.net> Martin, I wasn't that impressed with Dave's remarks, but I heard them rather than read them, which may have made a difference. I agree with your views on the substance and spirit of Susan's and Wendy's statements. This -- the new GTLD process -- was originally scheduled to get to completion in 2003 and 2004 -- after the initial 2000 round. Eric Martin Hannigan wrote: >> See pages 17 - 20 of https://par.icann.org/files/paris/gTLDUpdateParis-23jun08.pdf >> See pages 22 - 25 of https://par.icann.org/files/paris/gTLDUpdateParis-23jun08.pdf >> > > I think that this is a good read as well, especially the comments by Dave Wodeley, Susan Crawford, and Wendy Seltzer. > > https://par.icann.org/files/paris/BoardMeeting_26June08.txt > > > Best, > > Martin > > > > > > From hannigan at verneglobal.com Fri Jun 27 06:12:46 2008 From: hannigan at verneglobal.com (Martin Hannigan) Date: Fri, 27 Jun 2008 11:12:46 -0000 Subject: ICANN opens up Pandora's Box of new TLDs Message-ID: Eric; The only reason I would have supported rejecting the proposal is the 'morality' language related to offensive TLD's. . What's your take on that part of the process? Marty ----- Original Message ----- From: Eric Brunner-Williams To: Martin Hannigan Cc: nanog at nanog.org ; =?ISO-8859-1?Q?Jean-Fran=E7ois_?=@mxa.skyrr.is <=?ISO-8859-1?Q?Jean-Fran=E7ois_?=@mxa.skyrr.is> Sent: Fri Jun 27 10:57:15 2008 Subject: Re: ICANN opens up Pandora's Box of new TLDs Martin, I wasn't that impressed with Dave's remarks, but I heard them rather than read them, which may have made a difference. I agree with your views on the substance and spirit of Susan's and Wendy's statements. This -- the new GTLD process -- was originally scheduled to get to completion in 2003 and 2004 -- after the initial 2000 round. Eric Martin Hannigan wrote: >> See pages 17 - 20 of https://par.icann.org/files/paris/gTLDUpdateParis-23jun08.pdf >> See pages 22 - 25 of https://par.icann.org/files/paris/gTLDUpdateParis-23jun08.pdf >> > > I think that this is a good read as well, especially the comments by Dave Wodeley, Susan Crawford, and Wendy Seltzer. > > https://par.icann.org/files/paris/BoardMeeting_26June08.txt > > > Best, > > Martin > > > > > > From brunner at nic-naa.net Fri Jun 27 06:25:12 2008 From: brunner at nic-naa.net (Eric Brunner-Williams) Date: Fri, 27 Jun 2008 13:25:12 +0200 Subject: ICANN opens up Pandora's Box of new TLDs In-Reply-To: References: Message-ID: <4864CE18.6090909@nic-naa.net> Martin, You know the phrase "Paris is worth a mass"? Well, we get .paris, as well as .cat, and other reasonable things, plus chaff and clutter. Eric Martin Hannigan wrote: > Eric; > > The only reason I would have supported rejecting the proposal is the 'morality' language related to offensive TLD's. . > > What's your take on that part of the process? > > Marty > > > > ----- Original Message ----- > From: Eric Brunner-Williams > To: Martin Hannigan > Cc: nanog at nanog.org ; =?ISO-8859-1?Q?Jean-Fran=E7ois_?=@mxa.skyrr.is <=?ISO-8859-1?Q?Jean-Fran=E7ois_?=@mxa.skyrr.is> > Sent: Fri Jun 27 10:57:15 2008 > Subject: Re: ICANN opens up Pandora's Box of new TLDs > > Martin, > > I wasn't that impressed with Dave's remarks, but I heard them rather > than read them, which may have made a difference. I agree with your > views on the substance and spirit of Susan's and Wendy's statements. > > This -- the new GTLD process -- was originally scheduled to get to > completion in 2003 and 2004 -- after the initial 2000 round. > > Eric > > Martin Hannigan wrote: > >>> See pages 17 - 20 of https://par.icann.org/files/paris/gTLDUpdateParis-23jun08.pdf >>> See pages 22 - 25 of https://par.icann.org/files/paris/gTLDUpdateParis-23jun08.pdf >>> >>> >> >> I think that this is a good read as well, especially the comments by Dave Wodeley, Susan Crawford, and Wendy Seltzer. >> >> https://par.icann.org/files/paris/BoardMeeting_26June08.txt >> >> >> Best, >> >> Martin >> >> >> >> >> >> >> > > > From brandon at rd.bbc.co.uk Fri Jun 27 06:43:43 2008 From: brandon at rd.bbc.co.uk (Brandon Butterworth) Date: Fri, 27 Jun 2008 12:43:43 +0100 (BST) Subject: ICANN opens up Pandora's Box of new TLDs Message-ID: <200806271143.MAA17183@sunf10.rd.bbc.co.uk> > > > And no, companies *aren't* "forced to pay for another domain name" > > > just because a new TLD appears -- they aren't doing it *now* > > > > Oh yes we are > > Looking at bbc.org and bbc.tv suggests that you are not. We used not to, bbc.org and others are why we started. We did have bbc.tv for a while, what you see now shows why this is a considered a problem. I tried to stick to just one, I was wrong, legal overuled technical. Now we have thousands such as bbcsathalanalatpaxathipataipaxaxonlao.com but not some obvious ones brandon From cidr-report at potaroo.net Fri Jun 27 07:00:05 2008 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 27 Jun 2008 22:00:05 +1000 (EST) Subject: BGP Update Report Message-ID: <200806271200.m5RC05ll009207@wattle.apnic.net> BGP Update Report Interval: 26-May-08 -to- 26-Jun-08 (32 days) Observation Point: BGP Peering with AS2.0 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS4766 299254 3.6% 229.0 -- KIXS-AS-KR Korea Telecom 2 - AS4538 214681 2.6% 43.2 -- ERX-CERNET-BKB China Education and Research Network Center 3 - AS8866 80487 1.0% 251.5 -- BTC-AS Bulgarian Telecommunication Company Plc. 4 - AS5691 74369 0.9% 5720.7 -- MITRE-AS-5 - The MITRE Corporation 5 - AS9583 67573 0.8% 54.6 -- SIFY-AS-IN Sify Limited 6 - AS6140 62576 0.8% 91.4 -- IMPSAT-USA - ImpSat USA, Inc. 7 - AS17974 60255 0.7% 101.8 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia 8 - AS17488 45007 0.5% 36.2 -- HATHWAY-NET-AP Hathway IP Over Cable Internet 9 - AS42787 37363 0.5% 12454.3 -- MMIP-AS MultiMedia IP Ltd. 10 - AS9498 34410 0.4% 28.1 -- BBIL-AP BHARTI BT INTERNET LTD. 11 - AS18231 32875 0.4% 137.6 -- EXATT-AS-AP IOL NETCOM LTD 12 - AS13620 32441 0.4% 6488.2 -- ASN-ELAN - Elan Communications, Inc. 13 - AS15611 32072 0.4% 320.7 -- Iranian Research Organization for Science & Technology 14 - AS8151 30819 0.4% 24.1 -- Uninet S.A. de C.V. 15 - AS21565 30496 0.4% 165.7 -- HTCC - HTC Communications, LLC 16 - AS6471 30463 0.4% 73.4 -- ENTEL CHILE S.A. 17 - AS25994 30205 0.4% 170.6 -- NPG-001 - NPG Cable, INC 18 - AS20115 29647 0.4% 28.1 -- CHARTER-NET-HKY-NC - Charter Communications 19 - AS577 28878 0.3% 36.7 -- BACOM - Bell Canada 20 - AS209 27983 0.3% 9.1 -- ASN-QWEST - Qwest TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS17834 16342 0.2% 16342.0 -- KYOBOAUTO-AS-KR Kyobo Auto Insurance CO.,LTD 2 - AS42787 37363 0.5% 12454.3 -- MMIP-AS MultiMedia IP Ltd. 3 - AS9988 8663 0.1% 8663.0 -- MPT-AP Myanma Post and Telecommunication 4 - AS29910 6943 0.1% 6943.0 -- IACP - INTL. ASSN OF CHIEF OF POLICEI 5 - AS13620 32441 0.4% 6488.2 -- ASN-ELAN - Elan Communications, Inc. 6 - AS5691 74369 0.9% 5720.7 -- MITRE-AS-5 - The MITRE Corporation 7 - AS31003 27353 0.3% 3907.6 -- IRON-MOUNTAIN-UK-AS Iron Mountain UK Ltd 8 - AS40831 7481 0.1% 3740.5 -- ROBERTSDYBDAHL - Roberts & Dybdahl Inc. 9 - AS30287 3714 0.0% 3714.0 -- ALON-USA - ALON USA, LP 10 - AS38513 3666 0.0% 3666.0 -- LINTASARTA-AS-ID PT Aplikanusa Lintasarta 11 - AS23082 18283 0.2% 3656.6 -- MPHI - Michigan Public Health Institute 12 - AS30929 3215 0.0% 3215.0 -- HUTCB Hidrotechnical Faculty - Technical University 13 - AS25250 9088 0.1% 3029.3 -- GAMTEL-AS 14 - AS40256 11568 0.1% 2892.0 -- ACS-HCMS-ASN - Affiliated Computer Services, Inc. 15 - AS39105 2803 0.0% 2803.0 -- CLASS-AS SC Class Computers And Service SRL 16 - AS38069 23984 0.3% 2664.9 -- WARIDTEL-BD-AS-AP Warid Telecom 17 - AS25799 2083 0.0% 2083.0 -- HOLMAN - Holman Enterprises 18 - AS35155 1751 0.0% 1751.0 -- VERBASOFT-AS Verbasoft ASN 19 - AS9747 12837 0.2% 1604.6 -- EZINTERNET-AS-AP EZInternet Pty Ltd 20 - AS38165 14782 0.2% 1478.2 -- ADSNET-AS-ID PT. AMBHARA DUTA SHANTI TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 192.12.120.0/24 74297 0.8% AS5691 -- MITRE-AS-5 - The MITRE Corporation 2 - 213.91.175.0/24 44795 0.5% AS8866 -- BTC-AS Bulgarian Telecommunication Company Plc. 3 - 193.33.184.0/23 37277 0.4% AS42787 -- MMIP-AS MultiMedia IP Ltd. 4 - 221.128.192.0/18 26409 0.3% AS18231 -- EXATT-AS-AP IOL NETCOM LTD 5 - 24.121.123.0/24 25606 0.3% AS25994 -- NPG-001 - NPG Cable, INC 6 - 83.228.71.0/24 25194 0.3% AS8866 -- BTC-AS Bulgarian Telecommunication Company Plc. AS8953 -- ASN-ORANGE-ROMANIA Orange Romania Autonomous System Number 7 - 193.239.114.0/24 23058 0.3% AS31003 -- IRON-MOUNTAIN-UK-AS Iron Mountain UK Ltd 8 - 221.135.230.0/23 19541 0.2% AS9583 -- SIFY-AS-IN Sify Limited 9 - 84.23.102.0/24 17161 0.2% AS24731 -- ASN-NESMA National Engineering Services and Marketing Company Ltd. (NESMA) AS34400 -- ASN-ETTIHADETISALAT Etihad Etisalat 10 - 210.92.148.0/24 16342 0.2% AS17834 -- KYOBOAUTO-AS-KR Kyobo Auto Insurance CO.,LTD 11 - 203.63.26.0/24 12790 0.1% AS9747 -- EZINTERNET-AS-AP EZInternet Pty Ltd 12 - 210.214.88.0/23 9428 0.1% AS9583 -- SIFY-AS-IN Sify Limited 13 - 203.81.64.0/19 8663 0.1% AS9988 -- MPT-AP Myanma Post and Telecommunication 14 - 192.166.49.0/24 7910 0.1% AS3320 -- DTAG Deutsche Telekom AG 15 - 125.23.208.0/20 7009 0.1% AS9498 -- BBIL-AP BHARTI BT INTERNET LTD. 16 - 63.239.134.0/24 6943 0.1% AS29910 -- IACP - INTL. ASSN OF CHIEF OF POLICEI 17 - 64.68.1.0/24 6516 0.1% AS13620 -- ASN-ELAN - Elan Communications, Inc. 18 - 64.68.0.0/24 6513 0.1% AS13620 -- ASN-ELAN - Elan Communications, Inc. 19 - 64.68.9.0/24 6509 0.1% AS13620 -- ASN-ELAN - Elan Communications, Inc. 20 - 64.68.3.0/24 6500 0.1% AS13620 -- ASN-ELAN - Elan Communications, Inc. Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at merit.edu eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From cidr-report at potaroo.net Fri Jun 27 07:00:03 2008 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 27 Jun 2008 22:00:03 +1000 (EST) Subject: The Cidr Report Message-ID: <200806271200.m5RC03ti009178@wattle.apnic.net> This report has been generated at Fri Jun 27 21:16:22 2008 AEST. The report analyses the BGP Routing Table of AS2.0 router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org for a current version of this report. Recent Table History Date Prefixes CIDR Agg 20-06-08 270490 168348 21-06-08 270526 168591 22-06-08 270662 168647 23-06-08 270399 169007 24-06-08 270542 165623 25-06-08 270644 165347 26-06-08 266216 164967 27-06-08 271147 165882 AS Summary 28714 Number of ASes in routing system 12149 Number of ASes announcing only one prefix 4960 Largest number of prefixes announced by an AS AS4538 : ERX-CERNET-BKB China Education and Research Network Center 88347904 Largest address span announced by an AS (/32s) AS721 : DISA-ASNBLK - DoD Network Information Center Aggregation Summary The algorithm used in this report proposes aggregation only when there is a precise match using the AS path, so as to preserve traffic transit policies. Aggregation is also proposed across non-advertised address space ('holes'). --- 27Jun08 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 271356 166009 105347 38.8% All ASes AS4538 4960 880 4080 82.3% ERX-CERNET-BKB China Education and Research Network Center AS209 3031 658 2373 78.3% ASN-QWEST - Qwest AS6389 2670 336 2334 87.4% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS4755 1668 214 1454 87.2% VSNL-AS Videsh Sanchar Nigam Ltd. Autonomous System AS18566 1045 40 1005 96.2% COVAD - Covad Communications Co. AS4323 1466 497 969 66.1% TWTC - Time Warner Telecom, Inc. AS22773 965 69 896 92.8% CCINET-2 - Cox Communications Inc. AS17488 1189 330 859 72.2% HATHWAY-NET-AP Hathway IP Over Cable Internet AS8151 1269 512 757 59.7% Uninet S.A. de C.V. AS11492 1231 479 752 61.1% CABLEONE - CABLE ONE AS19262 917 165 752 82.0% VZGNI-TRANSIT - Verizon Internet Services Inc. AS1785 1080 359 721 66.8% AS-PAETEC-NET - PaeTec Communications, Inc. AS2386 1497 891 606 40.5% INS-AS - AT&T Data Communications Services AS9498 1077 537 540 50.1% BBIL-AP BHARTI BT INTERNET LTD. AS18101 688 148 540 78.5% RIL-IDC Reliance Infocom Ltd Internet Data Centre, AS6478 956 448 508 53.1% ATT-INTERNET3 - AT&T WorldNet Services AS4766 872 382 490 56.2% KIXS-AS-KR Korea Telecom AS855 598 129 469 78.4% CANET-ASN-4 - Bell Aliant AS6197 946 486 460 48.6% BATI-ATL - BellSouth Network Solutions, Inc AS17676 525 82 443 84.4% GIGAINFRA BB TECHNOLOGY Corp. AS22047 565 128 437 77.3% VTR BANDA ANCHA S.A. AS4134 829 397 432 52.1% CHINANET-BACKBONE No.31,Jin-rong Street AS7018 1412 989 423 30.0% ATT-INTERNET4 - AT&T WorldNet Services AS7011 1015 594 421 41.5% FRONTIER-AND-CITIZENS - Frontier Communications of America, Inc. AS4668 679 271 408 60.1% LGNET-AS-KR LG CNS AS9443 489 85 404 82.6% INTERNETPRIMUS-AS-AP Primus Telecommunications AS4780 709 317 392 55.3% SEEDNET Digital United Inc. AS4808 524 145 379 72.3% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS3602 456 79 377 82.7% AS3602-RTI - Rogers Telecom Inc. AS5668 689 328 361 52.4% AS-5668 - CenturyTel Internet Holdings, Inc. Total 36017 10975 25042 69.5% Top 30 total Possible Bogus Routes 24.38.0.0/17 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 24.48.0.0/13 AS19548 ADELPHIA-AS2 - Road Runner HoldCo LLC 24.48.244.0/23 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 24.51.159.0/24 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 24.54.23.0/24 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 24.54.224.0/19 AS20001 ROADRUNNER-WEST - Road Runner HoldCo LLC 24.75.160.0/19 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 24.75.192.0/18 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 24.142.40.0/21 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 24.142.160.0/19 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 24.246.0.0/17 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 24.246.128.0/18 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV - Wireless Broadband via Satellite 63.140.213.0/24 AS22555 UTC - Universal Talkware Corporation 63.141.42.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 63.143.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 63.143.115.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 63.143.251.0/24 AS22555 UTC - Universal Talkware Corporation 63.248.0.0/16 AS3356 LEVEL3 Level 3 Communications 64.7.112.0/21 AS6453 GLOBEINTERNET TATA Communications 64.7.120.0/21 AS6453 GLOBEINTERNET TATA Communications 64.50.128.0/18 AS4565 MEGAPATH2-US - MegaPath Networks Inc. 64.64.159.0/24 AS32004 BIG-ASN - Business Information Group, Inc. 64.144.0.0/15 AS4565 MEGAPATH2-US - MegaPath Networks Inc. 64.188.0.0/16 AS3356 LEVEL3 Level 3 Communications 65.36.8.0/24 AS5696 65.36.9.0/24 AS5696 65.36.33.0/24 AS5696 65.36.52.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 66.11.32.0/20 AS6261 VISINET - Visionary Systems, Inc. 66.11.40.0/21 AS6261 VISINET - Visionary Systems, Inc. 66.54.91.0/24 AS30506 BLACKSUN-1 - Blacksun Technologies LLC 66.55.160.0/19 AS29994 66.64.96.0/20 AS3790 RADIGRAFICA COSTARRICENSE 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.199.32.0/20 AS10397 WISP-AS - Wispnet, LLC 66.206.32.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.33.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.34.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.35.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.40.0/22 AS174 COGENT Cogent/PSI 66.206.44.0/23 AS174 COGENT Cogent/PSI 66.206.47.0/24 AS17557 PKTELECOM-AS-AP Pakistan Telecom 66.207.32.0/20 AS23011 66.219.192.0/18 AS5048 FIBER - FIBERNET Corp. 67.20.0.0/14 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 68.64.0.0/13 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 68.168.0.0/14 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 68.232.0.0/14 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 69.71.192.0/20 AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport 69.80.0.0/17 AS3043 AMPHIB-AS - Amphibian Media Corporation 69.164.0.0/17 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 69.165.102.0/24 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 70.34.0.0/16 AS7843 ADELPHIA-AS - Road Runner HoldCo LLC 80.88.0.0/21 AS33774 DJAWEB 80.88.8.0/22 AS33774 DJAWEB 80.88.10.0/24 AS33774 DJAWEB 80.88.11.0/24 AS33774 DJAWEB 80.88.12.0/24 AS33779 wataniya-telecom-as 87.76.0.0/16 AS3301 TELIANET-SWEDEN TeliaNet Sweden 93.174.176.0/21 AS43451 RADIOLAN-SK-AS RadioLAN, spol. s r.o. 95.192.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 95.255.248.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 114.198.160.0/20 AS9924 TFN-TW Taiwan Fixed Network, Telco and Network Service Provider. 114.198.176.0/20 AS9924 TFN-TW Taiwan Fixed Network, Telco and Network Service Provider. 137.0.0.0/13 AS721 DISA-ASNBLK - DoD Network Information Center 151.135.0.0/16 AS4768 CLIX-NZ TelstraClear Ltd 159.3.211.0/24 AS2687 ASATTCA AT&T Global Network Services - AP 163.142.0.0/16 AS2500 WIDE-BB WIDE Project 166.63.0.0/16 AS33775 NITEL-AS 172.7.0.0/24 AS28175 172.10.1.0/30 AS18305 POSNET POSDATA Co.,Ltd 192.9.200.0/24 AS3602 AS3602-RTI - Rogers Telecom Inc. 192.30.93.0/24 AS17757 HPAUS-AP HP Australia 192.30.94.0/24 AS17757 HPAUS-AP HP Australia 192.40.105.0/24 AS12582 TSF-DATANET-NGD-AS TSF MPLS VPN Services 192.64.85.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.107.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.108.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.177.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.70.164.0/24 AS25689 NRCNET-AS - National Research Council of Canada 192.96.36.0/24 AS5713 SAIX-NET 192.96.37.0/24 AS10474 NETACTIVE 192.96.135.0/24 AS2018 TENET-1 192.96.136.0/23 AS2018 TENET-1 192.96.141.0/24 AS5713 SAIX-NET 192.96.143.0/24 AS2018 TENET-1 192.96.145.0/24 AS2018 TENET-1 192.96.177.0/24 AS6083 POSIX-AFRICA 192.101.45.0/24 AS2905 TICSA-ASN 192.101.46.0/24 AS6503 Avantel, S.A. 192.101.47.0/24 AS6503 Avantel, S.A. 192.101.64.0/21 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.67.0/24 AS21775 192.101.70.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.72.0/24 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.73.0/24 AS4765 WORLDNET-AS World Net & Services Co., Ltd. 192.101.74.0/24 AS1239 SPRINTLINK - Sprint 192.122.212.0/24 AS209 ASN-QWEST - Qwest 192.124.252.0/22 AS680 DFN-IP service G-WiN 192.131.233.0/24 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 192.133.6.0/24 AS10282 EQUANT-CEEUR EQUANT AS for Central and Eastern Europe region 192.153.144.0/21 AS721 DISA-ASNBLK - DoD Network Information Center 192.154.32.0/19 AS81 NCREN - MCNC 192.188.208.0/20 AS721 DISA-ASNBLK - DoD Network Information Center 193.200.114.0/23 AS31530 SERVERCREW-AS Servercrew LTD Autonomes System 194.31.227.0/24 AS21461 TRANSFAIRNET Transfair-net GmbH Krefeld 194.246.72.0/23 AS8893 ARTFILES-AS Artfiles New Media GmbH 196.6.108.0/24 AS5713 SAIX-NET 196.10.119.0/24 AS2018 TENET-1 196.10.122.0/23 AS2018 TENET-1 196.10.251.0/24 AS2018 TENET-1 196.10.252.0/23 AS2018 TENET-1 196.10.254.0/24 AS2018 TENET-1 196.13.101.0/24 AS2018 TENET-1 196.13.102.0/23 AS2018 TENET-1 196.13.104.0/24 AS2018 TENET-1 196.13.121.0/24 AS2018 TENET-1 196.13.125.0/24 AS2018 TENET-1 196.13.126.0/24 AS2018 TENET-1 196.13.169.0/24 AS2018 TENET-1 196.13.174.0/23 AS2018 TENET-1 196.13.176.0/21 AS2018 TENET-1 196.13.192.0/22 AS2018 TENET-1 196.13.196.0/24 AS2018 TENET-1 196.201.98.0/24 AS29571 CITelecom-AS 196.216.132.0/24 AS9207 TAIDE-KE-NAIROBI Taide - Kenya POP 196.216.134.0/24 AS9207 TAIDE-KE-NAIROBI Taide - Kenya POP 198.23.26.0/24 AS4390 BELLATLANTIC-COM - Bell Atlantic, Inc. 198.54.82.0/24 AS2018 TENET-1 198.54.92.0/24 AS2018 TENET-1 198.54.222.0/24 AS2018 TENET-1 198.97.72.0/21 AS721 DISA-ASNBLK - DoD Network Information Center 198.97.80.0/20 AS721 DISA-ASNBLK - DoD Network Information Center 198.97.96.0/19 AS721 DISA-ASNBLK - DoD Network Information Center 198.97.240.0/20 AS721 DISA-ASNBLK - DoD Network Information Center 198.144.96.0/20 AS12185 198.161.87.0/24 AS6539 GT-BELL - Bell Canada 198.167.0.0/16 AS7456 INTERHOP - Interhop Network SERVICES Inc. 198.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 198.169.0.0/16 AS803 SASKTEL - Saskatchewan Telecommunications 198.180.198.0/24 AS23715 SEOUL-INTGW-GXS-AP Global Exchange Services 199.9.128.0/17 AS668 ASN-ASNET-NET-AS - Defense Research and Engineering Network 199.10.0.0/16 AS721 DISA-ASNBLK - DoD Network Information Center 199.114.0.0/21 AS721 DISA-ASNBLK - DoD Network Information Center 199.114.128.0/18 AS721 DISA-ASNBLK - DoD Network Information Center 199.114.130.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.131.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.132.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.134.0/24 AS3541 ITSDN-U4 - DoD Network Information Center 199.114.136.0/24 AS27044 DDN-ASNBLK1 - DoD Network Information Center 199.114.138.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.140.0/24 AS3544 ITSDN-U7 - DoD Network Information Center 199.114.142.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.144.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.148.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.150.0/24 AS6045 DDN-ASNBLK - DoD Network Information Center 199.114.152.0/24 AS27033 DDN-ASNBLK1 - DoD Network Information Center 199.114.153.0/24 AS27034 DDN-ASNBLK1 - DoD Network Information Center 199.114.154.0/24 AS1733 CENTAF-SWA - AF DDN PMO 199.114.156.0/24 AS1733 CENTAF-SWA - AF DDN PMO 199.114.160.0/24 AS1733 CENTAF-SWA - AF DDN PMO 199.121.0.0/16 AS721 DISA-ASNBLK - DoD Network Information Center 199.123.0.0/18 AS721 DISA-ASNBLK - DoD Network Information Center 199.123.16.0/20 AS721 DISA-ASNBLK - DoD Network Information Center 199.123.80.0/21 AS721 DISA-ASNBLK - DoD Network Information Center 199.189.32.0/19 AS7332 IQUEST-AS - IQuest Internet 199.202.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 199.246.116.0/24 AS813 UUNET-CANADA - MCI Communications Services, Inc. d/b/a Verizon Business 202.58.113.0/24 AS19161 INNOCOM-TELECOM - INNOCOM TELECOM 202.73.144.0/20 AS4788 TMNET-AS-AP TM Net, Internet Service Provider 202.80.192.0/20 AS2706 HKSUPER-HK-AP Pacific Internet (Hong Kong) Limited 202.86.252.0/22 AS4748 RESOLINK-AS-AP Resources Link Network Limited 202.86.252.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.253.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.254.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.255.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.90.33.0/24 AS9830 SWIFTONLINE-AS-AP SWIFT ONLINE BORDER AS 202.90.40.0/24 AS9830 SWIFTONLINE-AS-AP SWIFT ONLINE BORDER AS 202.90.41.0/24 AS9830 SWIFTONLINE-AS-AP SWIFT ONLINE BORDER AS 202.90.42.0/24 AS9830 SWIFTONLINE-AS-AP SWIFT ONLINE BORDER AS 202.90.43.0/24 AS9830 SWIFTONLINE-AS-AP SWIFT ONLINE BORDER AS 202.90.44.0/24 AS9830 SWIFTONLINE-AS-AP SWIFT ONLINE BORDER AS 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.94.70.0/24 AS9837 POWERTEL-AP Powertel Ltd 202.124.195.0/24 AS17557 PKTELECOM-AS-AP Pakistan Telecom 202.124.207.0/24 AS17911 BRAINPK-AS-AP Brain Telecommunication Ltd. 202.136.254.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.136.255.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.164.100.0/24 AS18101 RIL-IDC Reliance Infocom Ltd Internet Data Centre, 202.176.228.0/24 AS17988 SINOSAT-AS-AP SINOSAT (HONG KONG) LIMITED 202.176.232.0/24 AS17988 SINOSAT-AS-AP SINOSAT (HONG KONG) LIMITED 202.181.32.0/24 AS4645 ASN-HKNET-AP HKNet Co. Ltd 203.12.45.0/24 AS4854 NETSPACE-AS-AP Netspace Online Systems 203.62.0.0/17 AS7575 AARNET-AS-AP Australian Academic and Reasearch Network (AARNet) 203.78.48.0/20 AS9299 IPG-AS-AP Philippine Long Distance Telephone Company 203.89.139.0/24 AS17911 BRAINPK-AS-AP Brain Telecommunication Ltd. 203.111.192.0/20 AS7473 SINGTEL-AS-AP Singapore Telecom 203.112.97.0/24 AS9942 COMINDICO-AP SOUL Converged Communications Australia 203.112.111.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.113.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.114.0/24 AS4802 ASN-IINET iiNet Limited 203.112.116.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.117.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.118.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.119.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.120.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.121.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.127.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.128.128.0/19 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 203.128.128.0/24 AS23849 CNNIC-NET263-AP Beijing Capital-online science development Co.,Ltd. 203.152.136.0/23 AS23649 NEWSKIES-AS-AP New Skies Satellites, Hong Kong Teleport 203.152.138.0/23 AS23649 NEWSKIES-AS-AP New Skies Satellites, Hong Kong Teleport 203.152.142.0/24 AS23649 NEWSKIES-AS-AP New Skies Satellites, Hong Kong Teleport 203.152.143.0/24 AS23649 NEWSKIES-AS-AP New Skies Satellites, Hong Kong Teleport 203.160.110.0/23 AS7643 VNN-AS-AP Vietnam Posts and Telecommunications (VNPT) 204.9.216.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.9.217.0/24 AS4323 TWTC - Time Warner Telecom, Inc. 204.9.218.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.13.140.0/22 AS7270 NET2PHONE - Net2Phone Corp. 204.16.120.0/23 AS12077 204.16.122.0/23 AS12077 204.19.14.0/23 AS577 BACOM - Bell Canada 204.48.58.0/24 AS4323 TWTC - Time Warner Telecom, Inc. 204.48.60.0/24 AS4323 TWTC - Time Warner Telecom, Inc. 204.154.125.0/24 AS3952 TELLABS-ASN - TELLABS Operations, Inc. 204.154.126.0/24 AS3952 TELLABS-ASN - TELLABS Operations, Inc. 204.154.127.0/24 AS3952 TELLABS-ASN - TELLABS Operations, Inc. 205.150.0.0/15 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 206.162.224.0/19 AS23464 ILCSNET - Interlink Computer Services 206.180.240.0/20 AS12083 KNOLOGY-NET - Knology Holdings 206.220.240.0/24 AS10764 STARTAP - National Center for Supercomputing Applications 206.220.240.64/26 AS22335 MREN - Metropolitan Research and Education Network 206.220.240.128/25 AS10764 STARTAP - National Center for Supercomputing Applications 206.220.240.160/30 AS10764 STARTAP - National Center for Supercomputing Applications 206.220.240.220/32 AS10764 STARTAP - National Center for Supercomputing Applications 206.220.241.0/24 AS10764 STARTAP - National Center for Supercomputing Applications 207.98.192.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 207.98.209.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 207.98.223.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 207.191.128.0/19 AS10887 BPSI-AS - BPSI Internet Services 207.204.168.0/24 AS15150 BELLTECH-AS - BELLWETHER TECHNOLOGY CORPORATION 207.204.222.0/24 AS22773 CCINET-2 - Cox Communications Inc. 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc. 208.38.192.0/18 AS3043 AMPHIB-AS - Amphibian Media Corporation 208.38.192.0/21 AS14237 BEAMSPEED1 - Beamspeed 208.38.202.0/24 AS14237 BEAMSPEED1 - Beamspeed 208.38.203.0/24 AS14237 BEAMSPEED1 - Beamspeed 208.38.204.0/22 AS14237 BEAMSPEED1 - Beamspeed 209.54.93.0/24 AS22773 CCINET-2 - Cox Communications Inc. 209.54.111.0/24 AS22773 CCINET-2 - Cox Communications Inc. 209.54.123.0/24 AS6062 NETPLEX - NETPLEX 209.54.240.0/21 AS10887 BPSI-AS - BPSI Internet Services 209.105.224.0/19 AS20074 209.140.90.0/24 AS14461 NTSL - NET SOLUTIONS 209.140.224.0/21 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.234.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.235.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.236.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.237.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.238.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.140.239.0/24 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.141.16.0/21 AS10573 WEBNEXUS - WebNexus Communications Inc. 209.141.48.0/22 AS14461 NTSL - NET SOLUTIONS 209.145.192.0/18 AS3043 AMPHIB-AS - Amphibian Media Corporation 209.145.204.0/22 AS14237 BEAMSPEED1 - Beamspeed 210.5.128.0/20 AS4837 CHINA169-BACKBONE CNCGROUP China169 Backbone 216.37.114.0/23 AS3549 GBLX Global Crossing Ltd. 216.37.120.0/23 AS13377 216.59.0.0/17 AS3356 LEVEL3 Level 3 Communications 216.99.16.0/24 AS6395 LVLT-6395 - Level 3 Communications, Inc. 216.99.20.0/24 AS6395 LVLT-6395 - Level 3 Communications, Inc. 216.162.96.0/19 AS7393 CYBERCON - CYBERCON, INC. 216.172.198.0/24 AS22773 CCINET-2 - Cox Communications Inc. 216.172.199.0/24 AS22773 CCINET-2 - Cox Communications Inc. 216.210.86.0/24 AS577 BACOM - Bell Canada 216.240.240.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 216.240.241.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 216.240.242.0/24 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 216.251.207.0/24 AS1239 SPRINTLINK - Sprint 217.78.71.0/24 AS12491 IPPLANET-AS IPPlanet 217.78.72.0/24 AS12491 IPPLANET-AS IPPlanet 217.78.73.0/24 AS12491 IPPLANET-AS IPPlanet Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at merit.edu eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From johnl at iecc.com Fri Jun 27 07:05:49 2008 From: johnl at iecc.com (John Levine) Date: 27 Jun 2008 12:05:49 -0000 Subject: ICANN opens up Pandora's Box of new TLDs In-Reply-To: Message-ID: <20080627120549.32616.qmail@simone.iecc.com> >> Some people are going to get very rich over this. > >How do you know this? Judging by the past experience of TLDs >there will not be a rush of customers but there will be a rush >of people trying to make a buck. You might enjoy my blog entries about the .TRAVEL domain: http://weblog.johnlevine.com/ICANN/travelcroak.html http://weblog.johnlevine.com/ICANN/travelnotdead.html http://weblog.johnlevine.com/ICANN/traveldrain.html http://weblog.johnlevine.com/ICANN/travelstillnotdead.html From johnl at iecc.com Fri Jun 27 07:21:01 2008 From: johnl at iecc.com (John Levine) Date: 27 Jun 2008 12:21:01 -0000 Subject: ICANN opens up Pandora's Box of new TLDs In-Reply-To: <5647AFE5-D11E-496C-A8FC-647BD98BB9C0@multicasttech.com> Message-ID: <20080627122101.36306.qmail@simone.iecc.com> >> http://www.gtld-mou.org/gtld-discuss/mail-archive/00990.html > >The SNR in the gtld WG was very low, which I think may have been an >influencing factor. Yeah, it was dominated by a bunch of small-scale amateur greedy speculators, while the solution was ICANN which is dominated by a bunch of large-scale professional greedy speculators. We did come up with the registrar/registry split, though. http://www.iahc.org/contrib/draft-iahc-levine-shared-00.txt R's, John From a.harrowell at gmail.com Fri Jun 27 07:22:03 2008 From: a.harrowell at gmail.com (Alexander Harrowell) Date: Fri, 27 Jun 2008 13:22:03 +0100 Subject: ICANN opens up Pandora's Box of new TLDs In-Reply-To: <20080627120549.32616.qmail@simone.iecc.com> References: <20080627120549.32616.qmail@simone.iecc.com> Message-ID: Well, at least the new TLDs will promote DNS-based cruft filtration. You can already safely ignore anything with a .name, .biz, .info, .tv suffix, to name just the worst. If only there was a way to get the cruft to move over into the new ones... On Fri, Jun 27, 2008 at 1:05 PM, John Levine wrote: > >> Some people are going to get very rich over this. > > > >How do you know this? Judging by the past experience of TLDs > >there will not be a rush of customers but there will be a rush > >of people trying to make a buck. > > You might enjoy my blog entries about the .TRAVEL domain: > > http://weblog.johnlevine.com/ICANN/travelcroak.html > > http://weblog.johnlevine.com/ICANN/travelnotdead.html > > http://weblog.johnlevine.com/ICANN/traveldrain.html > > http://weblog.johnlevine.com/ICANN/travelstillnotdead.html > > > From drew.weaver at thenap.com Fri Jun 27 08:36:30 2008 From: drew.weaver at thenap.com (Drew Weaver) Date: Fri, 27 Jun 2008 09:36:30 -0400 Subject: uceprotect.net Message-ID: Hello everyone, this is possibly off-topic here, not entirely sure. I'm kind of confused about some of uceprotect's policies, they seem to require every IP address to have reverse DNS with matching forwards (which works fine for a wireless/broadband/dial-up ISP, but not so much for a hosting company/datacenter). They seem to penalize companies who have many small allocations from ARIN/whomever while rewarding companies who have huge swaths of IP addresses in single chunks. They don't seem to understand that in a datacenter a single machine running virtuozzo/vmware can have any number of IPs assigned to it and that not everything can be so tightly scripted/controlled. They currently take issue with 106 out of almost 54,000 IP addresses and our AS appears to be listed in their list. That seems extreme to me. My question is, has anyone had a problem with uceprotect.net's system and then been able to satisfy their requirements on an ongoing basis? We'll obviously do whatever it takes because we really have no choice. We've found ISPs with over 100,000 IPs using their list(s) so obviously it has an impact. Off-list is fine, sorry to bother anyone if this is off-topic. Thanks for your time. -Drew From stevel at hostingshop.com.au Fri Jun 27 08:43:51 2008 From: stevel at hostingshop.com.au (Steven Lisson) Date: Fri, 27 Jun 2008 23:43:51 +1000 Subject: uceprotect.net In-Reply-To: Message-ID: Hi, I could be wrong but I think that they are only referring to the forward hostname advertised in the mail servers HELO, it is obvious that most systems have many more forward A records than reverse PTR records. Regards, Steve -----Original Message----- From: Drew Weaver [mailto:drew.weaver at thenap.com] Sent: Friday, 27 June 2008 11:37 PM To: nanog at nanog.org Subject: uceprotect.net Hello everyone, this is possibly off-topic here, not entirely sure. I'm kind of confused about some of uceprotect's policies, they seem to require every IP address to have reverse DNS with matching forwards (which works fine for a wireless/broadband/dial-up ISP, but not so much for a hosting company/datacenter). They seem to penalize companies who have many small allocations from ARIN/whomever while rewarding companies who have huge swaths of IP addresses in single chunks. They don't seem to understand that in a datacenter a single machine running virtuozzo/vmware can have any number of IPs assigned to it and that not everything can be so tightly scripted/controlled. They currently take issue with 106 out of almost 54,000 IP addresses and our AS appears to be listed in their list. That seems extreme to me. My question is, has anyone had a problem with uceprotect.net's system and then been able to satisfy their requirements on an ongoing basis? We'll obviously do whatever it takes because we really have no choice. We've found ISPs with over 100,000 IPs using their list(s) so obviously it has an impact. Off-list is fine, sorry to bother anyone if this is off-topic. Thanks for your time. -Drew From warren at kumari.net Fri Jun 27 09:06:20 2008 From: warren at kumari.net (Warren Kumari) Date: Fri, 27 Jun 2008 10:06:20 -0400 Subject: Possible explanations for a large hop in latency In-Reply-To: <4864602E.6060308@psg.com> References: <48642E62.70206@fluidhosting.com> <48643DC5.1040208@fluidhosting.com> <4aebc7330806261819o6e5eda7aqd16faabfefdc5f1d@mail.gmail.com> <4864602E.6060308@psg.com> Message-ID: <3B366C68-91C4-4737-B733-C449BD8D7849@kumari.net> On Jun 26, 2008, at 11:36 PM, Randy Bush wrote: > Frank Bulk - iNAME wrote: >> Just google "tbr1.sl9mo.ip.att.net" and it's clear that high >> latency through >> that point has occurred before. And guess what kind of customer >> complained >> to me about the latency? A gamer. > > you can pay a lot of money for the net propagation anomaly detection > services that gamers give you for free. ---- Many years ago I worked for a small Mom-and-Pop type ISP in New York state (I was the only network / technical person there) -- it was a very free wheeling place and I built the network by doing whatever made sense at the time. One of my "favorite" customers (Joe somebody) was somehow related to the owner of the ISP and was a gamer. This was back in the day when the gaming magazines would give you useful tips like "Type 'tracert $gameserver' and make sure that there are less than N hops". Joe would call up tech support, me, the owner, etc and complain that there was N+3 hops and most of them were in our network. I spent much time explaining things about packet-loss, latency, etc but couldn't shake his belief that hop count was the only metric that mattered. Finally, one night he called me at home well after midnight (no, I didn't give him my home phone number, he looked me up in the phonebook!) to complain that his gaming was suffering because it was "too many hops to get out of your network". I finally snapped and built a static GRE tunnel from the RAS box that he connected to all over the network -- it was a thing of beauty, it went through almost every device that we owned and took the most convoluted path I could come up with. "Yay!", I figured, "now I can demonstrate that latency is more important than hop count" and I went to bed. The next morning I get a call from him. He is ecstatic and wildly impressed by how well the network is working for him now and how great his gaming performance is. "Oh well", I think, "at least he is happy and will leave me alone now". I don't document the purpose of this GRE anywhere and after some time forget about it. A few months later I am doing some routine cleanup work and stumble across a weird looking tunnel -- its bizarre, it goes all over the place and is all kinds of crufty -- there are static routes and policy routing and bizarre things being done on the RADIUS server to make sure some user always gets a certain IP... I look in my pile of notes and old configs and then decide to just yank it out. That night I get an enraged call (at home again) from Joe *screaming* that the network is all broken again because it is now way too many hops to get out of the network and that people keep shooting him... What I learnt from this: 1: Make sure you document everything (and no, the network isn't documentation) 2: Gamers are weird. 3: Making changes to your network in anger provides short term pleasure but long term pain. ----- W > > > randy > -- Do not meddle in the affairs of dragons, for you are crunchy and taste good with ketchup. From ops.lists at gmail.com Fri Jun 27 09:42:43 2008 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Fri, 27 Jun 2008 20:12:43 +0530 Subject: uceprotect.net In-Reply-To: References: Message-ID: Do you actually have a problem beyond "ZOMG, dnsstuff.com says I am in uceprotect?". Its not a list that I personally would waste time with. BTW, the kind of issue that often affects "cost effective" colo shops - so-called snowshoe spam - typically HAS matching forward and reverse. srs On Fri, Jun 27, 2008 at 7:06 PM, Drew Weaver wrote: > Hello everyone, this is possibly off-topic here, not entirely sure. > > I'm kind of confused about some of uceprotect's policies, they seem to require every IP address to have reverse DNS with matching forwards (which works fine for a wireless/broadband/dial-up ISP, but not so much for a From Valdis.Kletnieks at vt.edu Fri Jun 27 10:22:53 2008 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 27 Jun 2008 11:22:53 -0400 Subject: ICANN opens up Pandora's Box of new TLDs In-Reply-To: Your message of "Thu, 26 Jun 2008 17:16:52 PDT." <46610B65-23E5-466E-B1FF-FEB1C56D7774@mailchannels.com> References: <7ff145960806261309u4eda28b7v8973556b983df63a@mail.gmail.com> <20080626203334.GA18237@cgi.jachomes.com> <48642C9E.70806@wvi.com> <46610B65-23E5-466E-B1FF-FEB1C56D7774@mailchannels.com> Message-ID: <20656.1214580173@turing-police.cc.vt.edu> On Thu, 26 Jun 2008 17:16:52 PDT, Ken Simpson said: > > On that note, it will be very interesting to see who manages to > > register the *.sucks TLD, and what they do with it. > > Oooh -- dibs on that one. And .some, so you can register awe.some, > trouble.some, and fear.some. And .ous, which would allow humm.ous, > seri.ous, fabul.ous, etc.. > > Oh - vomit - this is gonna hurt. A cow-orker of mine said: "How about .dot? I'd like to set up a hostname of dotdot.dashdashdashdot.dot" -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From Valdis.Kletnieks at vt.edu Fri Jun 27 10:31:35 2008 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 27 Jun 2008 11:31:35 -0400 Subject: ICANN opens up Pandora's Box of new TLDs In-Reply-To: Your message of "Fri, 27 Jun 2008 00:01:23 EDT." <48646613.8020409@vaxination.ca> References: <7ff145960806261309u4eda28b7v8973556b983df63a@mail.gmail.com> <48646613.8020409@vaxination.ca> Message-ID: <21137.1214580695@turing-police.cc.vt.edu> On Fri, 27 Jun 2008 00:01:23 EDT, =?ISO-8859-1?Q?Jean-Fran=E7ois_Mezei?= said: > Finally, will there be any performance impact on DNS servers around the > world (thinking of caching issues) ? It should be almost identical to the current performance impact on the second level DNS servers that have to handle 140M .com entries... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From jabley at ca.afilias.info Fri Jun 27 10:44:35 2008 From: jabley at ca.afilias.info (Joe Abley) Date: Fri, 27 Jun 2008 11:44:35 -0400 Subject: ICANN opens up Pandora's Box of new TLDs In-Reply-To: <20656.1214580173@turing-police.cc.vt.edu> References: <7ff145960806261309u4eda28b7v8973556b983df63a@mail.gmail.com> <20080626203334.GA18237@cgi.jachomes.com> <48642C9E.70806@wvi.com> <46610B65-23E5-466E-B1FF-FEB1C56D7774@mailchannels.com> <20656.1214580173@turing-police.cc.vt.edu> Message-ID: <6C77CFAD-95E5-4413-B58C-16101A8552A8@ca.afilias.info> On 27 Jun 2008, at 11:22, Valdis.Kletnieks at vt.edu wrote: > "How about .dot? I'd like to set up a hostname of > dotdot.dashdashdashdot.dot" To my mind, Tony Finch owns you all :-) http://dotat.at/ dot at dotat.at Joe From tme at multicasttech.com Fri Jun 27 11:07:11 2008 From: tme at multicasttech.com (Marshall Eubanks) Date: Fri, 27 Jun 2008 12:07:11 -0400 Subject: ICANN opens up Pandora's Box of new TLDs In-Reply-To: References: <20080627120549.32616.qmail@simone.iecc.com> Message-ID: <66FA0C90-4FAD-4B95-9307-3D1BDA4F5CD5@multicasttech.com> On Jun 27, 2008, at 8:22 AM, Alexander Harrowell wrote: > Well, at least the new TLDs will promote DNS-based cruft filtration. > You can > already safely ignore anything with a .name, .biz, .info, .tv > suffix, to > name just the worst. If only there was a way to get the cruft to > move over > into the new ones... Hey, please don't ignore .tv. No cruft from me, at least. Marshall > > > On Fri, Jun 27, 2008 at 1:05 PM, John Levine wrote: > >>>> Some people are going to get very rich over this. >>> >>> How do you know this? Judging by the past experience of TLDs >>> there will not be a rush of customers but there will be a rush >>> of people trying to make a buck. >> >> You might enjoy my blog entries about the .TRAVEL domain: >> >> http://weblog.johnlevine.com/ICANN/travelcroak.html >> >> http://weblog.johnlevine.com/ICANN/travelnotdead.html >> >> http://weblog.johnlevine.com/ICANN/traveldrain.html >> >> http://weblog.johnlevine.com/ICANN/travelstillnotdead.html >> >> >> From johnl at iecc.com Fri Jun 27 11:12:31 2008 From: johnl at iecc.com (John Levine) Date: Fri, 27 Jun 2008 12:12:31 -0400 (EDT) Subject: ICANN opens up Pandora's Box of new TLDs In-Reply-To: <66FA0C90-4FAD-4B95-9307-3D1BDA4F5CD5@multicasttech.com> References: <20080627120549.32616.qmail@simone.iecc.com> <66FA0C90-4FAD-4B95-9307-3D1BDA4F5CD5@multicasttech.com> Message-ID: > Hey, please don't ignore .tv. No cruft from me, at least. The two letter country codes are a swamp all of their own, with no help from ICANN. I hear that Tuvalu approximately doubled its GNP the year they sold the rights to .tv. R's, John From tme at multicasttech.com Fri Jun 27 11:13:10 2008 From: tme at multicasttech.com (Marshall Eubanks) Date: Fri, 27 Jun 2008 12:13:10 -0400 Subject: ICANN opens up Pandora's Box of new TLDs In-Reply-To: <4864C470.6060400@aset.com> References: <7ff145960806261309u4eda28b7v8973556b983df63a@mail.gmail.com> <20080626203334.GA18237@cgi.jachomes.com> <48642C9E.70806@wvi.com> <4864B0F0.4070203@aset.com> <3C82C988-8F56-4CF4-A8D5-7A333E7E1812@multicasttech.com> <4864C470.6060400@aset.com> Message-ID: <5E590F95-C7B4-4A90-894E-55CDA5296241@multicasttech.com> On Jun 27, 2008, at 6:44 AM, Jon Kibler wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Marshall Eubanks wrote: >> >> On Jun 27, 2008, at 5:20 AM, Jon Kibler wrote: >> >> Jeff Shultz wrote: >>>>> Owen DeLong wrote: >>>>> >>>>> On that note, it will be very interesting to see who manages to >>>>> register >>>>> the *.sucks TLD, and what they do with it. >>>>> >> >> >> Well, I guess this shoots in the foot Microsoft's name server best >> practices of setting up your AD domain as foo.LOCAL, using the logic >> that .LOCAL is safe because it cannot be resolved by the root name >> servers. >> >> Who wants to be the first to try to register *.local? >> >>> They should have been following RFC 2606. >> >>> Regards >>> Marshall > > > Thinking about it a little more, what about the common use of > 'localhost.localdomain' for 127.0.0.1 in most versions of *nix? I can > just imagine the chaos that registering a *.localdomain TLD will > cause. > .localhost is already reserved through RFC 2606, so this should not be a problem. To quote : The ".localhost" TLD has traditionally been statically defined in host DNS implementations as having an A record pointing to the loop back IP address and is reserved for such use. Any other use would conflict with widely deployed code which assumes this use. > Methinks it is time to update RFC2606 to reflect common practices > before > the new ICANN policies take effect. > If you can think of a list, it probably would... Marshall > Jon > - -- > Jon R. Kibler > Chief Technical Officer > Advanced Systems Engineering Technology, Inc. > Charleston, SC USA > o: 843-849-8214 > c: 843-224-2494 > s: 843-564-4224 > > My PGP Fingerprint is: > BAA2 1F2C 5543 5D25 4636 A392 515C 5045 CF39 4253 > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.8 (Darwin) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iEYEARECAAYFAkhkxHAACgkQUVxQRc85QlPfmgCgiIUv7KYOz/U2vdk2DyA04D/O > 8Q4An2wK8vilUCJne06qIn/67erB2rkt > =ih+F > -----END PGP SIGNATURE----- > > From tme at multicasttech.com Fri Jun 27 11:14:28 2008 From: tme at multicasttech.com (Marshall Eubanks) Date: Fri, 27 Jun 2008 12:14:28 -0400 Subject: ICANN opens up Pandora's Box of new TLDs In-Reply-To: References: <20080627120549.32616.qmail@simone.iecc.com> <66FA0C90-4FAD-4B95-9307-3D1BDA4F5CD5@multicasttech.com> Message-ID: <8F7C5CB3-6EC2-4595-BF4A-AD25198AEFAC@multicasttech.com> .tv is heavily used by the burgeoning Internet TV industry (including by yours truly). It may contain cruft, but it is certainly not all cruft. Regards Marshall On Jun 27, 2008, at 12:12 PM, John Levine wrote: >> Hey, please don't ignore .tv. No cruft from me, at least. > > The two letter country codes are a swamp all of their own, with no > help from ICANN. > > I hear that Tuvalu approximately doubled its GNP the year they sold > the rights to .tv. > > R's, > John From lou at metron.com Fri Jun 27 11:21:30 2008 From: lou at metron.com (Lou Katz) Date: Fri, 27 Jun 2008 09:21:30 -0700 Subject: ICANN opens up Pandora's Box of new TLDs In-Reply-To: <5E590F95-C7B4-4A90-894E-55CDA5296241@multicasttech.com> References: <7ff145960806261309u4eda28b7v8973556b983df63a@mail.gmail.com> <20080626203334.GA18237@cgi.jachomes.com> <48642C9E.70806@wvi.com> <4864B0F0.4070203@aset.com> <3C82C988-8F56-4CF4-A8D5-7A333E7E1812@multicasttech.com> <4864C470.6060400@aset.com> <5E590F95-C7B4-4A90-894E-55CDA5296241@multicasttech.com> Message-ID: <20080627162130.GA92539@metron.com> On Fri, Jun 27, 2008 at 12:13:10PM -0400, Marshall Eubanks wrote: > > >>Well, I guess this shoots in the foot Microsoft's name server best > >>practices of setting up your AD domain as foo.LOCAL, using the logic > >>that .LOCAL is safe because it cannot be resolved by the root name > >>servers. > >> > >>Who wants to be the first to try to register *.local? > >> > >>>They should have been following RFC 2606. > >> > >>>Regards > >>>Marshall > > > > > >Thinking about it a little more, what about the common use of > >'localhost.localdomain' for 127.0.0.1 in most versions of *nix? I can > >just imagine the chaos that registering a *.localdomain TLD will > >cause. > > > > .localhost is already reserved through RFC 2606, so this should not be > a problem. To quote : > The ".localhost" TLD has traditionally been statically defined in host > DNS implementations as having an A record pointing to the loop back IP > address and is reserved for such use. Any other use would conflict > with widely deployed code which assumes this use. > > >Methinks it is time to update RFC2606 to reflect common practices > >before > >the new ICANN policies take effect. > > > > If you can think of a list, it probably would... Having had the need to construct a few TLDs for internal use, I hope that some new RFC will address this and reserve some (e.g. .internal, .internal# (where # is any fully numeric string), .local)? I really don't care what they are called, but I do need more than one. > > Marshall > > >Jon -- -=[L]=- Helping to interpret the lives of the animals. From lists at memetic.org Fri Jun 27 11:42:53 2008 From: lists at memetic.org (Adam Armstrong) Date: Fri, 27 Jun 2008 17:42:53 +0100 Subject: OS, Hardware, Network - Logging, Monitoring, and Alerting In-Reply-To: <20080626092204.GR24243@datavibe.net> References: <20080626092204.GR24243@datavibe.net> Message-ID: <4865188D.2050507@memetic.org> Rev. Jeffrey Paul wrote: > Hi. I've a (theoretically) simple problem and I'm wondering how others > solve it. > > I've recently deployed ~40 Linux instances on ~20 different Dell blades > and PowerEdges (we're big on virtualization), a few 7204s and 3560s, and > assorted switchable PDUs and whatnot. > > We need to monitor standard things like cpu, memory, disk usage on all > OSes. This is straightforward with net-snmp. It would also be cool if > I could monitor more esoteric things, like ntp synchronization status, > i/o statistics, etc. > > Other stuff we really need to keep an eye on is hardware - redundant > PSU status in our 7204s and Dells, temperatures and voltages (one of > our colos in New York peaked at over 40C a few weeks ago, for > instance), and disk array status (I'd like to know of a failed disk > in a hardware RAID5 before I get calls about performance issues). Our > blade chassis have DRACs in them and I think they export this data via > SNMP (I'm trying to avoid the use of SNMP traps), but not all of our > other PowerEdges have the DRACs in them so some of this information may > need to be pulled via IPMI from within the host OS. Presumably the > Cisco gear makes the temperature available via SNMP. > > Finally, service checks - standard stuff (dns, http, https, ssh, smtp). > > Now, to the questions. > > 1) Is SNMP the best way to do this? Obviously some of the data (service > checks) will need to be collected other ways. > > 2) Is there any good solution that does both logging/trending of this > data and also notification/monitoring/alerting? I've used both Nagios > and Cacti in the past, and, due to the number of individual things being > monitored (3-5 items per OS instance, 5-10 items per physical server, > 10-50 things per network device), setting them both up independently > seems like a huge pain. Also, I've never really liked Nagios that much. > > I recently entertained the idea of writing a CGI that output all of this > information in a standard format (csv?), distributing and installing it, then > collecting it periodically at a central location and doing all the > rrd/notification myself, but then realized that this problem must've > been solved a million times already. > > There's got to be a better way. What do you guys use? > I wrote an NMS to do something along these lines. It's focussed more towards graphing than alerting. It knows where to find Dell/Cisco temperature monitors via SNMP and will keep track of hardware and OS types/versions. It's probably still not really ready for general consumption, but if you think it would be useful to you, give me a shout and I'll see if I can help you make it work properly for you. http://www.project-observer.org I wrote it mostly due to my own absolute hatred of Nagios and disappointment at the other NMSes around (where are the asthetics?)! :) Thanks, adam. From simonw at zynet.net Fri Jun 27 11:46:04 2008 From: simonw at zynet.net (Simon Waters) Date: Fri, 27 Jun 2008 17:46:04 +0100 Subject: ICANN opens up Pandora's Box of new TLDs In-Reply-To: <5E590F95-C7B4-4A90-894E-55CDA5296241@multicasttech.com> References: <7ff145960806261309u4eda28b7v8973556b983df63a@mail.gmail.com> <4864C470.6060400@aset.com> <5E590F95-C7B4-4A90-894E-55CDA5296241@multicasttech.com> Message-ID: <200806271746.05242.simonw@zynet.net> On Friday 27 June 2008 17:13:10 Marshall Eubanks wrote: > > .localhost is already reserved through RFC 2606, so this should not be > a problem. .localdomain shouldn't cause a problem, since most Unix systems that use it put it in the name resolution before the DNS is invoked (i.e. /etc/hosts). ICANN have a technical review step in the procedure, which hopefully would flag a request for ".localdomain", I don't think we want to try to enumerate possible brokenness. Probably appropriate for the review step is to ask the root name server operators if there is substantive traffic for a proposed TLD, as if there is it may reveal a problem. That said substantive traffic for a proposed domain need not of itself block a request, ICANN are tasked with maintaining the stability of the net, not the stability of every broken piece of software on the net. Does anyone has a specific operational concerns - otherwise I think this topic should probably be laid to rest on this list. From tme at multicasttech.com Fri Jun 27 11:48:50 2008 From: tme at multicasttech.com (Marshall Eubanks) Date: Fri, 27 Jun 2008 12:48:50 -0400 Subject: ICANN opens up Pandora's Box of new TLDs In-Reply-To: <20080627162130.GA92539@metron.com> References: <7ff145960806261309u4eda28b7v8973556b983df63a@mail.gmail.com> <20080626203334.GA18237@cgi.jachomes.com> <48642C9E.70806@wvi.com> <4864B0F0.4070203@aset.com> <3C82C988-8F56-4CF4-A8D5-7A333E7E1812@multicasttech.com> <4864C470.6060400@aset.com> <5E590F95-C7B4-4A90-894E-55CDA5296241@multicasttech.com> <20080627162130.GA92539@metron.com> Message-ID: <15E6D712-06D0-4DB5-8EDC-8737229A378E@multicasttech.com> Dear Lou; On Jun 27, 2008, at 12:21 PM, Lou Katz wrote: > On Fri, Jun 27, 2008 at 12:13:10PM -0400, Marshall Eubanks wrote: >> >>>> Well, I guess this shoots in the foot Microsoft's name server best >>>> practices of setting up your AD domain as foo.LOCAL, using the >>>> logic >>>> that .LOCAL is safe because it cannot be resolved by the root name >>>> servers. >>>> >>>> Who wants to be the first to try to register *.local? >>>> >>>>> They should have been following RFC 2606. >>>> >>>>> Regards >>>>> Marshall >>> >>> >>> Thinking about it a little more, what about the common use of >>> 'localhost.localdomain' for 127.0.0.1 in most versions of *nix? I >>> can >>> just imagine the chaos that registering a *.localdomain TLD will >>> cause. >>> >> >> .localhost is already reserved through RFC 2606, so this should not >> be >> a problem. To quote : >> The ".localhost" TLD has traditionally been statically defined in >> host >> DNS implementations as having an A record pointing to the loop back >> IP >> address and is reserved for such use. Any other use would conflict >> with widely deployed code which assumes this use. >> >>> Methinks it is time to update RFC2606 to reflect common practices >>> before >>> the new ICANN policies take effect. >>> >> >> If you can think of a list, it probably would... > > Having had the need to construct a few TLDs for internal use, I hope > that some > new RFC will address this and reserve some > (e.g. .internal, .internal# (where # is > any fully numeric string), .local)? I really don't care what they > are called, > but I do need more than one. There are 4 already, .test .example .invalid .localhost . I suspect that .local should also be reserved, which would make 5. It seems that .internal# should just be blocked, not reserved. Before, the feeling was that the best blockage was a reservation, but as I read the ICANN presentation, if .internal was reserved, .internal# could be blocked too without an explicit reservation. Regards Marshall > > > >> >> Marshall >> >>> Jon > > > > -- > > -=[L]=- > Helping to interpret the lives of the animals. > From fobdfc at gmail.com Fri Jun 27 12:15:57 2008 From: fobdfc at gmail.com (Mike) Date: Fri, 27 Jun 2008 12:15:57 -0500 Subject: OS, Hardware, Network - Logging, Monitoring, and Alerting In-Reply-To: <4865188D.2050507@memetic.org> References: <20080626092204.GR24243@datavibe.net> <4865188D.2050507@memetic.org> Message-ID: you can do most of this with Cacti out of the box. you can also add the thold and monitoring plugins to get the additional things you need. Cacti mainly uses SNMP but you can also use external scripts to gather information. It does have future trending capabilities (that i am aware of) but can evaluate against baseline thresholds using the thold plugin. The Cacti community has created templates and add-ons for the most common network vendors and system types. On Fri, Jun 27, 2008 at 11:42 AM, Adam Armstrong wrote: > Rev. Jeffrey Paul wrote: >> >> Hi. I've a (theoretically) simple problem and I'm wondering how others >> solve it. >> >> I've recently deployed ~40 Linux instances on ~20 different Dell blades >> and PowerEdges (we're big on virtualization), a few 7204s and 3560s, and >> assorted switchable PDUs and whatnot. >> We need to monitor standard things like cpu, memory, disk usage on all >> OSes. This is straightforward with net-snmp. It would also be cool if >> I could monitor more esoteric things, like ntp synchronization status, >> i/o statistics, etc. >> >> Other stuff we really need to keep an eye on is hardware - redundant PSU >> status in our 7204s and Dells, temperatures and voltages (one of >> our colos in New York peaked at over 40C a few weeks ago, for instance), >> and disk array status (I'd like to know of a failed disk in a hardware RAID5 >> before I get calls about performance issues). Our >> blade chassis have DRACs in them and I think they export this data via >> SNMP (I'm trying to avoid the use of SNMP traps), but not all of our >> other PowerEdges have the DRACs in them so some of this information may >> need to be pulled via IPMI from within the host OS. Presumably the >> Cisco gear makes the temperature available via SNMP. >> >> Finally, service checks - standard stuff (dns, http, https, ssh, smtp). >> >> Now, to the questions. >> >> 1) Is SNMP the best way to do this? Obviously some of the data (service >> checks) will need to be collected other ways. >> >> 2) Is there any good solution that does both logging/trending of this >> data and also notification/monitoring/alerting? I've used both Nagios >> and Cacti in the past, and, due to the number of individual things being >> monitored (3-5 items per OS instance, 5-10 items per physical server, >> 10-50 things per network device), setting them both up independently >> seems like a huge pain. Also, I've never really liked Nagios that much. >> >> I recently entertained the idea of writing a CGI that output all of this >> information in a standard format (csv?), distributing and installing it, >> then >> collecting it periodically at a central location and doing all the >> rrd/notification myself, but then realized that this problem must've >> been solved a million times already. >> >> There's got to be a better way. What do you guys use? >> > > I wrote an NMS to do something along these lines. It's focussed more towards > graphing than alerting. It knows where to find Dell/Cisco temperature > monitors via SNMP and will keep track of hardware and OS types/versions. > It's probably still not really ready for general consumption, but if you > think it would be useful to you, give me a shout and I'll see if I can help > you make it work properly for you. > > http://www.project-observer.org > > I wrote it mostly due to my own absolute hatred of Nagios and disappointment > at the other NMSes around (where are the asthetics?)! :) > > Thanks, > adam. > > From joly at punkcast.com Fri Jun 27 12:21:54 2008 From: joly at punkcast.com (WWWhatsup) Date: Fri, 27 Jun 2008 13:21:54 -0400 Subject: ICANN opens up Pandora's Box of new TLDs In-Reply-To: References: <7ff145960806261309u4eda28b7v8973556b983df63a@mail.gmail.com> <48646613.8020409@vaxination.ca> <3AF701D8-9EE9-424A-BF71-DB9019119E51@virtualized.org> Message-ID: <20080627172157.660FD213C0@spunkymail-a9.g.dreamhost.com> > I reformatted the pertinent parts to make them more easily readable http://isoc-ny.org/wiki/ICANN_-_Paris/gTLD_discussion joly >I think that this is a good read as well, especially the comments by Dave Wodeley, Susan Crawford, and Wendy Seltzer. > >https://par.icann.org/files/paris/BoardMeeting_26June08.txt > > >Best, > >Martin --------------------------------------------------------------- WWWhatsup NYC http://pinstand.com - http://punkcast.com --------------------------------------------------------------- From darkuncle at gmail.com Fri Jun 27 12:24:48 2008 From: darkuncle at gmail.com (Scott Francis) Date: Fri, 27 Jun 2008 10:24:48 -0700 Subject: what problem are we solving? (was Re: ICANN opens up Pandora's Box of new TLDs) Message-ID: <171423de0806271024h73e9a181t1df338aa5fe84ef5@mail.gmail.com> On Thu, Jun 26, 2008 at 9:01 PM, Jean-Fran?ois Mezei wrote: [snip conflict examples] > Finally, will there be any performance impact on DNS servers around the > world (thinking of caching issues) ? more to the point ... what problem is ICANN trying to solve with this proposal? What about the current system that's broken, does this new system fix? It looks like a lot of thought went into the process (thanks for the PDF link, DRC), and most of the issues raised here are addressed (conflicts, abuse/phishing grabs, etc.) - I'm just still unclear what the motivation for this new system was in the first place. I'm not opposed to it if it solves a legitimate technical/operational issue that's germaine to either the operators of the Internet or the users of the Internet, but so far I can't see that this serves either of those communities. In fact, it could very well be argued that a slew of new TLDs (whether a few dozen or a few hundred) will only serve to increase complexity and add additional confusion to a system that the standard user has just now come to grips with ("www.company.com will get me Company's official, legitimate page"). perhaps somebody with more insight can explain the rationale to me (DRC?) - is there a purpose served here aside from corporate/legal interests? thanks, -- darkuncle@{gmail.com,darkuncle.net} || 0x5537F527 http://darkuncle.net/pubkey.asc for public key From lists at memetic.org Fri Jun 27 12:50:50 2008 From: lists at memetic.org (Adam Armstrong) Date: Fri, 27 Jun 2008 18:50:50 +0100 Subject: OS, Hardware, Network - Logging, Monitoring, and Alerting In-Reply-To: References: <20080626092204.GR24243@datavibe.net> <4865188D.2050507@memetic.org> Message-ID: <4865287A.2090405@memetic.org> Mike wrote: > you can do most of this with Cacti out of the box. you can also add > the thold and monitoring plugins to get the additional things you > need. Cacti mainly uses SNMP but you can also use external scripts to > gather information. It does have future trending capabilities (that i > am aware of) but can evaluate against baseline thresholds using the > thold plugin. > > The Cacti community has created templates and add-ons for the most > common network vendors and system types. > Cacti does graphs, but it's really just not useful enough to me. Neither was Nagios (on top of being a nightmare to configure). I found similar issues with other similarish solutions such as OpenNMS and JFFNMS. I generally used Cricket with the config-generation tool for graphing devices and ports, Cacti was prettier, but IMO slightly more complex than necessary. Observer is intended to be autodiscovering, with as little manually configured as possible. This has made a few things quite hard to do properly, like alerting. It was written firstly to discover the network, secondly to graph and log it, and thirdly to alert you when it breaks. Unfortunately it turns out that i can't get my head around the alerting bit, so it remains a little unfinished! My personal opinion is that all of the FOSS NMS solutions are sorely disappointing, Observer included. It seems to be something that no one has quite gotten right yet! Adam. > On Fri, Jun 27, 2008 at 11:42 AM, Adam Armstrong wrote: > >> Rev. Jeffrey Paul wrote: >> >>> Hi. I've a (theoretically) simple problem and I'm wondering how others >>> solve it. >>> >>> I've recently deployed ~40 Linux instances on ~20 different Dell blades >>> and PowerEdges (we're big on virtualization), a few 7204s and 3560s, and >>> assorted switchable PDUs and whatnot. >>> We need to monitor standard things like cpu, memory, disk usage on all >>> OSes. This is straightforward with net-snmp. It would also be cool if >>> I could monitor more esoteric things, like ntp synchronization status, >>> i/o statistics, etc. >>> >>> Other stuff we really need to keep an eye on is hardware - redundant PSU >>> status in our 7204s and Dells, temperatures and voltages (one of >>> our colos in New York peaked at over 40C a few weeks ago, for instance), >>> and disk array status (I'd like to know of a failed disk in a hardware RAID5 >>> before I get calls about performance issues). Our >>> blade chassis have DRACs in them and I think they export this data via >>> SNMP (I'm trying to avoid the use of SNMP traps), but not all of our >>> other PowerEdges have the DRACs in them so some of this information may >>> need to be pulled via IPMI from within the host OS. Presumably the >>> Cisco gear makes the temperature available via SNMP. >>> >>> Finally, service checks - standard stuff (dns, http, https, ssh, smtp). >>> >>> Now, to the questions. >>> >>> 1) Is SNMP the best way to do this? Obviously some of the data (service >>> checks) will need to be collected other ways. >>> >>> 2) Is there any good solution that does both logging/trending of this >>> data and also notification/monitoring/alerting? I've used both Nagios >>> and Cacti in the past, and, due to the number of individual things being >>> monitored (3-5 items per OS instance, 5-10 items per physical server, >>> 10-50 things per network device), setting them both up independently >>> seems like a huge pain. Also, I've never really liked Nagios that much. >>> >>> I recently entertained the idea of writing a CGI that output all of this >>> information in a standard format (csv?), distributing and installing it, >>> then >>> collecting it periodically at a central location and doing all the >>> rrd/notification myself, but then realized that this problem must've >>> been solved a million times already. >>> >>> There's got to be a better way. What do you guys use? >>> >>> >> I wrote an NMS to do something along these lines. It's focussed more towards >> graphing than alerting. It knows where to find Dell/Cisco temperature >> monitors via SNMP and will keep track of hardware and OS types/versions. >> It's probably still not really ready for general consumption, but if you >> think it would be useful to you, give me a shout and I'll see if I can help >> you make it work properly for you. >> >> http://www.project-observer.org >> >> I wrote it mostly due to my own absolute hatred of Nagios and disappointment >> at the other NMSes around (where are the asthetics?)! :) >> >> Thanks, >> adam. >> >> >> From drc at virtualized.org Fri Jun 27 12:53:19 2008 From: drc at virtualized.org (David Conrad) Date: Fri, 27 Jun 2008 10:53:19 -0700 Subject: what problem are we solving? (was Re: ICANN opens up Pandora's Box of new TLDs) In-Reply-To: <171423de0806271024h73e9a181t1df338aa5fe84ef5@mail.gmail.com> References: <171423de0806271024h73e9a181t1df338aa5fe84ef5@mail.gmail.com> Message-ID: On Jun 27, 2008, at 10:24 AM, Scott Francis wrote: > more to the point ... what problem is ICANN trying to solve with this > proposal? > ... > perhaps somebody with more insight can explain the rationale to me > (DRC?) - is there a purpose served here aside from corporate/legal > interests? I suspect one's view as to whether a purpose is served is largely subjective. Some folks believe that by liberalizing the rules, innovators will come up with new and interesting uses of the DNS namespace. A commonly cited example of this innovation would be the establishment of a ".BANK" top-level domain that has some assurance that registrants in that domain were actually 'certified' banks and thus would have a higher level of trust regarding banking transactions than registrants in (say) ".SCAMMERS". Other folks believe that anything that reduces the effective monopoly VeriSign has (through .COM and .NET) would be a good thing. This view holds that by increasing the number of top-level domains, you increase the opportunities for consumer (that is, domain registrant) choice, thereby reducing the value of any single top-level domain. And then there are the folks that claim "all the good names are gone", either registered appropriately or squatted on by IPR holders or scammers, thus new top-level domains are necessary in order to allow more "good names". Of course, there are a myriad other views, both positive and negative. However, more generally, ICANN was established in order to allow private (read: non-government) management of the Internet namespace under the assumption that public (read: governmental or inter-governmental, i.e. treaty organizations like the ITU) management would be too slow, too beholden to geo-political interests, and/or stifle innovation. A key component of this management was explicitly stated as being the promotion of competition. While one might argue that creating new top-level domains doesn't really promote competition given the cost of changing from one domain name to another, realistically, I figure there aren't many other ways in which additional opportunities for competition can be created. FWIW. Regards, -drc (speaking only for myself) From brandon.galbraith at gmail.com Fri Jun 27 12:56:22 2008 From: brandon.galbraith at gmail.com (Brandon Galbraith) Date: Fri, 27 Jun 2008 12:56:22 -0500 Subject: OS, Hardware, Network - Logging, Monitoring, and Alerting In-Reply-To: <4865287A.2090405@memetic.org> References: <20080626092204.GR24243@datavibe.net> <4865188D.2050507@memetic.org> <4865287A.2090405@memetic.org> Message-ID: <366100670806271056l6562a703i115395d3c5a9e333@mail.gmail.com> On 6/27/08, Adam Armstrong wrote: > > My personal opinion is that all of the FOSS NMS solutions are sorely > disappointing, Observer included. It seems to be something that no one has > quite gotten right yet! > > Adam. > Very true. One product (not OSS, somewhat pricey) we've had great luck with is SolarWinds Netmonitor. I can install it and point it at all of our equipment in under a couple of hours. When you want to monitor a server, you just need an SNMP service running on it, point Netmonitor at the IP of the box, and it'll ask you what you'd like to monitor (disk, CPU, memory, etc). Works great with our Cisco and HP networking gear as well. -brandon From billn at billn.net Fri Jun 27 12:57:37 2008 From: billn at billn.net (Bill Nash) Date: Fri, 27 Jun 2008 10:57:37 -0700 (MST) Subject: what problem are we solving? (was Re: ICANN opens up Pandora's Box of new TLDs) In-Reply-To: <171423de0806271024h73e9a181t1df338aa5fe84ef5@mail.gmail.com> References: <171423de0806271024h73e9a181t1df338aa5fe84ef5@mail.gmail.com> Message-ID: On Fri, 27 Jun 2008, Scott Francis wrote: > perhaps somebody with more insight can explain the rationale to me > (DRC?) - is there a purpose served here aside from corporate/legal > interests? It strikes me as fomenting another gold rush. The notion that disputed TLDs go up for auction sounds like a request for a nice, high quality money printing device. I may have skimmed over it, but where does the money from these auctions go? At the risk of invoking Ron Paul, this will turn TLDs into a fiat currency, and devalue the rest of them. A small subset of people will profit, and everyone else loses. Off the top of my head, I can see some high dollar fist fights breaking out for .sex, .porn, .games, .hotel, etc. It'll be like the .alt tree on usenet for people with money. There may also be an actual fist fight over TLDs like .irc, .leet, .goatse, and .krad. Maybe not .krad. I agree with Scott, I'd rather see ICANN spend time on current problems instead of making new ones. - billn From Valdis.Kletnieks at vt.edu Fri Jun 27 13:06:20 2008 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 27 Jun 2008 14:06:20 -0400 Subject: what problem are we solving? (was Re: ICANN opens up Pandora's Box of new TLDs) In-Reply-To: Your message of "Fri, 27 Jun 2008 10:24:48 PDT." <171423de0806271024h73e9a181t1df338aa5fe84ef5@mail.gmail.com> References: <171423de0806271024h73e9a181t1df338aa5fe84ef5@mail.gmail.com> Message-ID: <8386.1214589980@turing-police.cc.vt.edu> On Fri, 27 Jun 2008 10:24:48 PDT, Scott Francis said: > serve to increase complexity and add additional confusion to a system > that the standard user has just now come to grips with > ("www.company.com will get me Company's official, legitimate page"). Funny you should say that. :) On my way back from lunch, I heard an ad on the radio for a company in town that said: "or visit blueridgerealestate.org". Yep. dot-org, because the dot-com variant is owned by another company some 50 miles from here. And doing a 'whois' on both shows that "company" didn't get "company.com" because somebody else snagged it first. So it's a crap shoot regarding whether the .com gets you the "official legitimate page"... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From cscora at apnic.net Fri Jun 27 13:08:39 2008 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 28 Jun 2008 04:08:39 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <200806271808.m5RI8dXQ025385@thyme.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 28 Jun, 2008 Report Website: http://thyme.apnic.net Detailed Analysis: http://thyme.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 261031 Prefixes after maximum aggregation: 128186 Deaggregation factor: 2.04 Unique aggregates announced to Internet: 127105 Total ASes present in the Internet Routing Table: 28561 Prefixes per ASN: 9.14 Origin-only ASes present in the Internet Routing Table: 24896 Origin ASes announcing only one prefix: 12051 Transit ASes present in the Internet Routing Table: 3665 Transit-only ASes present in the Internet Routing Table: 80 Average AS path length visible in the Internet Routing Table: 3.6 Max AS path length visible: 18 Max AS path prepend of ASN (43380) 13 Prefixes from unregistered ASNs in the Routing Table: 612 Unregistered ASNs in the Routing Table: 221 Number of 32-bit ASNs allocated by the RIRs: 48 Prefixes from 32-bit ASNs in the Routing Table: 8 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 778 Number of addresses announced to Internet: 1864217696 Equivalent to 111 /8s, 29 /16s and 180 /24s Percentage of available address space announced: 50.3 Percentage of allocated address space announced: 61.1 Percentage of available address space allocated: 82.3 Percentage of address space in use by end-sites: 72.4 Total number of prefixes smaller than registry allocations: 127006 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 59718 Total APNIC prefixes after maximum aggregation: 22124 APNIC Deaggregation factor: 2.70 Prefixes being announced from the APNIC address blocks: 56731 Unique aggregates announced from the APNIC address blocks: 25012 APNIC Region origin ASes present in the Internet Routing Table: 3284 APNIC Prefixes per ASN: 17.27 APNIC Region origin ASes announcing only one prefix: 878 APNIC Region transit ASes present in the Internet Routing Table: 512 Average APNIC Region AS path length visible: 3.5 Max APNIC Region AS path length visible: 15 Number of APNIC addresses announced to Internet: 359769888 Equivalent to 21 /8s, 113 /16s and 167 /24s Percentage of available APNIC address space announced: 76.6 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079 APNIC Address Blocks 58/8, 59/8, 60/8, 61/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 119970 Total ARIN prefixes after maximum aggregation: 64949 ARIN Deaggregation factor: 1.85 Prefixes being announced from the ARIN address blocks: 89671 Unique aggregates announced from the ARIN address blocks: 34705 ARIN Region origin ASes present in the Internet Routing Table: 12240 ARIN Prefixes per ASN: 7.33 ARIN Region origin ASes announcing only one prefix: 4741 ARIN Region transit ASes present in the Internet Routing Table: 1144 Average ARIN Region AS path length visible: 3.3 Max ARIN Region AS path length visible: 15 Number of ARIN addresses announced to Internet: 353360032 Equivalent to 21 /8s, 15 /16s and 216 /24s Percentage of available ARIN address space announced: 72.6 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 ARIN Address Blocks 24/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 173/8, 174/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 56335 Total RIPE prefixes after maximum aggregation: 34205 RIPE Deaggregation factor: 1.65 Prefixes being announced from the RIPE address blocks: 51535 Unique aggregates announced from the RIPE address blocks: 34513 RIPE Region origin ASes present in the Internet Routing Table: 11539 RIPE Prefixes per ASN: 4.47 RIPE Region origin ASes announcing only one prefix: 6041 RIPE Region transit ASes present in the Internet Routing Table: 1742 Average RIPE Region AS path length visible: 4.0 Max RIPE Region AS path length visible: 18 Number of RIPE addresses announced to Internet: 361948800 Equivalent to 21 /8s, 146 /16s and 230 /24s Percentage of available RIPE address space announced: 83.0 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-48127 RIPE Address Blocks 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 20337 Total LACNIC prefixes after maximum aggregation: 5198 LACNIC Deaggregation factor: 3.91 Prefixes being announced from the LACNIC address blocks: 18584 Unique aggregates announced from the LACNIC address blocks: 10491 LACNIC Region origin ASes present in the Internet Routing Table: 960 LACNIC Prefixes per ASN: 19.36 LACNIC Region origin ASes announcing only one prefix: 315 LACNIC Region transit ASes present in the Internet Routing Table: 160 Average LACNIC Region AS path length visible: 4.1 Max LACNIC Region AS path length visible: 15 Number of LACNIC addresses announced to Internet: 52687360 Equivalent to 3 /8s, 35 /16s and 242 /24s Percentage of available LACNIC address space announced: 52.3 LACNIC AS Blocks 26592-26623, 27648-28671, plus ERX transfers LACNIC Address Blocks 186/8, 187/8, 189/8, 190/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 4062 Total AfriNIC prefixes after maximum aggregation: 1204 AfriNIC Deaggregation factor: 3.37 Prefixes being announced from the AfriNIC address blocks: 4339 Unique aggregates announced from the AfriNIC address blocks: 1880 AfriNIC Region origin ASes present in the Internet Routing Table: 240 AfriNIC Prefixes per ASN: 18.08 AfriNIC Region origin ASes announcing only one prefix: 76 AfriNIC Region transit ASes present in the Internet Routing Table: 47 Average AfriNIC Region AS path length visible: 3.9 Max AfriNIC Region AS path length visible: 15 Number of AfriNIC addresses announced to Internet: 12233216 Equivalent to 0 /8s, 186 /16s and 170 /24s Percentage of available AfriNIC address space announced: 36.5 AfriNIC AS Blocks 36864-37887 & ERX transfers AfriNIC Address Blocks 41/8, 196/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4755 1668 387 90 Videsh Sanchar Nigam Ltd. Aut 17488 1188 82 91 Hathway IP Over Cable Interne 9583 1163 111 420 Sify Limited 9498 1078 550 62 BHARTI BT INTERNET LTD. 4766 846 6006 343 Korea Telecom (KIX) 4134 829 12995 328 CHINANET-BACKBONE 23577 824 35 704 Korea Telecom (ATM-MPLS) 4780 704 351 63 Digital United Inc. 18101 688 167 35 Reliance Infocom Ltd Internet 9829 598 450 12 BSNL National Internet Backbo Complete listing at http://thyme.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 209 3013 3874 622 Qwest 6389 2671 3260 199 bellsouth.net, inc. 2386 1496 663 877 AT&T Data Communications Serv 4323 1469 1044 376 Time Warner Telecom 7018 1395 5822 976 AT&T WorldNet Services 11492 1231 150 12 Cable One 1785 1080 510 104 AppliedTheory Corporation 20115 1048 1068 561 Charter Communications 18566 1045 296 10 Covad Communications 7011 1015 287 554 Citizens Utilities Complete listing at http://thyme.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 3292 414 1788 372 TDC Tele Danmark 8452 344 188 11 TEDATA 3301 335 1460 305 TeliaNet Sweden 3320 319 7046 268 Deutsche Telekom AG 8866 319 77 21 Bulgarian Telecommunication C 5462 296 666 27 Telewest Broadband 8551 287 269 38 Bezeq International 3215 286 2742 89 France Telecom Transpac 680 274 2047 264 DFN-IP service G-WiN 6746 268 126 243 Dynamic Network Technologies, Complete listing at http://thyme.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8151 1273 2464 227 UniNet S.A. de C.V. 11830 604 299 9 Instituto Costarricense de El 22047 565 270 14 VTR PUNTO NET S.A. 7303 469 231 65 Telecom Argentina Stet-France 16814 426 27 10 NSS, S.A. 6471 411 85 48 ENTEL CHILE S.A. 11172 408 118 70 Servicios Alestra S.A de C.V 10620 397 101 68 TVCABLE BOGOTA 14117 375 23 9 Telefonica del Sur S.A. 20299 334 23 98 NEWCOM AMERICAS Complete listing at http://thyme.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 24863 475 61 30 LINKdotNET AS number 20858 397 34 3 EgyNet 3741 273 853 224 The Internet Solution 2018 201 205 85 Tertiary Education Network 5713 156 558 94 Telkom SA Ltd 6713 143 135 11 Itissalat Al-MAGHRIB 33783 133 9 17 EEPAD TISP TELECOM & INTERNET 5536 121 8 16 Internet Egypt Network 29571 102 13 8 Ci Telecom Autonomous system 33776 100 6 3 Starcomms Nigeria Limited Complete listing at http://thyme.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 209 3013 3874 622 Qwest 6389 2671 3260 199 bellsouth.net, inc. 4755 1668 387 90 Videsh Sanchar Nigam Ltd. Aut 2386 1496 663 877 AT&T Data Communications Serv 4323 1469 1044 376 Time Warner Telecom 7018 1395 5822 976 AT&T WorldNet Services 8151 1273 2464 227 UniNet S.A. de C.V. 11492 1231 150 12 Cable One 17488 1188 82 91 Hathway IP Over Cable Interne 9583 1163 111 420 Sify Limited Complete listing at http://thyme.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 6389 2671 2472 bellsouth.net, inc. 4755 1668 1578 Videsh Sanchar Nigam Ltd. Aut 11492 1231 1219 Cable One 17488 1188 1097 Hathway IP Over Cable Interne 4323 1469 1093 Time Warner Telecom 8151 1273 1046 UniNet S.A. de C.V. 18566 1045 1035 Covad Communications 9498 1078 1016 BHARTI BT INTERNET LTD. 1785 1080 976 AppliedTheory Corporation 22773 966 904 Cox Communications, Inc. Complete listing at http://thyme.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 16927 UNALLOCATED 12.0.252.0/23 701 UUNET Technologies, 22492 UNALLOCATED 12.2.46.0/24 7018 AT&T WorldNet Servic 15132 UNALLOCATED 12.9.150.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.14.170.0/24 7018 AT&T WorldNet Servic 13632 UNALLOCATED 12.20.55.0/24 6517 Yipes Communications 13746 UNALLOCATED 12.24.56.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.25.107.0/24 7018 AT&T WorldNet Servic 13632 UNALLOCATED 12.31.25.0/24 6517 Yipes Communications 27220 UNALLOCATED 12.35.204.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.152.0/24 7018 AT&T WorldNet Servic Complete listing at http://thyme.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 24.48.244.0/23 7843 Adelphia Corp. 24.51.159.0/24 7843 Adelphia Corp. 24.54.23.0/24 7843 Adelphia Corp. 24.54.224.0/19 20001 HoldCo LLC - Road Runner 24.75.160.0/19 7843 Adelphia Corp. 24.75.192.0/18 7843 Adelphia Corp. 24.142.40.0/21 7018 AT&T WorldNet Services 24.142.160.0/19 7018 AT&T WorldNet Services 24.246.0.0/17 7018 AT&T WorldNet Services 24.246.128.0/18 7018 AT&T WorldNet Services Complete listing at http://thyme.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:18 /9:9 /10:16 /11:44 /12:143 /13:281 /14:514 /15:1037 /16:9958 /17:4325 /18:7368 /19:15727 /20:18361 /21:17999 /22:22360 /23:23307 /24:136792 /25:859 /26:1032 /27:783 /28:81 /29:9 /30:1 /31:0 /32:7 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 209 1769 3013 Qwest 6389 1670 2671 bellsouth.net, inc. 11492 1211 1231 Cable One 2386 1191 1496 AT&T Data Communications Serv 18566 1026 1045 Covad Communications 9583 1013 1163 Sify Limited 4755 1009 1668 Videsh Sanchar Nigam Ltd. Aut 17488 1002 1188 Hathway IP Over Cable Interne 6298 976 991 Cox Communicatons 6478 947 956 AT&T Worldnet Services Complete listing at http://thyme.apnic.net/current/data/sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 4:7 8:118 12:2060 13:2 15:22 16:3 17:5 18:13 20:35 24:1071 25:1 32:62 38:446 40:92 41:651 43:1 44:2 47:6 52:3 55:3 56:3 57:24 58:501 59:501 60:448 61:1001 62:1188 63:2031 64:3288 65:2386 66:3533 67:1229 68:694 69:2278 70:681 71:121 72:1821 73:5 74:1028 75:159 76:299 77:738 78:710 79:199 80:950 81:848 82:612 83:393 84:577 85:1024 86:417 87:701 88:335 89:1285 90:14 91:1301 92:205 93:590 94:52 96:37 97:27 98:168 99:3 112:1 113:1 114:58 116:762 117:329 118:182 119:446 120:49 121:554 122:793 123:360 124:858 125:1153 128:362 129:202 130:131 131:409 132:67 133:9 134:177 135:33 136:220 137:87 138:145 139:93 140:489 141:99 142:415 143:311 144:365 145:51 146:364 147:154 148:511 149:197 150:120 151:191 152:131 153:136 154:10 155:277 156:174 157:277 158:186 159:240 160:276 161:114 162:239 163:187 164:523 165:449 166:319 167:327 168:620 169:136 170:428 171:30 172:10 189:242 190:2141 192:5787 193:4104 194:3221 195:2511 196:1048 198:3730 199:3274 200:5545 201:1456 202:7622 203:8020 204:3970 205:2131 206:2391 207:2772 208:3388 209:3520 210:2571 211:1051 212:1430 213:1631 214:148 215:49 216:4396 217:1199 218:339 219:412 220:1068 221:471 222:309 End of report From nanog at ian.co.uk Fri Jun 27 13:21:42 2008 From: nanog at ian.co.uk (Ian Mason) Date: Fri, 27 Jun 2008 19:21:42 +0100 Subject: ICANN opens up Pandora's Box of new TLDs In-Reply-To: <20080627011301.GA821217@hiwaay.net> References: <7ff145960806261309u4eda28b7v8973556b983df63a@mail.gmail.com> <20080626203334.GA18237@cgi.jachomes.com> <48642C9E.70806@wvi.com> <46610B65-23E5-466E-B1FF-FEB1C56D7774@mailchannels.com> <20080627011301.GA821217@hiwaay.net> Message-ID: <9391100D-F3EE-410E-A28E-0D8849DF0BA4@ian.co.uk> On 27 Jun 2008, at 02:13, Chris Adams wrote: > Once upon a time, Ken Simpson said: >> Oooh -- dibs on that one. And .some, so you can register awe.some, >> trouble.some, and fear.some. And .ous, which would allow humm.ous, >> seri.ous, fabul.ous, etc.. > > Somebody on /. mentioned .dot, so you could tell someone to go to: > > eych tee tee pee colon slash slash slash dot dot dot > Or .dash ... From tme at multicasttech.com Fri Jun 27 13:34:11 2008 From: tme at multicasttech.com (Marshall Eubanks) Date: Fri, 27 Jun 2008 14:34:11 -0400 Subject: what problem are we solving? (was Re: ICANN opens up Pandora's Box of new TLDs) In-Reply-To: References: <171423de0806271024h73e9a181t1df338aa5fe84ef5@mail.gmail.com> Message-ID: <81B64E0E-DC0C-4DED-BEF7-7CC486243988@multicasttech.com> On Jun 27, 2008, at 1:57 PM, Bill Nash wrote: > On Fri, 27 Jun 2008, Scott Francis wrote: > >> perhaps somebody with more insight can explain the rationale to me >> (DRC?) - is there a purpose served here aside from corporate/legal >> interests? > > It strikes me as fomenting another gold rush. The notion that > disputed TLDs go up for auction sounds like a request for a nice, > high quality money printing device. I may have skimmed over it, but > where does the money from these auctions go? At the risk of invoking > Ron Paul, this will turn TLDs into a fiat currency, and devalue the > rest of them. A small subset of people will profit, and everyone > else loses. > > Off the top of my head, I can see some high dollar fist fights > breaking out for .sex, .porn, .games, .hotel, etc. It'll be like > the .alt tree on usenet for people with money. There may also be an > actual fist fight over TLDs like .irc, .leet, .goatse, and .krad. > Maybe not .krad. > The Newdom WG was frequently insane, reaching its peak in the hack for which Eugene Kashpureff went to jail. I for one would not want to go there again. > I agree with Scott, I'd rather see ICANN spend time on current > problems instead of making new ones. > +1 > - billn > Marshall From sil at infiltrated.net Fri Jun 27 13:52:37 2008 From: sil at infiltrated.net (J. Oquendo) Date: Fri, 27 Jun 2008 14:52:37 -0400 Subject: Attn: Paul Vixie Message-ID: <486536F5.2090404@infiltrated.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Please shoot me an offlist email (sorry for the excess traffic list) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQIVAwUBSGU2IoOeOV2sx4+mAQJmEA//evs/h35ND0RkuFc8Yvu1mUloUoF69Zc5 quWiqg4FsEHXtZLAeppkF+zaFCzh1kLh7SOWSGriKRPahtI3nrjGe+IPRJN3JNkv YmvYRj7pdihzUBH+2p/0S7GQoHBzDGp40s97a+/JGkCi1Zsv2dCyMAEvpUJeu+LR Fl5ncTOuEFIMQo4oftJxlToyoktLnuxMpjey6k9a0D2kcqo6066IwoIp7yjbt73V 0xT43Yz+C/3wGwrxPj/ijK7m4kC77asvycu5uP9gAa15rn+fhjvLD6voOY/4QNMW lo//nodF4/ZgZ/bEMp46YZbdcEJNBSDdnqYPxZVT7RVfOpiLtc3DjRonogyGL/gx ZpHUGWtZDSG5QF/uETGEmea81B7KwuLWzDHPQbIReHW8C5aPQo6iYT/Uv7uIey8D llSCcgfLQxYvd0BEIAoVGmNud9i3YlUUczCeiaDJzJmml45M4A/v2lsfLhnO2dgv aFU7aKW3EaWGWvIcfJP82oxHBbOl2Dbt80RtyN9vWsYY0nqQbafjMmm5WtjrMv2+ 57K9syxtCVYUFiYIAPggXylFen3s1E+bGufjS3HjJ8U/RluRj7u7FBZIQN7tJWPd P+ZJQ8K+ewcrQO59VBYlpq7fT/6f0o1z0mIK3KgRIfLPaAMDuAfbIi3BhY3Rbr9z oHq63Z8fju4= =omjA -----END PGP SIGNATURE----- From regnauld at catpipe.net Fri Jun 27 13:58:46 2008 From: regnauld at catpipe.net (Phil Regnauld) Date: Fri, 27 Jun 2008 20:58:46 +0200 Subject: what problem are we solving? (was Re: ICANN opens up Pandora's Box of new TLDs) In-Reply-To: References: <171423de0806271024h73e9a181t1df338aa5fe84ef5@mail.gmail.com> Message-ID: <20080627185846.GB26861@catpipe.net> David Conrad (drc) writes: > > Other folks believe that anything that reduces the effective monopoly > VeriSign has (through .COM and .NET) would be a good thing. This view > holds that by increasing the number of top-level domains, you increase the > opportunities for consumer (that is, domain registrant) choice, thereby > reducing the value of any single top-level domain. The process ensures that too few new TLDs will be created for it being a threat to VeriSign, but sufficiently enough of them will be created that it will bring in lots of cash, if only with application fees, auction, but also because of the perceived rarity. As business models go, it's a fine example of how to build demand without really servicing the community. > component of this management was explicitly stated as being the promotion > of competition. While one might argue that creating new top-level domains > doesn't really promote competition given the cost of changing from one > domain name to another, realistically, I figure there aren't many other > ways in which additional opportunities for competition can be created. Allowing anyone to register a TLD is one, but I do agree it's not necessarily a trivial model. From dot at dotat.at Fri Jun 27 14:16:33 2008 From: dot at dotat.at (Tony Finch) Date: Fri, 27 Jun 2008 20:16:33 +0100 Subject: ICANN opens up Pandora's Box of new TLDs In-Reply-To: <6C77CFAD-95E5-4413-B58C-16101A8552A8@ca.afilias.info> References: <7ff145960806261309u4eda28b7v8973556b983df63a@mail.gmail.com> <20080626203334.GA18237@cgi.jachomes.com> <48642C9E.70806@wvi.com> <46610B65-23E5-466E-B1FF-FEB1C56D7774@mailchannels.com> <20656.1214580173@turing-police.cc.vt.edu> <6C77CFAD-95E5-4413-B58C-16101A8552A8@ca.afilias.info> Message-ID: On Fri, 27 Jun 2008, Joe Abley wrote: > > To my mind, Tony Finch owns you all :-) > > http://dotat.at/ > dot at dotat.at The Austrians should not have given up on their hierarchial naming scheme. Tony. -- f.anthony.n.finch http://dotat.at/ NORTH FITZROY SOLE: WEST OR SOUTHWEST 4 OR 5, OCCASIONALLY 6. ROUGH OR VERY ROUGH DECREASING MODERATE OR ROUGH. OCCASIONAL RAIN. MODERATE OR GOOD. From dot at dotat.at Fri Jun 27 14:20:59 2008 From: dot at dotat.at (Tony Finch) Date: Fri, 27 Jun 2008 20:20:59 +0100 Subject: ICANN opens up Pandora's Box of new TLDs In-Reply-To: <4864B0F0.4070203@aset.com> References: <7ff145960806261309u4eda28b7v8973556b983df63a@mail.gmail.com> <20080626203334.GA18237@cgi.jachomes.com> <48642C9E.70806@wvi.com> <4864B0F0.4070203@aset.com> Message-ID: On Fri, 27 Jun 2008, Jon Kibler wrote: > > Well, I guess this shoots in the foot Microsoft's name server best > practices of setting up your AD domain as foo.LOCAL, using the logic > that .LOCAL is safe because it cannot be resolved by the root name servers. .local is also used by MDNS. (Nice interop problem there.) Tony. -- f.anthony.n.finch http://dotat.at/ ROCKALL MALIN: CYCLONIC BECOMING SOUTHWESTERLY 5 OR 6, OCCASIONALLY 7 AT FIRST. MODERATE OR ROUGH, OCCASIONALLY VERY ROUGH. RAIN OR THUNDERY SHOWERS. MODERATE OR GOOD, OCCASIONALLY POOR. From dot at dotat.at Fri Jun 27 14:22:59 2008 From: dot at dotat.at (Tony Finch) Date: Fri, 27 Jun 2008 20:22:59 +0100 Subject: ICANN opens up Pandora's Box of new TLDs In-Reply-To: <48640FC2.2000909@spaghetti.zurich.ibm.com> References: <7ff145960806261309u4eda28b7v8973556b983df63a@mail.gmail.com> <5429E6E0-382A-4711-8D8C-2A241B6E4F6A@mailchannels.com> <48640FC2.2000909@spaghetti.zurich.ibm.com> Message-ID: On Thu, 26 Jun 2008, Jeroen Massar wrote: > > thinking of all the nice security issues which come along (home, mycomputer > and .exe etc anyone ? :) .exe has the same security properties as .com Tony. -- f.anthony.n.finch http://dotat.at/ TYNE DOGGER FISHER: SOUTH OR SOUTHWEST 4 OR 5, OCCASIONALLY 6. MODERATE OR ROUGH. OCCASIONAL RAIN. MODERATE OR GOOD, OCCASIONALLY POOR. From darkuncle at gmail.com Fri Jun 27 14:23:28 2008 From: darkuncle at gmail.com (Scott Francis) Date: Fri, 27 Jun 2008 12:23:28 -0700 Subject: what problem are we solving? (was Re: ICANN opens up Pandora's Box of new TLDs) In-Reply-To: <8386.1214589980@turing-police.cc.vt.edu> References: <171423de0806271024h73e9a181t1df338aa5fe84ef5@mail.gmail.com> <8386.1214589980@turing-police.cc.vt.edu> Message-ID: <171423de0806271223w5240f6f1s8005766773404ef5@mail.gmail.com> On Fri, Jun 27, 2008 at 11:06 AM, wrote: > On Fri, 27 Jun 2008 10:24:48 PDT, Scott Francis said: > >> serve to increase complexity and add additional confusion to a system >> that the standard user has just now come to grips with >> ("www.company.com will get me Company's official, legitimate page"). > > Funny you should say that. :) > > On my way back from lunch, I heard an ad on the radio for a company in > town that said: "or visit blueridgerealestate.org". > > Yep. dot-org, because the dot-com variant is owned by another company > some 50 miles from here. > > And doing a 'whois' on both shows that "company" didn't get "company.com" > because somebody else snagged it first. So it's a crap shoot regarding > whether the .com gets you the "official legitimate page"... that's exactly my point! it's _not_ reliable, but it's the behavior that the average user has come to expect. If we can't even guarantee reliability with the small handful of TLDs currently in use, when we start introducing arbitrary new ones to anybody that can pay, I'm concerned that it's going to make user support even more of a headache (for those of us unfortunate enough to be involved in that role, professionally or personally :)) -- darkuncle@{gmail.com,darkuncle.net} || 0x5537F527 http://darkuncle.net/pubkey.asc for public key From randy at psg.com Fri Jun 27 14:23:53 2008 From: randy at psg.com (Randy Bush) Date: Sat, 28 Jun 2008 04:23:53 +0900 Subject: what problem are we solving? (was Re: ICANN opens up Pandora's Box of new TLDs) In-Reply-To: <20080627185846.GB26861@catpipe.net> References: <171423de0806271024h73e9a181t1df338aa5fe84ef5@mail.gmail.com> <20080627185846.GB26861@catpipe.net> Message-ID: <48653E49.2030904@psg.com> >> realistically, I figure there aren't many other ways in which >> additional opportunities for competition can be created. > Allowing anyone to register a TLD is one, but I do agree it's not > necessarily a trivial model. we have two tools with which to build scale, distribution and hierarchy. this goes against both, though maybe the latter a bit more than the former. this is one of those where the short term business/political gain trumps the long term pain it can cause. we're not very good at this kind of trade-off because we discount future pain very very heavily. and you gotta love the spin that excess pain will be damped by the very high fee. i wonder how much of it will go to where the pain is actually felt, the root servers. randy From jra at baylink.com Fri Jun 27 14:26:50 2008 From: jra at baylink.com (Jay R. Ashworth) Date: Fri, 27 Jun 2008 15:26:50 -0400 Subject: ICANN opens up Pandora's Box of new TLDs In-Reply-To: References: <7ff145960806261309u4eda28b7v8973556b983df63a@mail.gmail.com> <20080626203334.GA18237@cgi.jachomes.com> Message-ID: <20080627192650.GP22330@cgi.jachomes.com> On Thu, Jun 26, 2008 at 11:07:57PM -0000, Martin Hannigan wrote: [ quoting me ] > >And no, companies *aren't* "forced to pay for another domain name" just > >because a new TLD appears -- they aren't doing it *now*, by and large, > >and thank ghod: > > The last time I looked there were a few thousand companies protecting > their intellectual property by using companies like Mark Monitor to > insure that they had defensive registrations in all ccTLD's possible. Sure; MarkMonitor has a great sales staff. But the methods by which you can violate a trademark are *very* clearly defined, and the mere existence of a domain name doesn't seem to be one of them. IANAL. Cheers, -- jra -- Jay R. Ashworth jra at baylink.com Designer +-Internetworking------+---------+ RFC 2100 Ashworth & Associates | Best Practices Wiki | | '87 e24 St Petersburg FL USA +-http://bestpractices.wikia.com-+ +1 727 647 1274 If you can read this... thank a system administrator. Or two. --me From jra at baylink.com Fri Jun 27 14:29:32 2008 From: jra at baylink.com (Jay R. Ashworth) Date: Fri, 27 Jun 2008 15:29:32 -0400 Subject: ICANN opens up Pandora's Box of new TLDs In-Reply-To: <6C77CFAD-95E5-4413-B58C-16101A8552A8@ca.afilias.info> References: <7ff145960806261309u4eda28b7v8973556b983df63a@mail.gmail.com> <20080626203334.GA18237@cgi.jachomes.com> <48642C9E.70806@wvi.com> <46610B65-23E5-466E-B1FF-FEB1C56D7774@mailchannels.com> <20656.1214580173@turing-police.cc.vt.edu> <6C77CFAD-95E5-4413-B58C-16101A8552A8@ca.afilias.info> Message-ID: <20080627192932.GQ22330@cgi.jachomes.com> On Fri, Jun 27, 2008 at 11:44:35AM -0400, Joe Abley wrote: > On 27 Jun 2008, at 11:22, Valdis.Kletnieks at vt.edu wrote: > >"How about .dot? I'd like to set up a hostname of > >dotdot.dashdashdashdot.dot" > > To my mind, Tony Finch owns you all :-) > > http://dotat.at/ > dot at dotat.at Well, I believe the gent whose email is "up at 3.am" is tied with him... Cheers, -- jra -- Jay R. Ashworth jra at baylink.com Designer +-Internetworking------+---------+ RFC 2100 Ashworth & Associates | Best Practices Wiki | | '87 e24 St Petersburg FL USA +-http://bestpractices.wikia.com-+ +1 727 647 1274 If you can read this... thank a system administrator. Or two. --me From mhuff at ox.com Fri Jun 27 14:35:04 2008 From: mhuff at ox.com (Matthew Huff) Date: Fri, 27 Jun 2008 15:35:04 -0400 Subject: what problem are we solving? (was Re: ICANN opens up Pandora'sBox of new TLDs) In-Reply-To: <171423de0806271223w5240f6f1s8005766773404ef5@mail.gmail.com> References: <171423de0806271024h73e9a181t1df338aa5fe84ef5@mail.gmail.com><8386.1214589980@turing-police.cc.vt.edu> <171423de0806271223w5240f6f1s8005766773404ef5@mail.gmail.com> Message-ID: <5218D1934E787843B5235E139DE0E0300650F7EE@PUR-EXCH03VS1.ox.com> > that's exactly my point! it's _not_ reliable, but it's the behavior > that the average user has come to expect. If we can't even guarantee > reliability with the small handful of TLDs currently in use, when we > start introducing arbitrary new ones to anybody that can pay, I'm > concerned that it's going to make user support even more of a headache > (for those of us unfortunate enough to be involved in that role, > professionally or personally :)) > -- > darkuncle@{gmail.com,darkuncle.net} || 0x5537F527 > http://darkuncle.net/pubkey.asc for public key It's amusing to see companies actually profit from this behavior. The poker gambling sites know they can't advertise on TV as a gambling site, so everyone of their ads mention *.net which is their play for free site. They know that a major of people will instead go to their *.com website which isn't a free site. From jra at baylink.com Fri Jun 27 14:35:08 2008 From: jra at baylink.com (Jay R. Ashworth) Date: Fri, 27 Jun 2008 15:35:08 -0400 Subject: ICANN opens up Pandora's Box of new TLDs In-Reply-To: <20080627024941.GA29345@gsp.org> References: <7ff145960806261309u4eda28b7v8973556b983df63a@mail.gmail.com> <5429E6E0-382A-4711-8D8C-2A241B6E4F6A@mailchannels.com> <20080627024941.GA29345@gsp.org> Message-ID: <20080627193508.GS22330@cgi.jachomes.com> On Thu, Jun 26, 2008 at 10:49:41PM -0400, Rich Kulawiec wrote: > For example: the .info TLD is completely overrun with spammers, to > the point where many people, including me, have simply blacklisted the > whole thing. The irony that MailScanner's domain is mailscanner.info is absolutely deafening. Cheers, -- jra -- Jay R. Ashworth jra at baylink.com Designer +-Internetworking------+---------+ RFC 2100 Ashworth & Associates | Best Practices Wiki | | '87 e24 St Petersburg FL USA +-http://bestpractices.wikia.com-+ +1 727 647 1274 If you can read this... thank a system administrator. Or two. --me From jra at baylink.com Fri Jun 27 14:36:16 2008 From: jra at baylink.com (Jay R. Ashworth) Date: Fri, 27 Jun 2008 15:36:16 -0400 Subject: ICANN opens up Pandora's Box of new TLDs In-Reply-To: <004b01c8d7ef$813f3d20$83bdb760$@com> References: <200806262259.XAA10700@sunf10.rd.bbc.co.uk> <004b01c8d7ef$813f3d20$83bdb760$@com> Message-ID: <20080627193616.GT22330@cgi.jachomes.com> On Thu, Jun 26, 2008 at 08:48:08PM -0400, TJ wrote: > Ah, but some are ... for trademark or brand protection usually. But most trademark holders aren't *entitled* to that much protection: unless they do business worldwide, *and* have a "famous" mark. Cheers, -- jra -- Jay R. Ashworth jra at baylink.com Designer +-Internetworking------+---------+ RFC 2100 Ashworth & Associates | Best Practices Wiki | | '87 e24 St Petersburg FL USA +-http://bestpractices.wikia.com-+ +1 727 647 1274 If you can read this... thank a system administrator. Or two. --me From jra at baylink.com Fri Jun 27 14:39:30 2008 From: jra at baylink.com (Jay R. Ashworth) Date: Fri, 27 Jun 2008 15:39:30 -0400 Subject: ICANN opens up Pandora's Box of new TLDs In-Reply-To: <48646613.8020409@vaxination.ca> References: <7ff145960806261309u4eda28b7v8973556b983df63a@mail.gmail.com> <48646613.8020409@vaxination.ca> Message-ID: <20080627193930.GU22330@cgi.jachomes.com> On Fri, Jun 27, 2008 at 12:01:23AM -0400, Jean-Fran?ois Mezei wrote: > Does anyone know how if the new gTLD system will still give some "veto" > power to some people over some domain names that are morally objectable > to some people ? > > I am not thinking of only .SEX but perhaps also .GOD .GAY .ALLAH .BI > .CHRISTIAN .LESBIAN .MORMON .JEW .JEWISH .ISLAM etc. .WOMEN-WITH-VISIBLE-FACES? > For instance, in the USA "ABC" is the american broadcasting companies, > but in australia, it is the Australian Broadcasting Corporation. > > Is it fair to hand .ABC to either one of the two ? (highest bidder) or > will ICANN "lock" .ABC out so that neither can get to it ? I am sure > there are many such gTLDs around the world that would conflict across > countries. Sure, which is why that's not what should be being *done* with GTLDs. But engineering issues will be the very least of anyone's concern here. Cheers, -- jra -- ay R. Ashworth jra at baylink.com Designer +-Internetworking------+---------+ RFC 2100 Ashworth & Associates | Best Practices Wiki | | '87 e24 St Petersburg FL USA +-http://bestpractices.wikia.com-+ +1 727 647 1274 If you can read this... thank a system administrator. Or two. --me From jra at baylink.com Fri Jun 27 14:46:11 2008 From: jra at baylink.com (Jay R. Ashworth) Date: Fri, 27 Jun 2008 15:46:11 -0400 Subject: what problem are we solving? (was Re: ICANN opens up Pandora's Box of new TLDs) In-Reply-To: <171423de0806271223w5240f6f1s8005766773404ef5@mail.gmail.com> References: <171423de0806271024h73e9a181t1df338aa5fe84ef5@mail.gmail.com> <8386.1214589980@turing-police.cc.vt.edu> <171423de0806271223w5240f6f1s8005766773404ef5@mail.gmail.com> Message-ID: <20080627194611.GV22330@cgi.jachomes.com> On Fri, Jun 27, 2008 at 12:23:28PM -0700, Scott Francis wrote: > that's exactly my point! it's _not_ reliable, but it's the behavior > that the average user has come to expect. If we can't even guarantee > reliability with the small handful of TLDs currently in use, when we > start introducing arbitrary new ones to anybody that can pay, I'm > concerned that it's going to make user support even more of a headache > (for those of us unfortunate enough to be involved in that role, > professionally or personally :)) That sounds like the "gun control will reduce gun crime" argument, to me. :-) If there are enough *widely used* (generic) TLDs, then *people will stop believing that ".com is the 'real' domain" (wasn't that Verisign's sales pitch, once upon a time?). Cheers -- jra -- Jay R. Ashworth jra at baylink.com Designer +-Internetworking------+---------+ RFC 2100 Ashworth & Associates | Best Practices Wiki | | '87 e24 St Petersburg FL USA +-http://bestpractices.wikia.com-+ +1 727 647 1274 If you can read this... thank a system administrator. Or two. --me From tomb at byrneit.net Fri Jun 27 14:48:08 2008 From: tomb at byrneit.net (Tomas L. Byrnes) Date: Fri, 27 Jun 2008 12:48:08 -0700 Subject: ICANN opens up Pandora's Box of new TLDs In-Reply-To: References: <7ff145960806261309u4eda28b7v8973556b983df63a@mail.gmail.com><20080626203334.GA18237@cgi.jachomes.com><48642C9E.70806@wvi.com> <4864B0F0.4070203@aset.com> Message-ID: <70D072392E56884193E3D2DE09C097A9F29E@pascal.zaphodb.org> If they assign .local, they will break the default for AD, especially SBS, Apple Rendezvous, anything using mDNS/Zeroconf, and a lot of other "local significance only" uses of DNS, or, which is more likely, the domains in .local will find themselves unresolvable from a very large portion of the Internet. .local should be reserved. > -----Original Message----- > From: Tony Finch [mailto:dot at dotat.at] > Sent: Friday, June 27, 2008 12:21 PM > To: Jon Kibler > Cc: NANOG list > Subject: Re: ICANN opens up Pandora's Box of new TLDs > > On Fri, 27 Jun 2008, Jon Kibler wrote: > > > > Well, I guess this shoots in the foot Microsoft's name server best > > practices of setting up your AD domain as foo.LOCAL, using > the logic > > that .LOCAL is safe because it cannot be resolved by the > root name servers. > > .local is also used by MDNS. (Nice interop problem there.) > > Tony. > -- > f.anthony.n.finch http://dotat.at/ ROCKALL > MALIN: CYCLONIC BECOMING SOUTHWESTERLY 5 OR 6, OCCASIONALLY 7 > AT FIRST. MODERATE OR ROUGH, OCCASIONALLY VERY ROUGH. RAIN OR > THUNDERY SHOWERS. > MODERATE OR GOOD, OCCASIONALLY POOR. > > From marquis at roble.com Fri Jun 27 15:32:05 2008 From: marquis at roble.com (Roger Marquis) Date: Fri, 27 Jun 2008 13:32:05 -0700 (PDT) Subject: ICANN opens up Pandora's Box of new TLDs In-Reply-To: References: Message-ID: <20080627203205.51B612B7C02@mx5.roble.com> Phil Regnauld wrote: > As business models go, it's a fine example of how to build demand > without really servicing the community. Of all the ways new tlds could have been implemented this has to be the most poorly thought out. Security-aware programmers will now be unable to apply even cursory tests for domain name validity. Phishers and spammers will have a field day with the inevitable namespace collisions. It is, however, unfortunately consistent with ICANN's inability to address other security issues such as fast flush DNS, domain tasting (botnets), and requiring valid domain contacts. The core problem seems to be financial, as this is likely the most revenue generating plan (both over and under the table) ICANN bean-counters could have dreamed up. It certainly was not the foreseen outcome when non-profit status was mandated. I have to conclude that ICANN has failed, simply failed, and should be returned to the US government. Perhaps the DHL would at least solicit for RFCs from the security community. Roger Marquis From drc at virtualized.org Fri Jun 27 15:40:03 2008 From: drc at virtualized.org (David Conrad) Date: Fri, 27 Jun 2008 13:40:03 -0700 Subject: ICANN opens up Pandora's Box of new TLDs In-Reply-To: References: <20080627120549.32616.qmail@simone.iecc.com> Message-ID: Hi, On Jun 27, 2008, at 5:22 AM, Alexander Harrowell wrote: > Well, at least the new TLDs will promote DNS-based cruft filtration. > You can > already safely ignore anything with a .name, .biz, .info, .tv > suffix, to > name just the worst. Does this actually work? The vast majority of spam I receive has an origin that doesn't reverse map. Of those messages that have origins (as extracted from the appropriate Received header) that do reverse map, the majority are in com and net. The mail origins of the top 10 TLDs from the last 30K spam messages I've received): unknown: 12487 net: 2586 com: 1664 pl: 1093 ru: 917 it: 851 br: 652 de: 479 th: 372 fr: 226 Biz, info, and name don't show up at all. Looking at the 'From' lines, I get: com: 13432 de: 8819 net: 1959 org: 1902 uk: 256 it: 246 nl: 240 edu: 229 au: 181 ca: 180 What cruft are you filtering using top-level domains? Thanks, -drc From drc at virtualized.org Fri Jun 27 15:41:53 2008 From: drc at virtualized.org (David Conrad) Date: Fri, 27 Jun 2008 13:41:53 -0700 Subject: what problem are we solving? (was Re: ICANN opens up Pandora's Box of new TLDs) In-Reply-To: References: <171423de0806271024h73e9a181t1df338aa5fe84ef5@mail.gmail.com> Message-ID: <4D0B482D-8FD5-48A5-9FF6-C2011AA7ACB5@virtualized.org> On Jun 27, 2008, at 10:57 AM, Bill Nash wrote: > I'd rather see ICANN spend time on current problems instead of > making new ones. Out of curiosity, what are the problems you feel ICANN should be spending its time on? Regards, -drc From drc at virtualized.org Fri Jun 27 15:45:04 2008 From: drc at virtualized.org (David Conrad) Date: Fri, 27 Jun 2008 13:45:04 -0700 Subject: what problem are we solving? (was Re: ICANN opens up Pandora's Box of new TLDs) In-Reply-To: <20080627185846.GB26861@catpipe.net> References: <171423de0806271024h73e9a181t1df338aa5fe84ef5@mail.gmail.com> <20080627185846.GB26861@catpipe.net> Message-ID: On Jun 27, 2008, at 11:58 AM, Phil Regnauld wrote: > The process ensures that too few new TLDs will be created for > it being a threat to VeriSign This remains to be seen, at least from my perspective. I have no idea how many TLDs are going to make it through the gauntlet or even how many applicants there will be. If nothing else, I'm sure it'll be 'interesting' (for some value of that variable). Regards, -drc From drc at virtualized.org Fri Jun 27 15:49:09 2008 From: drc at virtualized.org (David Conrad) Date: Fri, 27 Jun 2008 13:49:09 -0700 Subject: what problem are we solving? (was Re: ICANN opens up Pandora's Box of new TLDs) In-Reply-To: <171423de0806271223w5240f6f1s8005766773404ef5@mail.gmail.com> References: <171423de0806271024h73e9a181t1df338aa5fe84ef5@mail.gmail.com> <8386.1214589980@turing-police.cc.vt.edu> <171423de0806271223w5240f6f1s8005766773404ef5@mail.gmail.com> Message-ID: <25EAEE91-34BB-4967-B5E7-91355AFFFE1A@virtualized.org> On Jun 27, 2008, at 12:23 PM, Scott Francis wrote: > If we can't even guarantee > reliability with the small handful of TLDs currently in use, when we > start introducing arbitrary new ones to anybody that can pay, I'm > concerned that it's going to make user support even more of a headache I might suggest that the assumption that reliability can be guaranteed by TLD (any number), regardless of what the labels might imply, is where things are broken. That ship has sailed (and already crashed into the rocks and sunk). Regards, -drc From darkuncle at gmail.com Fri Jun 27 16:02:34 2008 From: darkuncle at gmail.com (Scott Francis) Date: Fri, 27 Jun 2008 14:02:34 -0700 Subject: what problem are we solving? (was Re: ICANN opens up Pandora's Box of new TLDs) In-Reply-To: <25EAEE91-34BB-4967-B5E7-91355AFFFE1A@virtualized.org> References: <171423de0806271024h73e9a181t1df338aa5fe84ef5@mail.gmail.com> <8386.1214589980@turing-police.cc.vt.edu> <171423de0806271223w5240f6f1s8005766773404ef5@mail.gmail.com> <25EAEE91-34BB-4967-B5E7-91355AFFFE1A@virtualized.org> Message-ID: <171423de0806271402p5e9e9be9l283233fad83cac75@mail.gmail.com> On Fri, Jun 27, 2008 at 1:49 PM, David Conrad wrote: > On Jun 27, 2008, at 12:23 PM, Scott Francis wrote: >> >> If we can't even guarantee >> reliability with the small handful of TLDs currently in use, when we >> start introducing arbitrary new ones to anybody that can pay, I'm >> concerned that it's going to make user support even more of a headache > > I might suggest that the assumption that reliability can be guaranteed by > TLD (any number), regardless of what the labels might imply, is where things > are broken. That ship has sailed (and already crashed into the rocks and > sunk). indeed, TLD provides no assurance of authenticity. However, my concern is that adding add'l TLDs will make this problem worse, not better - what little assurance we have that e.g. bankofamerica.com is the legitimate (or should I say, _a_ legitimate) site for the financial institution of the same name becomes less certain when we have e.g. bank.of.america, www.bankofamerica.bank, www.bankofamerica, www.bofa, and other variants. Perhaps the solution is to devalue names (through the introduction of some theoretically unlimited number of variants) to the point that users come to rely upon reputation-based systems (e.g. PageRank) exclusively. Or maybe I'm just brewing a tempest in a teapot. *shrug* What I do know is that the folks @ ICANN who were involved in this are universally more experienced than myself, so I think perhaps I'll pipe down for a while and see what happens. :) cheers, -- darkuncle@{gmail.com,darkuncle.net} || 0x5537F527 http://darkuncle.net/pubkey.asc for public key From jfmezei at vaxination.ca Fri Jun 27 16:04:19 2008 From: jfmezei at vaxination.ca (=?ISO-8859-1?Q?Jean-Fran=E7ois_Mezei?=) Date: Fri, 27 Jun 2008 17:04:19 -0400 Subject: what problem are we solving? (was Re: ICANN opens up Pandora's Box of new TLDs) In-Reply-To: References: <171423de0806271024h73e9a181t1df338aa5fe84ef5@mail.gmail.com> Message-ID: <486555D3.7090107@vaxination.ca> Bill Nash wrote: > Off the top of my head, I can see some high dollar fist fights breaking > out for .sex, .porn, .games, .hotel, etc. It'll be like the .alt tree on > usenet for people with money. There may also be an actual fist fight over > TLDs like .irc, .leet, .goatse, and .krad. Maybe not .krad. Say I am a pastry chef, and I pay $40 per year for "pastry.com", I got it because I signed up early and now cherish my domain name. I am a small business. But now, some rich guy can come in and bid for .pastry I have no money to participate in this endeavour, and no intentions of running my own TLD. All I can do is voice an objection, but if the other guy is also involved in food, he is likely to convince ICANN's comittees that it is a legitimate request. Then you end up with pastry.com being the original small business, and .pastry being anything else. This will lead to a lot of confusion. Yeah, for guys with deep pockets like yahoo, google, banks, GE and oil companies, they won't even notice a dent in their wallets when they register their own .TLD . For small businesses who worked early to get THEY name attached to a .com, they now see the value of their domain name evaporate because anyone else can now use a confusing variation of it and you just don't have the money to bid/auction against them I didn't have the time to carefully read all the documents that were pointed to here, but are there any requirements for a TLD to operate a true WHOIS server so people can easily verify the indetity of some site using a new .TLD ? (aka: to enable people to see that pastry.com is the original shop, while www.pastry is some impostor who started a pastry shop that is unrelated to pastry.com) From lists at internetpolicyagency.com Fri Jun 27 16:10:56 2008 From: lists at internetpolicyagency.com (Roland Perry) Date: Fri, 27 Jun 2008 22:10:56 +0100 Subject: what problem are we solving? (was Re: ICANN opens up Pandora's Box of new TLDs) In-Reply-To: References: <171423de0806271024h73e9a181t1df338aa5fe84ef5@mail.gmail.com> Message-ID: In article , Bill Nash writes >I agree with Scott, I'd rather see ICANN spend time on current problems >instead of making new ones. Did you express that opinion to the Paris meeting? [Not an attack on you specifically, but as this process has been ongoing for at least five years, I think I detect a number of people here hastily building stables, debating what kind of door to attach, when the horse is already several blocks away.] -- Roland Perry From Valdis.Kletnieks at vt.edu Fri Jun 27 16:15:00 2008 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 27 Jun 2008 17:15:00 -0400 Subject: what problem are we solving? (was Re: ICANN opens up Pandora's Box of new TLDs) In-Reply-To: Your message of "Fri, 27 Jun 2008 17:04:19 EDT." <486555D3.7090107@vaxination.ca> References: <171423de0806271024h73e9a181t1df338aa5fe84ef5@mail.gmail.com> <486555D3.7090107@vaxination.ca> Message-ID: <5940.1214601300@turing-police.cc.vt.edu> On Fri, 27 Jun 2008 17:04:19 EDT, =?ISO-8859-1?Q?Jean-Fran=E7ois_Mezei?= said: > Say I am a pastry chef, and I pay $40 per year for "pastry.com", I got > it because I signed up early and now cherish my domain name. I am a > small business. > > But now, some rich guy can come in and bid for .pastry This will prove interesting for users who are still using browsers that will automagically prepend 'www.' and append '.com'.. :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From drc at virtualized.org Fri Jun 27 16:21:08 2008 From: drc at virtualized.org (David Conrad) Date: Fri, 27 Jun 2008 14:21:08 -0700 Subject: what problem are we solving? (was Re: ICANN opens up Pandora's Box of new TLDs) In-Reply-To: <171423de0806271402p5e9e9be9l283233fad83cac75@mail.gmail.com> References: <171423de0806271024h73e9a181t1df338aa5fe84ef5@mail.gmail.com> <8386.1214589980@turing-police.cc.vt.edu> <171423de0806271223w5240f6f1s8005766773404ef5@mail.gmail.com> <25EAEE91-34BB-4967-B5E7-91355AFFFE1A@virtualized.org> <171423de0806271402p5e9e9be9l283233fad83cac75@mail.gmail.com> Message-ID: <48448CFF-E281-4932-A728-A5285CA4A517@virtualized.org> On Jun 27, 2008, at 2:02 PM, Scott Francis wrote: > what little assurance we have that e.g. bankofamerica.com is the > legitimate (or should I say, _a_ legitimate) site for the financial > institution of the same name becomes less certain when we have e.g. > bank.of.america, www.bankofamerica.bank, www.bankofamerica, www.bofa, > and other variants. I agree, but we already face that problem now. Is bankofamerica. {org,net,us} the same thing as bankofamerica.com? I would agree that a flood of new TLDs would exacerbate the problem, but I suspect the difference is between a run over on a two lane street versus being run over on a five lane highway. In both cases, you're road pizza.... > Perhaps the solution is to devalue names (through the introduction of > some theoretically unlimited number of variants) to the point that > users come to rely upon reputation-based systems (e.g. PageRank) > exclusively. I suspect the right answer is to rely not on reputation or labels, but rather stronger security credentials, e.g., valid X.509 certs, PGP/GPG signatures, etc. Of course, that's been true for a while now. Regards, -drc From drc at virtualized.org Fri Jun 27 16:25:12 2008 From: drc at virtualized.org (David Conrad) Date: Fri, 27 Jun 2008 14:25:12 -0700 Subject: ICANN opens up Pandora's Box of new TLDs In-Reply-To: <20080627203205.51B612B7C02@mx5.roble.com> References: <20080627203205.51B612B7C02@mx5.roble.com> Message-ID: On Jun 27, 2008, at 1:32 PM, Roger Marquis wrote: > Phil Regnauld wrote: >> As business models go, it's a fine example of how to build demand >> without really servicing the community. > > Of all the ways new tlds could have been implemented this has to be > the > most poorly thought out. Oh, no. There are plenty of worse thought out approaches. _Plenty_. > Security-aware programmers will now be unable to > apply even cursory tests for domain name validity. I'm not sure how much I'd trust a 'security-aware programmer' that relies on top-level domain name labels for _anything_, much less domain name validity. But perhaps I misunderstand your point. > Phishers and spammers > will have a field day with the inevitable namespace collisions. I believe an attempt at limiting this is found in the restriction to disallow 'confusingly similar' names. > It is, > however, unfortunately consistent with ICANN's inability to address > other > security issues such as fast flush DNS, domain tasting (botnets), and > requiring valid domain contacts. I suspect you might not be fully aware of how ICANN works. ICANN is not the Internet's mommy and it can't make problems go away (even those it created itself) by waving a magic wand. It works via a bottom-up policy definition process that involves a large number of parties, many of which are directly at odds with each other. Efforts are underway in several of ICANN's constituencies and advisory councils to propose solutions to all of these (e.g., for domain tasting see http://www.icann.org/minutes/resolutions-26jun08.htm#_Toc76113173) , but (as I have discovered painfully) it is exceedingly difficult to have rapid forward motion in such an environment. If you try, you get accused of acting in non-open, non-transparent, non-accountable, etc. ways by all sorts of people. Really. > [de rigueur ICANN bashing] It is easy to criticize (trust me, I do it all the time :-)). It is more difficult to participate to try and get things fixed. Regards, -drc From billn at billn.net Fri Jun 27 17:30:58 2008 From: billn at billn.net (Bill Nash) Date: Fri, 27 Jun 2008 15:30:58 -0700 (MST) Subject: what problem are we solving? (was Re: ICANN opens up Pandora's Box of new TLDs) In-Reply-To: <4D0B482D-8FD5-48A5-9FF6-C2011AA7ACB5@virtualized.org> References: <171423de0806271024h73e9a181t1df338aa5fe84ef5@mail.gmail.com> <4D0B482D-8FD5-48A5-9FF6-C2011AA7ACB5@virtualized.org> Message-ID: On Fri, 27 Jun 2008, David Conrad wrote: > On Jun 27, 2008, at 10:57 AM, Bill Nash wrote: >> I'd rather see ICANN spend time on current problems instead of making new >> ones. > > Out of curiosity, what are the problems you feel ICANN should be spending its > time on? > For starters, has Verisign ever been sanctioned by ICANN for it's business practices, with stupid stuff occurring as late as what, this past February (the front running debacle)? If ICANN is supposed to be encouraging competition, et cetera, why is Verisign still in business? Also, show me a single registrar that actually gaurantees their service. Almost every registrar has boilerplate user agreements that shafts the domain owner in the event of any failure, even if the registrar screws it up. I'm not talking about some standard protection against user errors or identidy theft, I'm talking about a genuine 'If our service breaks, you get to keep both halves.' Would you use a registrar with these terms of service? I bet you do. Would you use them if you had a choice? I bet you wouldn't. "Because certain states do not permit the limitation of elimination of liability for certain types of damage, $registrar's liability shall be limited to the smallest amount permitted by law. $registrar disclaims any loss or liability resulting from: 1. access delays or interruptions to our web site or domain name registration system; 3. events beyond our control (i.e. acts of God); 4. the loss of registration or processing of a domain name or the use of a domain name; 5. the failure for whatever reason to renew a domain name registration; 7. errors, omissions or misstatements; 8. deletion of, failure to store, or failure to process or act upon email messages; 9. processing of updated information to Your registration record; 11. errors taking place with regard to the processing of Your application;" I pulled a couple of lines out because they were things that I felt a registrar might actually be indemnified, in the event of, but seriously. How does an entire class of business truly serve the consumer with these kinds of policies? reg??is??trar 1. a person who keeps a record; an official recorder. 2. an agent of a bank, trust company, or other corporation who is responsible for certifying and registering issues of securities. Except for domain registrars, who are only really a registrar when they make a mistake that could cost your entire commercial enterprise. I'll be the first to admit there's been progress made on the front of preventing domain theft and other shenanigans, but when it comes down to it, running a domain registry doesn't seem to be in the best interests of the primary consumers of such a product. - billn From billn at billn.net Fri Jun 27 17:34:29 2008 From: billn at billn.net (Bill Nash) Date: Fri, 27 Jun 2008 15:34:29 -0700 (MST) Subject: what problem are we solving? (was Re: ICANN opens up Pandora's Box of new TLDs) In-Reply-To: References: <171423de0806271024h73e9a181t1df338aa5fe84ef5@mail.gmail.com> <4D0B482D-8FD5-48A5-9FF6-C2011AA7ACB5@virtualized.org> Message-ID: On Fri, 27 Jun 2008, Bill Nash wrote: > Except for domain registrars, who are only really a registrar when they make > a mistake that could cost your entire commercial enterprise. Edit: s/when/until/ Beer:30. - billn From drc at virtualized.org Fri Jun 27 18:06:15 2008 From: drc at virtualized.org (David Conrad) Date: Fri, 27 Jun 2008 16:06:15 -0700 Subject: what problem are we solving? (was Re: ICANN opens up Pandora's Box of new TLDs) In-Reply-To: References: <171423de0806271024h73e9a181t1df338aa5fe84ef5@mail.gmail.com> <4D0B482D-8FD5-48A5-9FF6-C2011AA7ACB5@virtualized.org> Message-ID: On Jun 27, 2008, at 3:30 PM, Bill Nash wrote: >> On Jun 27, 2008, at 10:57 AM, Bill Nash wrote: >> >> Out of curiosity, what are the problems you feel ICANN should be >> spending its time on? > For starters, has Verisign ever been sanctioned by ICANN for it's > business practices, You mean like Sitefinder? > with stupid stuff occurring as late as what, this past February (the > front running debacle)? I suspect you've confused VeriSign with Network Solutions here (and I can't comment on the NetSol stuff because ICANN was named in a lawsuit on the topic). > If ICANN is supposed to be encouraging competition, et cetera, why > is Verisign still in business? Well, for one reason, people continue to register their names in (say) .NET... (:-)). > Also, show me a single registrar that actually gaurantees their > service. > [concerns about registrars] You have commented on the revision to the Registrar Accreditation Agreement (http://www.icann.org/topics/raa/) I presume? > How does an entire class of business truly serve the consumer with > these kinds of policies? Read a software EULA recently? With that said, personally, I agree that more attention should be spent on the welfare of the registrants. Unfortunately, given I work for ICANN, my providing comments in the RAA public consultation along those lines would be a bit ... awkward. > I'll be the first to admit there's been progress made on the front > of preventing domain theft and other shenanigans, but when it comes > down to it, running a domain registry doesn't seem to be in the best > interests of the primary consumers of such a product. I'm not sure I follow this (did you mean registrar?), but I suspect it depends on the registry. So, other than slapping VeriSign and making registrars liable for more stuff, what should ICANN be spending its time on? This is a serious question (not saying I can fix anything, but I can push internally). One of the personally frustrating things about ICANN processes is the lack of input from the network operations community. One of the reasons I'm spamming the NANOG list is to try to stir up folks from this community to actually participate in ICANN processes because, as should be apparent, it actually does matter... Regards, -drc (speaking only for myself) From xploitable at gmail.com Fri Jun 27 18:09:25 2008 From: xploitable at gmail.com (n3td3v) Date: Sat, 28 Jun 2008 00:09:25 +0100 Subject: Fwd: NYC - possible power/utility outages on the horizon In-Reply-To: <4b6ee9310806271548j75e338b6v707d4645b2462811@mail.gmail.com> References: <014a01c8d89b$23d12a20$0400a8c0@LaptopHal> <992ef2a4-eeee-4703-9255-557efe3d74db@e39g2000hsf.googlegroups.com> <4b6ee9310806271548j75e338b6v707d4645b2462811@mail.gmail.com> Message-ID: <4b6ee9310806271609vd64c64fs76e9667f2cde9b7f@mail.gmail.com> ---------- Forwarded message ---------- From: n3td3v Date: Fri, Jun 27, 2008 at 11:48 PM Subject: Fwd: NYC - possible power/utility outages on the horizon To: nanog at merit.edu, full-disclosure at lists.grok.org.uk ---------- Forwarded message ---------- From: cybersec Date: Fri, Jun 27, 2008 at 11:04 PM Subject: Fwd: NYC - possible power/utility outages on the horizon To: n3td3v ---------- Forwarded message ---------- From: Hal Newman Date: Jun 27, 10:17 pm Subject: NYC - possible power/utility outages on the horizon To: CrisisAlert A union that represents thousands of Con Edison employees voted to go on strike at 12:01 AM on June 29. The union and Con Ed are currently in negotiations. The strike would span all Con Ed commodities: gas, electric, and steam. The potential major consequence of the strike to the city is longer response times for repairs. The last Con Ed strike was in 1983 and lasted for nine weeks. Also, another union that represents some 15,000 New York City Verizon employees may go on strike at 12:01 AM on August 3. The union and Verizon are currently in negotiations. The strike would include Verizon telecom only (i.e. landlines) and not Verizon wireless. Verizon may bring in workers from across the U.S. if needed, but all non-essential work will stop and there may be a delayed response time for repairs. The last Verizon strike was in 2003 and lasted for three weeks. From xploitable at gmail.com Fri Jun 27 17:48:01 2008 From: xploitable at gmail.com (n3td3v) Date: Fri, 27 Jun 2008 23:48:01 +0100 Subject: Fwd: NYC - possible power/utility outages on the horizon In-Reply-To: <992ef2a4-eeee-4703-9255-557efe3d74db@e39g2000hsf.googlegroups.com> References: <014a01c8d89b$23d12a20$0400a8c0@LaptopHal> <992ef2a4-eeee-4703-9255-557efe3d74db@e39g2000hsf.googlegroups.com> Message-ID: <4b6ee9310806271548j75e338b6v707d4645b2462811@mail.gmail.com> ---------- Forwarded message ---------- From: cybersec Date: Fri, Jun 27, 2008 at 11:04 PM Subject: Fwd: NYC - possible power/utility outages on the horizon To: n3td3v ---------- Forwarded message ---------- From: Hal Newman Date: Jun 27, 10:17 pm Subject: NYC - possible power/utility outages on the horizon To: CrisisAlert A union that represents thousands of Con Edison employees voted to go on strike at 12:01 AM on June 29. The union and Con Ed are currently in negotiations. The strike would span all Con Ed commodities: gas, electric, and steam. The potential major consequence of the strike to the city is longer response times for repairs. The last Con Ed strike was in 1983 and lasted for nine weeks. Also, another union that represents some 15,000 New York City Verizon employees may go on strike at 12:01 AM on August 3. The union and Verizon are currently in negotiations. The strike would include Verizon telecom only (i.e. landlines) and not Verizon wireless. Verizon may bring in workers from across the U.S. if needed, but all non-essential work will stop and there may be a delayed response time for repairs. The last Verizon strike was in 2003 and lasted for three weeks. From randy at psg.com Fri Jun 27 18:41:28 2008 From: randy at psg.com (Randy Bush) Date: Sat, 28 Jun 2008 08:41:28 +0900 Subject: ICANN opens up Pandora's Box of new TLDs In-Reply-To: References: <20080627120549.32616.qmail@simone.iecc.com> Message-ID: <48657AA8.9000005@psg.com> >> already safely ignore anything with a .name, .biz, .info, .tv suffix, to >> name just the worst. > Does this actually work? The vast majority of spam I receive has an > origin that doesn't reverse map. Of those messages that have origins > (as extracted from the appropriate Received header) that do reverse map, > the majority are in com and net. this is analogous to the gossip that most spam comes from china, asia, nigeria, or whomever we like to be xenophobic or racist about this week. measurement shows the united states to be the largest single source of spam. randy From mehmet at icann.org Fri Jun 27 19:22:22 2008 From: mehmet at icann.org (Mehmet Akcin) Date: Fri, 27 Jun 2008 17:22:22 -0700 Subject: Anyone from Qwest? Message-ID: Anyone from Qwest senior sales team or VP can please contact me offlist? Thank you Mehmet -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2228 bytes Desc: not available URL: From nanog at shankland.org Fri Jun 27 20:11:58 2008 From: nanog at shankland.org (Jim Shankland) Date: Fri, 27 Jun 2008 18:11:58 -0700 Subject: ICANN opens up Pandora's Box of new TLDs In-Reply-To: <48657AA8.9000005@psg.com> References: <20080627120549.32616.qmail@simone.iecc.com> <48657AA8.9000005@psg.com> Message-ID: <48658FDE.8040400@shankland.org> Randy Bush wrote: > this is analogous to the gossip that most spam comes from china, asia, > nigeria, or whomever we like to be xenophobic or racist about this week. > measurement shows the united states to be the largest single source of spam. Because it's Friday, I checked the last few weeks or so of logs from my personal mail server (located in the US), and broke the list of unique IP addresses rejected by zen.spamhaus.org up by registry: 49.2% RIPE 22.2% LACNIC 13.8% ARIN 13.5% APNIC 1.3% Afrinic ARIN's share may be slightly overstated, as it includes most of the legacy blocks. For what it's worth .... Jim Shankland From jfmezei at vaxination.ca Fri Jun 27 20:11:46 2008 From: jfmezei at vaxination.ca (=?ISO-8859-1?Q?Jean-Fran=E7ois_Mezei?=) Date: Fri, 27 Jun 2008 21:11:46 -0400 Subject: what problem are we solving? (was Re: ICANN opens up Pandora's Box of new TLDs) In-Reply-To: <5940.1214601300@turing-police.cc.vt.edu> References: <171423de0806271024h73e9a181t1df338aa5fe84ef5@mail.gmail.com> <486555D3.7090107@vaxination.ca> <5940.1214601300@turing-police.cc.vt.edu> Message-ID: <48658FD2.2070000@vaxination.ca> While doing the groceries, I got to think about this issue. There have been complaints in the past about difficulty in getting new legitimate TLDs approved by ICANN. (image of ICANN being too USA centric etc etc etc). So I understand a move towards a more documented and "logical" process to get new .TLDs approved adn setup. Right now, whethere real or not, there is an image that the .TLDs have been vetted and are operated by reputable people and used for legitimate purposes. (yeah, that image might be tarnished in some circles). But my uneducated opinion is that this current project appears to let the .TLD loose and this will result in top level domains being meaningless, without any trust. There should have been an evolution from a tightly controlled small set of TLDs towards alowly growing set of TLDs done fairly and openly. Going whole hog on auctioning anything and everything is a bit too much fo a revolution in my opinion. The way I see it from quick read, by default you can get anything registered as a .TLD unless someone else justifies why you shouldn't get it, or if it is truly obscene. There should have be a "in between" where people still have to justify a new .TLD and only allow TLDs that are generic and allow many different entities to participate. (as opposed to using a private trademark as a .TLD where only one company can participate). From frnkblk at iname.com Fri Jun 27 20:30:15 2008 From: frnkblk at iname.com (Frank Bulk - iNAME) Date: Fri, 27 Jun 2008 20:30:15 -0500 Subject: Possible explanations for a large hop in latency In-Reply-To: References: Message-ID: Just to close this issue on the list: a (top) engineer from AT&T contacted me offline and helped us out. Turns out that 12.88.71.13 is located in Kansas City and tbr1.sl9mo.ip.att.net (12.122.112.22) is in St. Louis. AT&T has two L1 connections to that site for redundancy, but traffic was flowing over the longer loop. The engineer tweaked route weights so that the traffic prefers to flow over the shorter link to tbr2.sl9mo.ip.att.net (12.122.112.78), shaving about 12 msec. He also explained that the jump of ~70 msec is due to how ICMP traffic within MPLS tunnels is handled. It wasn't until I ran a traceroute from a Cisco router that I even saw the MPLS labels (that included in the ICMP responses) for each of the hops within the tunnel. Apparently each ICMP packet within an MPLS tunnel (where TTL decrementing is allowed) is sent to the *end* of the tunnel and back again, so my next "hop" to tbr1.sl9mo.ip.att.net (12.122.112.22) was really showing the RTT to the end of the tunnel, Los Angeles. Frank -----Original Message----- From: Frank Bulk [mailto:frnkblk at iname.com] Sent: Thursday, June 26, 2008 5:52 PM To: nanog list Subject: Possible explanations for a large hop in latency Our upstream provider has a connection to AT&T (12.88.71.13) where I relatively consistently measure with a RTT of 15 msec, but the next hop (12.122.112.22) comes in with a RTT of 85 msec. Unless AT&T is sending that traffic over a cable modem or to Europe and back, I can't see a reason why there is a consistent ~70 msec jump in RTT. Hops farther along the route are just a few msec more each hop, so it doesn't appear that 12.122.112.22 has some kind of ICMP rate-limiting. Is this a real performance issue, or is there some logical explanation? Frank From morrowc.lists at gmail.com Fri Jun 27 21:22:52 2008 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 27 Jun 2008 22:22:52 -0400 Subject: ICANN opens up Pandora's Box of new TLDs In-Reply-To: <20080627203205.51B612B7C02@mx5.roble.com> References: <20080627203205.51B612B7C02@mx5.roble.com> Message-ID: <75cb24520806271922w19d43c23y2b33c28b315ae877@mail.gmail.com> On Fri, Jun 27, 2008 at 4:32 PM, Roger Marquis wrote: > Phil Regnauld wrote: > apply even cursory tests for domain name validity. Phishers and spammers > will have a field day with the inevitable namespace collisions. It is, > however, unfortunately consistent with ICANN's inability to address other > security issues such as fast flush DNS, domain tasting (botnets), and > requiring valid domain contacts. > Please do not conflate: 1) Fast flux 2) Botnets 3) Domain tasting 4) valid contact info These are separate and distinct issues... I'd point out that FastFlux is actually sort of how Akamai does it's job (inconsistent dns responses), Double-Flux (at least the traditional DF) isn't though certainly Akamai COULD do something similar to Double-Flux (and arguably does with some bits their services. The particular form 'Double-Flux' is certainly troublesome, but arguably TOS/AUP info at Registrars already deals with most of this because #4 in your list would apply... That or use of the domain for clearly illicit ends. Also, perhaps just not having Registrar's that solely deal in criminal activities would make this harder to accomplish... Botnets clearly are bad... I'm not sure they are related to ICANN in any real way though, so that seems like a red herring in the discussion. Domain tasting has solutions on the table (thanks drc for linkages) but was a side effect of some customer-satisfaction/buyers-remorse loopholes placed in the regs... the fact that someone figured out that computers could be used to take advantage of that loophole on a massive scale isn't super surprising. In the end though, it's getting fixed, perhaps slower than we'd all prefer, but still. > I have to conclude that ICANN has failed, simply failed, and should be > returned to the US government. Perhaps the DHL would at least solicit for > RFCs from the security community. I'm not sure a shipping company really is the best place to solicit... or did you mean DHS? and why on gods green earth would you want them involved with this? -chris From marquis at roble.com Fri Jun 27 22:11:39 2008 From: marquis at roble.com (Roger Marquis) Date: Fri, 27 Jun 2008 20:11:39 -0700 (PDT) Subject: ICANN opens up Pandora's Box of new TLDs In-Reply-To: <75cb24520806271922w19d43c23y2b33c28b315ae877@mail.gmail.com> References: <20080627203205.51B612B7C02@mx5.roble.com> <75cb24520806271922w19d43c23y2b33c28b315ae877@mail.gmail.com> Message-ID: <20080628031139.8D0BB2B7C04@mx5.roble.com> On Fri, 27 Jun 2008, Christopher Morrow wrote: > 1) Fast flux 2) Botnets 3) Domain tasting 4) valid contact info > These are separate and distinct issues... They are separate but also linked by being issues that only be addressed at the registrar level, through TOS. Since some registrars have a financial incentive not to address these issues, in practice, they can be implemented only by ICANN policy (mandated much like the domain refund period). > I'd point out that FastFlux is actually sort of how Akamai does > it's job (inconsistent dns responses) That's not really fast flux. FF uses TTLs of just a few seconds with dozens of NS. Also, in practice, most FF NS are invalid. Not that FF has a fixed definition... > Domain tasting has solutions on the table (thanks drc for > linkages) but was a side effect of some > customer-satisfaction/buyers-remorse loopholes placed in the > regs... The domain tasting policy was, if I recall, intended to address buyers of one to a few domains, not thousands. Would be a simple matter to fix, in a functional organization. > I'm not sure a shipping company really is the best place to > solicit... or did you mean DHS? and why on gods green earth > would you want them involved with this? Yes, sorry, DHS. :-) At least they are sensitive to security matters and would, in theory, not be as easily influenced by politics as was the NSF. Roger Marquis From tomb at byrneit.net Fri Jun 27 22:13:51 2008 From: tomb at byrneit.net (Tomas L. Byrnes) Date: Fri, 27 Jun 2008 20:13:51 -0700 Subject: ICANN opens up Pandora's Box of new TLDs In-Reply-To: <75cb24520806271922w19d43c23y2b33c28b315ae877@mail.gmail.com> References: <20080627203205.51B612B7C02@mx5.roble.com> <75cb24520806271922w19d43c23y2b33c28b315ae877@mail.gmail.com> Message-ID: <70D072392E56884193E3D2DE09C097A9F2A4@pascal.zaphodb.org> These issues are not separate and distinct, but rather related. A graduated level of analysis of membership in any of the sets of: 1: Recently registered domain. 2: Short TTL 3: Appearance in DShield, Shadowserver, Cyber-TA and other sensor lists. 4: Invalid/Non-responsive RP info in Whois Create a pretty good profile of someone you probably don't want to accept traffic from. Conflation is bad, recognizing that each metric has value, and some correlation of membership in more than one set has even more value, as indicating a likely criminal node, is good. YMMV. I guess, if you have perfect malware signatures, code with no errors, and vigilance the Marines on the wire @ gitmo would envy, you can accept traffic from everywhere. > -----Original Message----- > From: Christopher Morrow [mailto:morrowc.lists at gmail.com] > Sent: Friday, June 27, 2008 7:23 PM > To: Roger Marquis > Cc: nanog at nanog.org > Subject: Re: ICANN opens up Pandora's Box of new TLDs > > On Fri, Jun 27, 2008 at 4:32 PM, Roger Marquis > wrote: > > Phil Regnauld wrote: > > apply even cursory tests for domain name validity. Phishers and > > spammers will have a field day with the inevitable namespace > > collisions. It is, however, unfortunately consistent with ICANN's > > inability to address other security issues such as fast flush DNS, > > domain tasting (botnets), and requiring valid domain contacts. > > > > Please do not conflate: > > 1) Fast flux > 2) Botnets > 3) Domain tasting > 4) valid contact info > > These are separate and distinct issues... I'd point out that > FastFlux is actually sort of how Akamai does it's job > (inconsistent dns responses), Double-Flux (at least the > traditional DF) isn't though certainly Akamai COULD do > something similar to Double-Flux (and arguably does with some > bits their services. The particular form 'Double-Flux' is > certainly troublesome, but arguably TOS/AUP info at > Registrars already deals with most of this because #4 in your > list would apply... That or use of the domain for clearly > illicit ends. > Also, perhaps just not having Registrar's that solely deal in > criminal activities would make this harder to accomplish... > > Botnets clearly are bad... I'm not sure they are related to > ICANN in any real way though, so that seems like a red > herring in the discussion. > > Domain tasting has solutions on the table (thanks drc for > linkages) but was a side effect of some > customer-satisfaction/buyers-remorse > loopholes placed in the regs... the fact that someone figured > out that computers could be used to take advantage of that > loophole on a massive scale isn't super surprising. In the > end though, it's getting fixed, perhaps slower than we'd all > prefer, but still. > > > I have to conclude that ICANN has failed, simply failed, > and should be > > returned to the US government. Perhaps the DHL would at > least solicit > > for RFCs from the security community. > > I'm not sure a shipping company really is the best place to solicit... > or did you mean DHS? and why on gods green earth would you > want them involved with this? > > -chris > > From ge at linuxbox.org Fri Jun 27 22:31:51 2008 From: ge at linuxbox.org (Gadi Evron) Date: Fri, 27 Jun 2008 22:31:51 -0500 (CDT) Subject: security relevance [was: ICANN opens up Pandora's Box of new TLDs] In-Reply-To: <20080628031139.8D0BB2B7C04@mx5.roble.com> References: <20080627203205.51B612B7C02@mx5.roble.com> <75cb24520806271922w19d43c23y2b33c28b315ae877@mail.gmail.com> <20080628031139.8D0BB2B7C04@mx5.roble.com> Message-ID: On Fri, 27 Jun 2008, Roger Marquis wrote: > On Fri, 27 Jun 2008, Christopher Morrow wrote: >> 1) Fast flux 2) Botnets 3) Domain tasting 4) valid contact info >> These are separate and distinct issues... > > They are separate but also linked by being issues that only be addressed at > the registrar level, through TOS. Since some registrars have a financial > incentive not to address these issues, in practice, they can be implemented > only by ICANN policy (mandated much like the domain refund period). These issues can be addressed, from a defensive standpoint alone, at: 1. The root 2. TLDs (the servers) 3. TLDs (registries) 4. Registrars 5. ISPs NS 6. Home, end-user The ability, sanity, cost and effectiveness are the main factors deciding what is to be done. Does anyone want a domain blocked at the TLD server under even extreme conditions? I do, but the situation would have to be *really* extreme, which I have only seen few of in the last 10 years. Registries have a high level of importance to this fight, especially if they are to make sure their business is not mostly criminally used--if they care. Registrars are far more closer to the fight, but with less potential impact--if they care, and we know some do. Others however are built to begin with as criminal havens. >> I'd point out that FastFlux is actually sort of how Akamai does >> it's job (inconsistent dns responses) > > That's not really fast flux. FF uses TTLs of just a few seconds with > dozens of NS. Also, in practice, most FF NS are invalid. Not that FF has > a fixed definition... You are both right. FF is a concept. I should know, having been the bastard to expose it to the public and thus getting it the defensive attention it needed--and wide(er) exploitation (I am not the one who found out it exists, that was someone who shall remain anonymous). The TTL is what is mainly abused. Then it went to the NS level, and I see no problem with NSs simply returning different answers with every query. I believe it has in fact been done before by the criminals. >> Domain tasting has solutions on the table (thanks drc for >> linkages) but was a side effect of some >> customer-satisfaction/buyers-remorse loopholes placed in the >> regs... > > The domain tasting policy was, if I recall, intended to address buyers of > one to a few domains, not thousands. Would be a simple matter to fix, in a > functional organization. >From a security standpoint.. But what it actually does is allow a criminal to register a domain, use it and dump it. Kind of like a jerk picking up a girl at a pub, if an analogy is easier for us to use. The main difference being domains don't get hurt, they just get replaced. The only difference using tasting when replacing domains is that when bought with a fake credit card (which has no practical effect on how the criminals do business) the registrars need to handle it, and that costs money. The second, far more recongnized abuse, is financial and has to do with some registrars operational practices, and/or being somewhere between sound businesses to bastards, which is beyond the scope of this post. >> I'm not sure a shipping company really is the best place to >> solicit... or did you mean DHS? and why on gods green earth >> would you want them involved with this? > > Yes, sorry, DHS. :-) At least they are sensitive to security matters and > would, in theory, not be as easily influenced by politics as was the NSF. You must be joking. > Roger Marquis Gadi. From ge at linuxbox.org Fri Jun 27 22:33:08 2008 From: ge at linuxbox.org (Gadi Evron) Date: Fri, 27 Jun 2008 22:33:08 -0500 (CDT) Subject: ICANN opens up Pandora's Box of new TLDs In-Reply-To: <70D072392E56884193E3D2DE09C097A9F2A4@pascal.zaphodb.org> References: <20080627203205.51B612B7C02@mx5.roble.com> <75cb24520806271922w19d43c23y2b33c28b315ae877@mail.gmail.com> <70D072392E56884193E3D2DE09C097A9F2A4@pascal.zaphodb.org> Message-ID: On Fri, 27 Jun 2008, Tomas L. Byrnes wrote: > These issues are not separate and distinct, but rather related. > > A graduated level of analysis of membership in any of the sets of: > > 1: Recently registered domain. > > 2: Short TTL > > 3: Appearance in DShield, Shadowserver, Cyber-TA and other sensor lists. > > 4: Invalid/Non-responsive RP info in Whois > > Create a pretty good profile of someone you probably don't want to > accept traffic from. > > Conflation is bad, recognizing that each metric has value, and some > correlation of membership in more than one set has even more value, as > indicating a likely criminal node, is good. > > YMMV. > > I guess, if you have perfect malware signatures, code with no errors, > and vigilance the Marines on the wire @ gitmo would envy, you can accept > traffic from everywhere. Not quite, because you still won't know who to send the Marines to kill. The Internet is perfect for plausible deniability. Gadi. > > > >> -----Original Message----- >> From: Christopher Morrow [mailto:morrowc.lists at gmail.com] >> Sent: Friday, June 27, 2008 7:23 PM >> To: Roger Marquis >> Cc: nanog at nanog.org >> Subject: Re: ICANN opens up Pandora's Box of new TLDs >> >> On Fri, Jun 27, 2008 at 4:32 PM, Roger Marquis >> wrote: >>> Phil Regnauld wrote: >>> apply even cursory tests for domain name validity. Phishers and >>> spammers will have a field day with the inevitable namespace >>> collisions. It is, however, unfortunately consistent with ICANN's >>> inability to address other security issues such as fast flush DNS, >>> domain tasting (botnets), and requiring valid domain contacts. >>> >> >> Please do not conflate: >> >> 1) Fast flux >> 2) Botnets >> 3) Domain tasting >> 4) valid contact info >> >> These are separate and distinct issues... I'd point out that >> FastFlux is actually sort of how Akamai does it's job >> (inconsistent dns responses), Double-Flux (at least the >> traditional DF) isn't though certainly Akamai COULD do >> something similar to Double-Flux (and arguably does with some >> bits their services. The particular form 'Double-Flux' is >> certainly troublesome, but arguably TOS/AUP info at >> Registrars already deals with most of this because #4 in your >> list would apply... That or use of the domain for clearly >> illicit ends. >> Also, perhaps just not having Registrar's that solely deal in >> criminal activities would make this harder to accomplish... >> >> Botnets clearly are bad... I'm not sure they are related to >> ICANN in any real way though, so that seems like a red >> herring in the discussion. >> >> Domain tasting has solutions on the table (thanks drc for >> linkages) but was a side effect of some >> customer-satisfaction/buyers-remorse >> loopholes placed in the regs... the fact that someone figured >> out that computers could be used to take advantage of that >> loophole on a massive scale isn't super surprising. In the >> end though, it's getting fixed, perhaps slower than we'd all >> prefer, but still. >> >>> I have to conclude that ICANN has failed, simply failed, >> and should be >>> returned to the US government. Perhaps the DHL would at >> least solicit >>> for RFCs from the security community. >> >> I'm not sure a shipping company really is the best place to solicit... >> or did you mean DHS? and why on gods green earth would you >> want them involved with this? >> >> -chris >> >> > > From joly at punkcast.com Fri Jun 27 22:59:52 2008 From: joly at punkcast.com (WWWhatsup) Date: Fri, 27 Jun 2008 23:59:52 -0400 Subject: what problem are we solving? (was Re: ICANN opens up Pandora's Box of new TLDs) In-Reply-To: References: <171423de0806271024h73e9a181t1df338aa5fe84ef5@mail.gmail.com> <4D0B482D-8FD5-48A5-9FF6-C2011AA7ACB5@virtualized.org> Message-ID: <20080628035954.BC78F213C3@spunkymail-a9.g.dreamhost.com> David Conrad wrote: >With that said, personally, I agree that more attention should be >spent on the welfare of the registrants. Unfortunately, given I work >for ICANN, my providing comments in the RAA public consultation along >those lines would be a bit ... awkward. Would you agree with Danny Younger (I believe this is his position) then that there should be a properly constituted & recognized registrants constituency? joly --------------------------------------------------------------- WWWhatsup NYC http://pinstand.com - http://punkcast.com --------------------------------------------------------------- From morrowc.lists at gmail.com Fri Jun 27 23:19:31 2008 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Sat, 28 Jun 2008 00:19:31 -0400 Subject: ICANN opens up Pandora's Box of new TLDs In-Reply-To: <70D072392E56884193E3D2DE09C097A9F2A4@pascal.zaphodb.org> References: <20080627203205.51B612B7C02@mx5.roble.com> <75cb24520806271922w19d43c23y2b33c28b315ae877@mail.gmail.com> <70D072392E56884193E3D2DE09C097A9F2A4@pascal.zaphodb.org> Message-ID: <75cb24520806272119x602e884eve4058f3bc92c6836@mail.gmail.com> On Fri, Jun 27, 2008 at 11:13 PM, Tomas L. Byrnes wrote: > These issues are not separate and distinct, but rather related. > > A graduated level of analysis of membership in any of the sets of: > > 1: Recently registered domain. > hi, I just registered 'newproduct.com' for my press release, I'm sending you emails from that domain since you signed up with my company for new news alerts abotu my great products! > 2: Short TTL > I'm anticipating high traffic loads, I'm putting my pressrelease things on akamai/llnw, I want to shift that away quickly when traffic levels decrease. I made my ttl's short, for that, plus akamai sets my ttl's on their responses to 5mins. > 3: Appearance in DShield, Shadowserver, Cyber-TA and other sensor lists. > sure, these are fine folks... they get things wring at times :( > 4: Invalid/Non-responsive RP info in Whois > oh, whois isn't updated with NS info updates... so for 6-12 hours that data's not going to reflect 'valid' info while I send out my notifications. > Create a pretty good profile of someone you probably don't want to > accept traffic from. > I agree that correlation across many forms of intell gathering is good, and probably the way out for folks on the good side of this battle. My point was that tossing FUD on top of the 'icann made a mistake, maybe' isn't helping the argument nor discussion. There should be some work, and maybe there is work happening on this, done to bring ICANN policies up to speed with respect to dealing with: 1) domain owners who have invalid (chronically bad) info 2) registrars who seem to solely > Conflation is bad, recognizing that each metric has value, and some > correlation of membership in more than one set has even more value, as > indicating a likely criminal node, is good. > > YMMV. > > I guess, if you have perfect malware signatures, code with no errors, > and vigilance the Marines on the wire @ gitmo would envy, you can accept > traffic from everywhere. > > > >> -----Original Message----- >> From: Christopher Morrow [mailto:morrowc.lists at gmail.com] >> Sent: Friday, June 27, 2008 7:23 PM >> To: Roger Marquis >> Cc: nanog at nanog.org >> Subject: Re: ICANN opens up Pandora's Box of new TLDs >> >> On Fri, Jun 27, 2008 at 4:32 PM, Roger Marquis >> wrote: >> > Phil Regnauld wrote: >> > apply even cursory tests for domain name validity. Phishers and >> > spammers will have a field day with the inevitable namespace >> > collisions. It is, however, unfortunately consistent with ICANN's >> > inability to address other security issues such as fast flush DNS, >> > domain tasting (botnets), and requiring valid domain contacts. >> > >> >> Please do not conflate: >> >> 1) Fast flux >> 2) Botnets >> 3) Domain tasting >> 4) valid contact info >> >> These are separate and distinct issues... I'd point out that >> FastFlux is actually sort of how Akamai does it's job >> (inconsistent dns responses), Double-Flux (at least the >> traditional DF) isn't though certainly Akamai COULD do >> something similar to Double-Flux (and arguably does with some >> bits their services. The particular form 'Double-Flux' is >> certainly troublesome, but arguably TOS/AUP info at >> Registrars already deals with most of this because #4 in your >> list would apply... That or use of the domain for clearly >> illicit ends. >> Also, perhaps just not having Registrar's that solely deal in >> criminal activities would make this harder to accomplish... >> >> Botnets clearly are bad... I'm not sure they are related to >> ICANN in any real way though, so that seems like a red >> herring in the discussion. >> >> Domain tasting has solutions on the table (thanks drc for >> linkages) but was a side effect of some >> customer-satisfaction/buyers-remorse >> loopholes placed in the regs... the fact that someone figured >> out that computers could be used to take advantage of that >> loophole on a massive scale isn't super surprising. In the >> end though, it's getting fixed, perhaps slower than we'd all >> prefer, but still. >> >> > I have to conclude that ICANN has failed, simply failed, >> and should be >> > returned to the US government. Perhaps the DHL would at >> least solicit >> > for RFCs from the security community. >> >> I'm not sure a shipping company really is the best place to solicit... >> or did you mean DHS? and why on gods green earth would you >> want them involved with this? >> >> -chris >> >> > From morrowc.lists at gmail.com Fri Jun 27 23:22:27 2008 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Sat, 28 Jun 2008 00:22:27 -0400 Subject: ICANN opens up Pandora's Box of new TLDs In-Reply-To: <75cb24520806272119x602e884eve4058f3bc92c6836@mail.gmail.com> References: <20080627203205.51B612B7C02@mx5.roble.com> <75cb24520806271922w19d43c23y2b33c28b315ae877@mail.gmail.com> <70D072392E56884193E3D2DE09C097A9F2A4@pascal.zaphodb.org> <75cb24520806272119x602e884eve4058f3bc92c6836@mail.gmail.com> Message-ID: <75cb24520806272122h6dabe67cya0115ef61cd31bc@mail.gmail.com> (picking up where I ejected on the email...argh) On Sat, Jun 28, 2008 at 12:19 AM, Christopher Morrow wrote: > On Fri, Jun 27, 2008 at 11:13 PM, Tomas L. Byrnes wrote: >> These issues are not separate and distinct, but rather related. >> >> A graduated level of analysis of membership in any of the sets of: >> >> 1: Recently registered domain. >> > > hi, I just registered 'newproduct.com' for my press release, I'm > sending you emails from that domain since you signed up with my > company for new news alerts abotu my great products! > >> 2: Short TTL >> > > I'm anticipating high traffic loads, I'm putting my pressrelease > things on akamai/llnw, I want to shift that away quickly when traffic > levels decrease. I made my ttl's short, for that, plus akamai sets my > ttl's on their responses to 5mins. > >> 3: Appearance in DShield, Shadowserver, Cyber-TA and other sensor lists. >> > > sure, these are fine folks... they get things wring at times :( > >> 4: Invalid/Non-responsive RP info in Whois >> > > oh, whois isn't updated with NS info updates... so for 6-12 hours that > data's not going to reflect 'valid' info while I send out my > notifications. > >> Create a pretty good profile of someone you probably don't want to >> accept traffic from. >> > > I agree that correlation across many forms of intell gathering is > good, and probably the way out for folks on the good side of this > battle. My point was that tossing FUD on top of the 'icann made a > mistake, maybe' isn't helping the argument nor discussion. > > There should be some work, and maybe there is work happening on this, > done to bring ICANN policies up to speed with respect to dealing with: > 1) domain owners who have invalid (chronically bad) info > 2) registrars who seem to solely solely registering bad/criminal/abusive domains... -chris From morrowc.lists at gmail.com Fri Jun 27 23:31:25 2008 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Sat, 28 Jun 2008 00:31:25 -0400 Subject: ICANN opens up Pandora's Box of new TLDs In-Reply-To: <20080628031139.8D0BB2B7C04@mx5.roble.com> References: <20080627203205.51B612B7C02@mx5.roble.com> <75cb24520806271922w19d43c23y2b33c28b315ae877@mail.gmail.com> <20080628031139.8D0BB2B7C04@mx5.roble.com> Message-ID: <75cb24520806272131n67897038n5706ba0289004235@mail.gmail.com> On Fri, Jun 27, 2008 at 11:11 PM, Roger Marquis wrote: > On Fri, 27 Jun 2008, Christopher Morrow wrote: >> >> I'd point out that FastFlux is actually sort of how Akamai does >> it's job (inconsistent dns responses) > > That's not really fast flux. FF uses TTLs of just a few seconds with > dozens of NS. Also, in practice, most FF NS are invalid. Not that FF has > a fixed definition... > ;; ANSWER SECTION: www.yahoo.com. 24 IN CNAME www.yahoo-ht3.akadns.net. www.yahoo-ht3.akadns.net. 57 IN A 69.147.76.15 akamai, 60 second TTL's... most of the FF things I've seen sit around 300seconds for NS and for A records. either way, this is 60 seconds which is fast enough. http://en.wikipedia.org/wiki/Fast_flux that goes fairly well to what I was referencing as FF and Double-Flux. >> Domain tasting has solutions on the table (thanks drc for >> linkages) but was a side effect of some >> customer-satisfaction/buyers-remorse loopholes placed in the >> regs... > > The domain tasting policy was, if I recall, intended to address buyers of > one to a few domains, not thousands. Would be a simple matter to fix, in a > functional organization. > sure, policy by committee I think drc made some references to that process. It's taking time :( > Yes, sorry, DHS. :-) At least they are sensitive to security matters and > would, in theory, not be as easily influenced by politics as was the NSF. I'm not sure that a us-focused law/regulatory answer serves 'the tubes' very well. Certainly DHS can help make things useful inside the US-Govt. they may also be able to help advise, but implementation is left to the operators and policy folks in ICANN + registries + registrars. -Chris From ge at linuxbox.org Fri Jun 27 23:34:34 2008 From: ge at linuxbox.org (Gadi Evron) Date: Fri, 27 Jun 2008 23:34:34 -0500 (CDT) Subject: ICANN opens up Pandora's Box of new TLDs In-Reply-To: <75cb24520806272131n67897038n5706ba0289004235@mail.gmail.com> References: <20080627203205.51B612B7C02@mx5.roble.com> <75cb24520806271922w19d43c23y2b33c28b315ae877@mail.gmail.com> <20080628031139.8D0BB2B7C04@mx5.roble.com> <75cb24520806272131n67897038n5706ba0289004235@mail.gmail.com> Message-ID: On Sat, 28 Jun 2008, Christopher Morrow wrote: > On Fri, Jun 27, 2008 at 11:11 PM, Roger Marquis wrote: >> On Fri, 27 Jun 2008, Christopher Morrow wrote: >>> >>> I'd point out that FastFlux is actually sort of how Akamai does >>> it's job (inconsistent dns responses) >> >> That's not really fast flux. FF uses TTLs of just a few seconds with >> dozens of NS. Also, in practice, most FF NS are invalid. Not that FF has >> a fixed definition... >> > > ;; ANSWER SECTION: > www.yahoo.com. 24 IN CNAME www.yahoo-ht3.akadns.net. > www.yahoo-ht3.akadns.net. 57 IN A 69.147.76.15 > > akamai, 60 second TTL's... most of the FF things I've seen sit around > 300seconds for NS and for A records. either way, this is 60 seconds > which is fast enough. Interesting, I was under the impression anything less than 120 is effectively as good as 120. Gadi. From morrowc.lists at gmail.com Fri Jun 27 23:38:35 2008 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Sat, 28 Jun 2008 00:38:35 -0400 Subject: ICANN opens up Pandora's Box of new TLDs In-Reply-To: References: <20080627203205.51B612B7C02@mx5.roble.com> <75cb24520806271922w19d43c23y2b33c28b315ae877@mail.gmail.com> <20080628031139.8D0BB2B7C04@mx5.roble.com> <75cb24520806272131n67897038n5706ba0289004235@mail.gmail.com> Message-ID: <75cb24520806272138r54e08da9q3e8bfd854a756999@mail.gmail.com> On Sat, Jun 28, 2008 at 12:34 AM, Gadi Evron wrote: > On Sat, 28 Jun 2008, Christopher Morrow wrote: >> >> On Fri, Jun 27, 2008 at 11:11 PM, Roger Marquis wrote: >>> >>> On Fri, 27 Jun 2008, Christopher Morrow wrote: >>>> >>>> I'd point out that FastFlux is actually sort of how Akamai does >>>> it's job (inconsistent dns responses) >>> >>> That's not really fast flux. FF uses TTLs of just a few seconds with >>> dozens of NS. Also, in practice, most FF NS are invalid. Not that FF >>> has >>> a fixed definition... >>> >> >> ;; ANSWER SECTION: >> www.yahoo.com. 24 IN CNAME www.yahoo-ht3.akadns.net. >> www.yahoo-ht3.akadns.net. 57 IN A 69.147.76.15 >> >> akamai, 60 second TTL's... most of the FF things I've seen sit around >> 300seconds for NS and for A records. either way, this is 60 seconds >> which is fast enough. > > Interesting, I was under the impression anything less than 120 is > effectively as good as 120. I have not measured... I bet yahoo has though :) and/or Akamai. There's a reason that these folks are doing this. Would be an interesting presentation though eh? -Chris From ge at linuxbox.org Fri Jun 27 23:47:09 2008 From: ge at linuxbox.org (Gadi Evron) Date: Fri, 27 Jun 2008 23:47:09 -0500 (CDT) Subject: TTL settings efficiency [was: ICANN opens up Pandora's Box of new TLDs] In-Reply-To: <75cb24520806272138r54e08da9q3e8bfd854a756999@mail.gmail.com> References: <20080627203205.51B612B7C02@mx5.roble.com> <75cb24520806271922w19d43c23y2b33c28b315ae877@mail.gmail.com> <20080628031139.8D0BB2B7C04@mx5.roble.com> <75cb24520806272131n67897038n5706ba0289004235@mail.gmail.com> <75cb24520806272138r54e08da9q3e8bfd854a756999@mail.gmail.com> Message-ID: On Sat, 28 Jun 2008, Christopher Morrow wrote: > On Sat, Jun 28, 2008 at 12:34 AM, Gadi Evron wrote: >> >> Interesting, I was under the impression anything less than 120 is >> effectively as good as 120. > > I have not measured... I bet yahoo has though :) and/or Akamai. > There's a reason that these folks are doing this. Would be an > interesting presentation though eh? Yep. Any takers? > -Chris > From tomb at byrneit.net Sat Jun 28 00:27:12 2008 From: tomb at byrneit.net (Tomas L. Byrnes) Date: Fri, 27 Jun 2008 22:27:12 -0700 Subject: ICANN opens up Pandora's Box of new TLDs Message-ID: <70D072392E56884193E3D2DE09C097A9F2A8@pascal.zaphodb.org> I just know who should be held for further processing @ the gate. Which is good enough, in this case. "What is the object of defense? Preservation. It is easier to hold ground than take it. . . defense is the stronger form of waging war" Carl Von Clausewitz > -----Original Message----- > From: Gadi Evron [mailto:ge at linuxbox.org] > Sent: Friday, June 27, 2008 8:33 PM > To: Tomas L. Byrnes > Cc: Christopher Morrow; Roger Marquis; nanog at nanog.org > Subject: RE: ICANN opens up Pandora's Box of new TLDs > > On Fri, 27 Jun 2008, Tomas L. Byrnes wrote: > > These issues are not separate and distinct, but rather related. > > > > A graduated level of analysis of membership in any of the sets of: > > > > 1: Recently registered domain. > > > > 2: Short TTL > > > > 3: Appearance in DShield, Shadowserver, Cyber-TA and other > sensor lists. > > > > 4: Invalid/Non-responsive RP info in Whois > > > > Create a pretty good profile of someone you probably don't want to > > accept traffic from. > > > > Conflation is bad, recognizing that each metric has value, and some > > correlation of membership in more than one set has even > more value, as > > indicating a likely criminal node, is good. > > > > YMMV. > > > > I guess, if you have perfect malware signatures, code with > no errors, > > and vigilance the Marines on the wire @ gitmo would envy, you can > > accept traffic from everywhere. > > Not quite, because you still won't know who to send the Marines to > kill. > The Internet is perfect for plausible deniability. > > Gadi. > > > > > > > > >> -----Original Message----- > >> From: Christopher Morrow [mailto:morrowc.lists at gmail.com] > >> Sent: Friday, June 27, 2008 7:23 PM > >> To: Roger Marquis > >> Cc: nanog at nanog.org > >> Subject: Re: ICANN opens up Pandora's Box of new TLDs > >> > >> On Fri, Jun 27, 2008 at 4:32 PM, Roger Marquis > >> wrote: > >>> Phil Regnauld wrote: > >>> apply even cursory tests for domain name validity. Phishers and > >>> spammers will have a field day with the inevitable namespace > >>> collisions. It is, however, unfortunately consistent with ICANN's > >>> inability to address other security issues such as fast > flush DNS, > >>> domain tasting (botnets), and requiring valid domain contacts. > >>> > >> > >> Please do not conflate: > >> > >> 1) Fast flux > >> 2) Botnets > >> 3) Domain tasting > >> 4) valid contact info > >> > >> These are separate and distinct issues... I'd point out > that FastFlux > >> is actually sort of how Akamai does it's job (inconsistent dns > >> responses), Double-Flux (at least the traditional DF) isn't though > >> certainly Akamai COULD do something similar to Double-Flux (and > >> arguably does with some bits their services. The particular form > >> 'Double-Flux' is certainly troublesome, but arguably > TOS/AUP info at > >> Registrars already deals with most of this because #4 in your list > >> would apply... That or use of the domain for clearly illicit ends. > >> Also, perhaps just not having Registrar's that solely deal in > >> criminal activities would make this harder to accomplish... > >> > >> Botnets clearly are bad... I'm not sure they are related > to ICANN in > >> any real way though, so that seems like a red herring in the > >> discussion. > >> > >> Domain tasting has solutions on the table (thanks drc for > >> linkages) but was a side effect of some > >> customer-satisfaction/buyers-remorse > >> loopholes placed in the regs... the fact that someone figured out > >> that computers could be used to take advantage of that > loophole on a > >> massive scale isn't super surprising. In the end though, > it's getting > >> fixed, perhaps slower than we'd all prefer, but still. > >> > >>> I have to conclude that ICANN has failed, simply failed, > >> and should be > >>> returned to the US government. Perhaps the DHL would at > >> least solicit > >>> for RFCs from the security community. > >> > >> I'm not sure a shipping company really is the best place > to solicit... > >> or did you mean DHS? and why on gods green earth would you > want them > >> involved with this? > >> > >> -chris > >> > >> > > > > > From ge at linuxbox.org Sat Jun 28 00:47:05 2008 From: ge at linuxbox.org (Gadi Evron) Date: Sat, 28 Jun 2008 00:47:05 -0500 (CDT) Subject: ICANN opens up Pandora's Box of new TLDs In-Reply-To: <70D072392E56884193E3D2DE09C097A9F2A8@pascal.zaphodb.org> References: <70D072392E56884193E3D2DE09C097A9F2A8@pascal.zaphodb.org> Message-ID: On Fri, 27 Jun 2008, Tomas L. Byrnes wrote: > > I just know who should be held for further processing @ the gate. This is getting off-topic, so let's continue the discussion for a couple more emails to see if we can bring it back on-topic to network operations, and then stop if not? > Which is good enough, in this case. > > "What is the object of defense? Preservation. It is easier to hold > ground than take it. . . defense is the stronger form of waging war" > > Carl Von Clausewitz Which, while valid in many cases, some of them on the Internet, is in most online cases--false. This is a statement by someone much lesser than Clausewitz--me. It is however, an educated opinion, and chronologically up to date. Attack is a much easier form of fighting, online (let's leave war out of it). For the sake of logic I will base this on two discussion points: In security, all you need to attack is one hole, one vulnerability. As a defender you need to defend against everything, anywhere. This is why risk analysis exists, which brings us to another point from Karl-- Changing the words to fit our needs, Clausewitz also believed wars are won by numbers, if you have more you win (Think the American Civil War). Strategy starts when you have less numbers, by where you choose to apply your forces--where it counts. Tying it with the point above is the basics of risk analysis in military terms. In security and information warfare, whlle numbers are "nice to have" and make operations larger and more sophisticated--they are not necessary, our rivals may be just a kid the same as they can be a nation-state. The cost of entry is low, anonymity is potentially (under the right conditions) assured. In my article for the Georgetown Journal of International Affairs on the war in Estonia, I mentioned how Martin van Creveld said decades ago how we will be facing "organizations" rather than just countries. He was laughed at and later obviously vidincated (think terrorism as one example). Today it's much worse than that, and I state the game can be played by individuals, ad-hoc groups and populations (not necessarily under any flag or leadership, think Estonia). Gadi. > > >> -----Original Message----- >> From: Gadi Evron [mailto:ge at linuxbox.org] >> Sent: Friday, June 27, 2008 8:33 PM >> To: Tomas L. Byrnes >> Cc: Christopher Morrow; Roger Marquis; nanog at nanog.org >> Subject: RE: ICANN opens up Pandora's Box of new TLDs >> >> On Fri, 27 Jun 2008, Tomas L. Byrnes wrote: >>> These issues are not separate and distinct, but rather related. >>> >>> A graduated level of analysis of membership in any of the sets of: >>> >>> 1: Recently registered domain. >>> >>> 2: Short TTL >>> >>> 3: Appearance in DShield, Shadowserver, Cyber-TA and other >> sensor lists. >>> >>> 4: Invalid/Non-responsive RP info in Whois >>> >>> Create a pretty good profile of someone you probably don't want to >>> accept traffic from. >>> >>> Conflation is bad, recognizing that each metric has value, and some >>> correlation of membership in more than one set has even >> more value, as >>> indicating a likely criminal node, is good. >>> >>> YMMV. >>> >>> I guess, if you have perfect malware signatures, code with >> no errors, >>> and vigilance the Marines on the wire @ gitmo would envy, you can >>> accept traffic from everywhere. >> >> Not quite, because you still won't know who to send the Marines to >> kill. >> The Internet is perfect for plausible deniability. >> >> Gadi. >> >>> >>> >>> >>>> -----Original Message----- >>>> From: Christopher Morrow [mailto:morrowc.lists at gmail.com] >>>> Sent: Friday, June 27, 2008 7:23 PM >>>> To: Roger Marquis >>>> Cc: nanog at nanog.org >>>> Subject: Re: ICANN opens up Pandora's Box of new TLDs >>>> >>>> On Fri, Jun 27, 2008 at 4:32 PM, Roger Marquis >>>> wrote: >>>>> Phil Regnauld wrote: >>>>> apply even cursory tests for domain name validity. Phishers and >>>>> spammers will have a field day with the inevitable namespace >>>>> collisions. It is, however, unfortunately consistent with ICANN's >>>>> inability to address other security issues such as fast >> flush DNS, >>>>> domain tasting (botnets), and requiring valid domain contacts. >>>>> >>>> >>>> Please do not conflate: >>>> >>>> 1) Fast flux >>>> 2) Botnets >>>> 3) Domain tasting >>>> 4) valid contact info >>>> >>>> These are separate and distinct issues... I'd point out >> that FastFlux >>>> is actually sort of how Akamai does it's job (inconsistent dns >>>> responses), Double-Flux (at least the traditional DF) isn't though >>>> certainly Akamai COULD do something similar to Double-Flux (and >>>> arguably does with some bits their services. The particular form >>>> 'Double-Flux' is certainly troublesome, but arguably >> TOS/AUP info at >>>> Registrars already deals with most of this because #4 in your list >>>> would apply... That or use of the domain for clearly illicit ends. >>>> Also, perhaps just not having Registrar's that solely deal in >>>> criminal activities would make this harder to accomplish... >>>> >>>> Botnets clearly are bad... I'm not sure they are related >> to ICANN in >>>> any real way though, so that seems like a red herring in the >>>> discussion. >>>> >>>> Domain tasting has solutions on the table (thanks drc for >>>> linkages) but was a side effect of some >>>> customer-satisfaction/buyers-remorse >>>> loopholes placed in the regs... the fact that someone figured out >>>> that computers could be used to take advantage of that >> loophole on a >>>> massive scale isn't super surprising. In the end though, >> it's getting >>>> fixed, perhaps slower than we'd all prefer, but still. >>>> >>>>> I have to conclude that ICANN has failed, simply failed, >>>> and should be >>>>> returned to the US government. Perhaps the DHL would at >>>> least solicit >>>>> for RFCs from the security community. >>>> >>>> I'm not sure a shipping company really is the best place >> to solicit... >>>> or did you mean DHS? and why on gods green earth would you >> want them >>>> involved with this? >>>> >>>> -chris >>>> >>>> >>> >>> >> > > From ge at linuxbox.org Sat Jun 28 00:49:27 2008 From: ge at linuxbox.org (Gadi Evron) Date: Sat, 28 Jun 2008 00:49:27 -0500 (CDT) Subject: warfare and the Internet [was: ICANN opens up Pandora's Box of new TLDs] In-Reply-To: References: <70D072392E56884193E3D2DE09C097A9F2A8@pascal.zaphodb.org> Message-ID: I forgot to change the subject line, apologies. On Sat, 28 Jun 2008, Gadi Evron wrote: > On Fri, 27 Jun 2008, Tomas L. Byrnes wrote: >> >> I just know who should be held for further processing @ the gate. > > This is getting off-topic, so let's continue the discussion for a couple more > emails to see if we can bring it back on-topic to network operations, and > then stop if not? > >> Which is good enough, in this case. >> >> "What is the object of defense? Preservation. It is easier to hold >> ground than take it. . . defense is the stronger form of waging war" >> >> Carl Von Clausewitz > > Which, while valid in many cases, some of them on the Internet, is in most > online cases--false. This is a statement by someone much lesser than > Clausewitz--me. > > It is however, an educated opinion, and chronologically up to date. > > Attack is a much easier form of fighting, online (let's leave war out of it). > For the sake of logic I will base this on two discussion points: > > In security, all you need to attack is one hole, one vulnerability. As a > defender you need to defend against everything, anywhere. This is why risk > analysis exists, which brings us to another point from Karl-- > > Changing the words to fit our needs, Clausewitz also believed wars are won by > numbers, if you have more you win (Think the American Civil War). Strategy > starts when you have less numbers, by where you choose to apply your > forces--where it counts. Tying it with the point above is the basics of risk > analysis in military terms. > > In security and information warfare, whlle numbers are "nice to have" and > make operations larger and more sophisticated--they are not necessary, our > rivals may be just a kid the same as they can be a nation-state. The cost of > entry is low, anonymity is potentially (under the right conditions) assured. > > In my article for the Georgetown Journal of International Affairs on the war > in Estonia, I mentioned how Martin van Creveld said decades ago how we will > be facing "organizations" rather than just countries. He was laughed at and > later obviously vidincated (think terrorism as one example). > > Today it's much worse than that, and I state the game can be played by > individuals, ad-hoc groups and populations (not necessarily under any flag or > leadership, think Estonia). > > Gadi. > > >> >> >>> -----Original Message----- >>> From: Gadi Evron [mailto:ge at linuxbox.org] >>> Sent: Friday, June 27, 2008 8:33 PM >>> To: Tomas L. Byrnes >>> Cc: Christopher Morrow; Roger Marquis; nanog at nanog.org >>> Subject: RE: ICANN opens up Pandora's Box of new TLDs >>> >>> On Fri, 27 Jun 2008, Tomas L. Byrnes wrote: >>>> These issues are not separate and distinct, but rather related. >>>> >>>> A graduated level of analysis of membership in any of the sets of: >>>> >>>> 1: Recently registered domain. >>>> >>>> 2: Short TTL >>>> >>>> 3: Appearance in DShield, Shadowserver, Cyber-TA and other >>> sensor lists. >>>> >>>> 4: Invalid/Non-responsive RP info in Whois >>>> >>>> Create a pretty good profile of someone you probably don't want to >>>> accept traffic from. >>>> >>>> Conflation is bad, recognizing that each metric has value, and some >>>> correlation of membership in more than one set has even >>> more value, as >>>> indicating a likely criminal node, is good. >>>> >>>> YMMV. >>>> >>>> I guess, if you have perfect malware signatures, code with >>> no errors, >>>> and vigilance the Marines on the wire @ gitmo would envy, you can >>>> accept traffic from everywhere. >>> >>> Not quite, because you still won't know who to send the Marines to >>> kill. >>> The Internet is perfect for plausible deniability. >>> >>> Gadi. >>> >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: Christopher Morrow [mailto:morrowc.lists at gmail.com] >>>>> Sent: Friday, June 27, 2008 7:23 PM >>>>> To: Roger Marquis >>>>> Cc: nanog at nanog.org >>>>> Subject: Re: ICANN opens up Pandora's Box of new TLDs >>>>> >>>>> On Fri, Jun 27, 2008 at 4:32 PM, Roger Marquis >>>>> wrote: >>>>>> Phil Regnauld wrote: >>>>>> apply even cursory tests for domain name validity. Phishers and >>>>>> spammers will have a field day with the inevitable namespace >>>>>> collisions. It is, however, unfortunately consistent with ICANN's >>>>>> inability to address other security issues such as fast >>> flush DNS, >>>>>> domain tasting (botnets), and requiring valid domain contacts. >>>>>> >>>>> >>>>> Please do not conflate: >>>>> >>>>> 1) Fast flux >>>>> 2) Botnets >>>>> 3) Domain tasting >>>>> 4) valid contact info >>>>> >>>>> These are separate and distinct issues... I'd point out >>> that FastFlux >>>>> is actually sort of how Akamai does it's job (inconsistent dns >>>>> responses), Double-Flux (at least the traditional DF) isn't though >>>>> certainly Akamai COULD do something similar to Double-Flux (and >>>>> arguably does with some bits their services. The particular form >>>>> 'Double-Flux' is certainly troublesome, but arguably >>> TOS/AUP info at >>>>> Registrars already deals with most of this because #4 in your list >>>>> would apply... That or use of the domain for clearly illicit ends. >>>>> Also, perhaps just not having Registrar's that solely deal in >>>>> criminal activities would make this harder to accomplish... >>>>> >>>>> Botnets clearly are bad... I'm not sure they are related >>> to ICANN in >>>>> any real way though, so that seems like a red herring in the >>>>> discussion. >>>>> >>>>> Domain tasting has solutions on the table (thanks drc for >>>>> linkages) but was a side effect of some >>>>> customer-satisfaction/buyers-remorse >>>>> loopholes placed in the regs... the fact that someone figured out >>>>> that computers could be used to take advantage of that >>> loophole on a >>>>> massive scale isn't super surprising. In the end though, >>> it's getting >>>>> fixed, perhaps slower than we'd all prefer, but still. >>>>> >>>>>> I have to conclude that ICANN has failed, simply failed, >>>>> and should be >>>>>> returned to the US government. Perhaps the DHL would at >>>>> least solicit >>>>>> for RFCs from the security community. >>>>> >>>>> I'm not sure a shipping company really is the best place >>> to solicit... >>>>> or did you mean DHS? and why on gods green earth would you >>> want them >>>>> involved with this? >>>>> >>>>> -chris >>>>> >>>>> >>>> >>>> >>> >> >> > From rsk at gsp.org Sat Jun 28 05:48:54 2008 From: rsk at gsp.org (Rich Kulawiec) Date: Sat, 28 Jun 2008 06:48:54 -0400 Subject: ICANN opens up Pandora's Box of new TLDs In-Reply-To: References: <20080627120549.32616.qmail@simone.iecc.com> Message-ID: <20080628104854.GA30532@gsp.org> On Fri, Jun 27, 2008 at 01:40:03PM -0700, David Conrad wrote: > > On Jun 27, 2008, at 5:22 AM, Alexander Harrowell wrote: >> Well, at least the new TLDs will promote DNS-based cruft filtration. >> You can >> already safely ignore anything with a .name, .biz, .info, .tv suffix, >> to >> name just the worst. > > Does this actually work? The vast majority of spam I receive has an > origin that doesn't reverse map. Best practice is refuse all mail that comes from any host lacking rDNS, since that host doesn't meet the minimum requirements for a mail server. After that, other sanity checks (such as matching forward DNS, valid HELO, proper wait for SMTP greeting, etc.) also knock out a good chunk of spam. Yes, some of these also impact non-spamming but broken mail servers, however, this is usually the only way to get the attention of their operators and persuade them to effect repairs. Beyond that, blocking of various gTLDs and ccTLDs and network allocations works nicely, depending on what your particular mix of inbound spam/not-spam is. Understanding of your own inbound mail mix is crucial to deciding which ones are viable for your operation. Locally, I've had .cn and .kr along with their entire network allocations blacklisted for years, and this has worked nicely; but clearly it wouldn't work well for, say, a major US research university. Locally, .name, .info and .tv are permanently blacklisted, and I recommend this to others: they're all heavily spammer-infested. .biz is not blacklisted at the moment, largely because it's been so badly ravaged that spammers *appear* to be abandoning it. ---Rsk From rsk at gsp.org Sat Jun 28 05:53:19 2008 From: rsk at gsp.org (Rich Kulawiec) Date: Sat, 28 Jun 2008 06:53:19 -0400 Subject: ICANN opens up Pandora's Box of new TLDs In-Reply-To: <48657AA8.9000005@psg.com> References: <20080627120549.32616.qmail@simone.iecc.com> <48657AA8.9000005@psg.com> Message-ID: <20080628105319.GB30532@gsp.org> On Sat, Jun 28, 2008 at 08:41:28AM +0900, Randy Bush wrote: > this is analogous to the gossip that most spam comes from china, asia, > nigeria, or whomever we like to be xenophobic or racist about this week. > measurement shows the united states to be the largest single source of spam. Globally, yes, but anti-spam measures aren't global: they're local. Everyone's mix is different: for example, during the past week, informal comparison of the incidence of pump-and-dumps spams revealed that one correspondent's have dropped to almost nothing, while another's continue to steadily increase. Global generalizations about spam trends are interesting, but not of much use in crafting local policy. The only thing that works for that is log analysis, in order to identify the composition of traffic and thus craft a policy (and then presumably implement it) that attempts to minimize the local FP/FN rates. (Note that FP/FN are always defined locally; there is no such thing as a general definition.) That said, global trends can provide some idea of what to look for in local traffic: for example, given the massive infestation of .info by spammers, phishers, spyware, adware, trojans, typosquatters, link farms, drive-by-downloaders, etc., it's very likely that most people will see a significant reduction in spam by blacklisting the TLD. ---Rsk From rsk at gsp.org Sat Jun 28 06:01:05 2008 From: rsk at gsp.org (Rich Kulawiec) Date: Sat, 28 Jun 2008 07:01:05 -0400 Subject: what problem are we solving? (was Re: ICANN opens up Pandora's Box of new TLDs) In-Reply-To: <171423de0806271024h73e9a181t1df338aa5fe84ef5@mail.gmail.com> References: <171423de0806271024h73e9a181t1df338aa5fe84ef5@mail.gmail.com> Message-ID: <20080628110105.GC30532@gsp.org> On Fri, Jun 27, 2008 at 10:24:48AM -0700, Scott Francis wrote: > more to the point ... what problem is ICANN trying to solve with this > proposal? Oh, that's quite straightforward: insufficient registrar revenue. ---Rsk From rs at seastrom.com Sat Jun 28 06:07:43 2008 From: rs at seastrom.com (Robert E. Seastrom) Date: Sat, 28 Jun 2008 07:07:43 -0400 Subject: ICANN opens up Pandora's Box of new TLDs In-Reply-To: <48657AA8.9000005@psg.com> (Randy Bush's message of "Sat, 28 Jun 2008 08:41:28 +0900") References: <20080627120549.32616.qmail@simone.iecc.com> <48657AA8.9000005@psg.com> Message-ID: <86hcbdg6m8.fsf@seastrom.com> Randy Bush writes: > this is analogous to the gossip that most spam comes from china, asia, > nigeria, or whomever we like to be xenophobic or racist about this week. > measurement shows the united states to be the largest single source of spam. The US is also the largest single source of email-that-I-want. Conversely, it's safe to assume that anything encoded in BIG5 format is something I'm totally uninterested in. There are indeed entire countries that I could block with a false positive rate of less than one every five years, which is a lot better than some other antispam technologies. Not that I'm doing this though. RBLs, SA, and greylisting with a carefully crafted list of organizations I've found that don't play well, works "well enough", and having everything wired up so it runs at or before the end of the DATA phase means I don't get left holding the bag for anything. -r From r.bhatia at ipax.at Sat Jun 28 06:19:09 2008 From: r.bhatia at ipax.at (Raoul Bhatia [IPAX]) Date: Sat, 28 Jun 2008 13:19:09 +0200 Subject: ICANN opens up Pandora's Box of new TLDs In-Reply-To: References: <7ff145960806261309u4eda28b7v8973556b983df63a@mail.gmail.com> <5429E6E0-382A-4711-8D8C-2A241B6E4F6A@mailchannels.com> <48640FC2.2000909@spaghetti.zurich.ibm.com> Message-ID: <48661E2D.60207@ipax.at> Tony Finch wrote: > On Thu, 26 Jun 2008, Jeroen Massar wrote: >> thinking of all the nice security issues which come along (home, mycomputer >> and .exe etc anyone ? :) > > .exe has the same security properties as .com not exactly, as a lot of users know that there is something like a .com domain. they will expect something else from .exe but for automated security, i quite agree. cheers, raoul -- ____________________________________________________________________ DI (FH) Raoul Bhatia M.Sc. email. r.bhatia at ipax.at Technischer Leiter IPAX - Aloy Bhatia Hava OEG web. http://www.ipax.at Barawitzkagasse 10/2/2/11 email. office at ipax.at 1190 Wien tel. +43 1 3670030 FN 277995t HG Wien fax. +43 1 3670030 15 ____________________________________________________________________ From regnauld at catpipe.net Sat Jun 28 06:37:52 2008 From: regnauld at catpipe.net (Phil Regnauld) Date: Sat, 28 Jun 2008 13:37:52 +0200 Subject: ICANN opens up Pandora's Box of new TLDs In-Reply-To: References: <7ff145960806261309u4eda28b7v8973556b983df63a@mail.gmail.com> <20080626203334.GA18237@cgi.jachomes.com> Message-ID: <20080628113752.GH31980@catpipe.net> Owen DeLong (owen) writes: >> > Whether some choose to do that or not, I believe that the point is that: > > 1. Nobody is FORCING them to do so. Trademark law is forcing you to - you have to make reasonable attempts to actively defend your trademark. Of course, no-one forces you to trademark your name in the first place. Not that I agree with the practice, either. Phil From regnauld at catpipe.net Sat Jun 28 06:52:16 2008 From: regnauld at catpipe.net (Phil Regnauld) Date: Sat, 28 Jun 2008 13:52:16 +0200 Subject: ICANN opens up Pandora's Box of new TLDs In-Reply-To: <48658FDE.8040400@shankland.org> References: <20080627120549.32616.qmail@simone.iecc.com> <48657AA8.9000005@psg.com> <48658FDE.8040400@shankland.org> Message-ID: <20080628115215.GI31980@catpipe.net> Jim Shankland (nanog) writes: > > Because it's Friday, I checked the last few weeks or so of logs from > my personal mail server (located in the US), and broke the list of > unique IP addresses rejected by zen.spamhaus.org up by registry: ... spam coming from US computers vs. spam coming from botnets which are being rented by american spammers. There is a distinction. Don't think that legitimate american businesses aren't the only ones who've outsourced. A lot of people around the world running XP just don't know that they're doing the outsourcing :) P. From regnauld at catpipe.net Sat Jun 28 06:56:53 2008 From: regnauld at catpipe.net (Phil Regnauld) Date: Sat, 28 Jun 2008 13:56:53 +0200 Subject: ICANN opens up Pandora's Box of new TLDs In-Reply-To: <20080628104854.GA30532@gsp.org> References: <20080627120549.32616.qmail@simone.iecc.com> <20080628104854.GA30532@gsp.org> Message-ID: <20080628115653.GJ31980@catpipe.net> Rich Kulawiec (rsk) writes: > > Best practice is refuse all mail that comes from any host lacking rDNS, > since that host doesn't meet the minimum requirements for a mail server. No, that's utterly stupid. You're excluding countries which have poor infrastructure or clueless ISPs (usually legacy telco operators) who can't be bothered to administrate IN-ADDR.ARPA delegations for their customers. It doesn't help, and only encourages people in these countries to go for @{hotmail|yahoo|gmail}. Millions of botnet PCs have valid reverses. > Yes, some of these also impact non-spamming but broken mail servers, > however, this is usually the only way to get the attention of their > operators and persuade them to effect repairs. You're kidding, right ? They don't give a rat's ass. > Locally, .name, .info and .tv are permanently blacklisted, and I recommend > this to others: they're all heavily spammer-infested. .biz is not > blacklisted at the moment, largely because it's been so badly ravaged > that spammers *appear* to be abandoning it. "Bomb the bridge, salt the earth" approach ? From regnauld at catpipe.net Sat Jun 28 07:03:34 2008 From: regnauld at catpipe.net (Phil Regnauld) Date: Sat, 28 Jun 2008 14:03:34 +0200 Subject: ICANN opens up Pandora's Box of new TLDs In-Reply-To: <20080627203205.51B612B7C02@mx5.roble.com> References: <20080627203205.51B612B7C02@mx5.roble.com> Message-ID: <20080628120334.GK31980@catpipe.net> Roger Marquis (marquis) writes: > I have to conclude that ICANN has failed, simply failed, and should be > returned to the US government. Perhaps the DHL would at least solicit for > RFCs from the security community. DHS ? Otherwise, yes, you could ship ICANN back to the US gvt. with DHL, but I don't think they'll give us our money back. From drc at virtualized.org Sat Jun 28 07:40:55 2008 From: drc at virtualized.org (David Conrad) Date: Sat, 28 Jun 2008 05:40:55 -0700 Subject: what problem are we solving? (was Re: ICANN opens up Pandora's Box of new TLDs) In-Reply-To: <48658FD2.2070000@vaxination.ca> References: <171423de0806271024h73e9a181t1df338aa5fe84ef5@mail.gmail.com> <486555D3.7090107@vaxination.ca> <5940.1214601300@turing-police.cc.vt.edu> <48658FD2.2070000@vaxination.ca> Message-ID: <4FE22484-E141-4329-8799-DB7230A968D0@virtualized.org> On Jun 27, 2008, at 6:11 PM, Jean-Fran?ois Mezei wrote: > But my uneducated opinion is that this current project appears to let > the .TLD loose and this will result in top level domains being > meaningless, without any trust. Given the complexity of the new gTLD process, I think it safe to say that there will be quite significant vetting of pretty much all aspects of new TLD applications. The press reports that say 'the floodgates have been opened' simply aren't true. > There should have been an evolution from a tightly controlled small > set > of TLDs towards alowly growing set of TLDs done fairly and openly. There has been. There was an initial set of 7 new TLDs (biz, info, name, museum, coop, aero, pro) back in 2002. There was much (justifiable IMHO) unhappiness about the process that created these TLDs. ICANN went back to the drawing board and came up with a new process ('sponsored' TLDs) which resulted in travel, cat, jobs, mobi, tel, and post (xxx was in this crowd but was shot down). There was much (justifiable IMHO) unhappiness about the process that created these TLDs. ICANN went back to the drawing board and came up with a new process. And here we are. I'm sure ICANN got it exactly right this time... (OK, maybe not :-)). Regards, -drc From drc at virtualized.org Sat Jun 28 07:49:54 2008 From: drc at virtualized.org (David Conrad) Date: Sat, 28 Jun 2008 05:49:54 -0700 Subject: what problem are we solving? (was Re: ICANN opens up Pandora's Box of new TLDs) In-Reply-To: <20080628035954.BC78F213C3@spunkymail-a9.g.dreamhost.com> References: <171423de0806271024h73e9a181t1df338aa5fe84ef5@mail.gmail.com> <4D0B482D-8FD5-48A5-9FF6-C2011AA7ACB5@virtualized.org> <20080628035954.BC78F213C3@spunkymail-a9.g.dreamhost.com> Message-ID: <4C0790EA-33E5-43F2-B281-215A0B37AE4F@virtualized.org> On Jun 27, 2008, at 8:59 PM, WWWhatsup wrote: > David Conrad wrote: >> With that said, personally, I agree that more attention should be >> spent on the welfare of the registrants. Unfortunately, given I work >> for ICANN, my providing comments in the RAA public consultation along >> those lines would be a bit ... awkward. > > Would you agree with Danny Younger (I believe this is his position) > then that there should be a > properly constituted & recognized registrants constituency? Obviously speaking personally, conceptually I agree, but the challenge here has always been how do you "properly constitute and recognize registrants" in a way that doesn't allow for capture. For example, you could say 'only folks who have domain names can be part of that constituency', but in reality, the majority of domain names are held by registrars. You could add the restriction that 'registrants' must be natural persons, but how would one verify this across the entire planet? It obviously isn't impossible, but people already complain about how big ICANN is -- I can't see how having some mechanism to validate a registrant constituency won't make ICANN _much_ larger... However, lacking this, I personally believe there should be strong explicit registrant protections built into the RAA. But that's just me. Regards, -drc From drc at virtualized.org Sat Jun 28 07:58:16 2008 From: drc at virtualized.org (David Conrad) Date: Sat, 28 Jun 2008 05:58:16 -0700 Subject: ICANN opens up Pandora's Box of new TLDs In-Reply-To: <48661E2D.60207@ipax.at> References: <7ff145960806261309u4eda28b7v8973556b983df63a@mail.gmail.com> <5429E6E0-382A-4711-8D8C-2A241B6E4F6A@mailchannels.com> <48640FC2.2000909@spaghetti.zurich.ibm.com> <48661E2D.60207@ipax.at> Message-ID: <2FF99DD3-3075-4403-B0EB-8E77148AA608@virtualized.org> On Jun 28, 2008, at 4:19 AM, Raoul Bhatia [IPAX] wrote: > Tony Finch wrote: >> On Thu, 26 Jun 2008, Jeroen Massar wrote: >>> thinking of all the nice security issues which come along (home, >>> mycomputer >>> and .exe etc anyone ? :) >> >> .exe has the same security properties as .com > > not exactly, as a lot of users know that there is something like a > .com domain. they will expect something else from .exe I'm not sure I understand the security threat here. Is the theory that someone will click on "foo.exe" and the fact that it is a URL is somehow worse than if it is an actual executable? If that's not it, can someone explain (small words, with subtitles -- I'm not a security geek). Thanks, -drc From jgreco at ns.sol.net Sat Jun 28 08:46:33 2008 From: jgreco at ns.sol.net (Joe Greco) Date: Sat, 28 Jun 2008 08:46:33 -0500 (CDT) Subject: what problem are we solving? (was Re: ICANN opens up Pandora's Box of In-Reply-To: <171423de0806271024h73e9a181t1df338aa5fe84ef5@mail.gmail.com> from "Scott Francis" at Jun 27, 2008 10:24:48 AM Message-ID: <200806281346.m5SDkX9b094171@aurora.sol.net> > > On Thu, Jun 26, 2008 at 9:01 PM, Jean-Fran?ois Mezei > wrote: > [snip conflict examples] > > > Finally, will there be any performance impact on DNS servers around the > > world (thinking of caching issues) ? > > more to the point ... what problem is ICANN trying to solve with this > proposal? What about the current system that's broken, does this new > system fix? It looks like a lot of thought went into the process > (thanks for the PDF link, DRC), and most of the issues raised here are > addressed (conflicts, abuse/phishing grabs, etc.) - I'm just still > unclear what the motivation for this new system was in the first > place. > > I'm not opposed to it if it solves a legitimate technical/operational > issue that's germaine to either the operators of the Internet or the > users of the Internet, but so far I can't see that this serves either > of those communities. In fact, it could very well be argued that a > slew of new TLDs (whether a few dozen or a few hundred) will only > serve to increase complexity and add additional confusion to a system > that the standard user has just now come to grips with > ("www.company.com will get me Company's official, legitimate page"). Yes. It completely marginalizes the remaining positive qualities of the Domain Name System as a way to find things, in the name of giving people "more options." Let me start by saying that I believe that the trends in the DNS have been going the wrong way for well over a decade. The insistence on the part of many that the namespace be flattened is just a poor choice. People are now used to trying ".com" to reach a company. In some cases, this makes fair sense; I can see why "ibm.com" or "seagate.com" are that way, even though in some cases there are namespace collisions with other trademarks. In others, it's ridiculous - why the heck do I get someplace in California when I go to "martyspizza.com", rather than our local very excellent pizza place? (sadly this example is less effective now, they managed to get "martyspizza.net" a few years back). We never had any business allowing small, local businesses to register in .com, or non-networking companies to register in .net, or non-organizations in .org... but a whole generation of Internet "professionals" "knew better" and the end result at the end of the road is that DNS will end up being almost as useless as IPv4 numbers for identifying the more obscure bits of the Internet. It would have been much better for us to fix some of the obvious problems with DNS back in the day. Instead, we didn't bother, and instead allowed "market forces" to dictate what happened next. This of course got buyers whatever they wanted (which was generally "short names!"), but what buyers wanted didn't necessarily map well into what would have made sense for /users/ of the system, which would have been "predictability of names." We are now reaping the evolution of that into even further mayhem. I look forward to many more years of having to remember that Marty's Pizza is "martyspizza.net" instead of "martyspizza.brookfield.wi.us", that Milwaukee's Department of Public Works is at "mpw.net" instead of "dpw.ci.milwaukee.wi.us", etc. I've kept this short and have omitted lots. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From tme at multicasttech.com Sat Jun 28 08:48:01 2008 From: tme at multicasttech.com (Marshall Eubanks) Date: Sat, 28 Jun 2008 09:48:01 -0400 Subject: ICANN opens up Pandora's Box of new TLDs In-Reply-To: <20080628104854.GA30532@gsp.org> References: <20080627120549.32616.qmail@simone.iecc.com> <20080628104854.GA30532@gsp.org> Message-ID: On Jun 28, 2008, at 6:48 AM, Rich Kulawiec wrote: > On Fri, Jun 27, 2008 at 01:40:03PM -0700, David Conrad wrote: >> >> On Jun 27, 2008, at 5:22 AM, Alexander Harrowell wrote: >>> Well, at least the new TLDs will promote DNS-based cruft filtration. >>> You can >>> already safely ignore anything with a .name, .biz, .info, .tv >>> suffix, >>> to >>> name just the worst. >> >> Does this actually work? The vast majority of spam I receive has an >> origin that doesn't reverse map. > > Best practice is refuse all mail that comes from any host lacking > rDNS, > since that host doesn't meet the minimum requirements for a mail > server. > > After that, other sanity checks (such as matching forward DNS, valid > HELO, > proper wait for SMTP greeting, etc.) also knock out a good chunk of > spam. > > Yes, some of these also impact non-spamming but broken mail servers, > however, this is usually the only way to get the attention of their > operators and persuade them to effect repairs. > > Beyond that, blocking of various gTLDs and ccTLDs and network > allocations > works nicely, depending on what your particular mix of inbound spam/ > not-spam > is. Understanding of your own inbound mail mix is crucial to deciding > which ones are viable for your operation. Locally, I've had .cn > and .kr > along with their entire network allocations blacklisted for years, and > this has worked nicely; but clearly it wouldn't work well for, say, > a major US research university. > > Locally, .name, .info and .tv are permanently blacklisted, and I > recommend > this to others: they're all heavily spammer-infested. .biz is not > blacklisted at the moment, largely because it's been so badly ravaged > that spammers *appear* to be abandoning it. Hmm. Looking at the recent spam collection plus email archive for the accounts I host for SPAM (recent messages only) 13864 messages - 57 from .info rate = 0.4 % 13864 messages - 8761 from .com rate = 63.1 % Non-SPAM (going back ~ two years) 122846 messages - 607 from .info - rate = 0.5 % 122846 messages - 71888 from .com - rate = 58.5 % I don't see any strong reason to drop .info traffic here. Note, btw, that at least Joe Abley, Andrew Sullivan and Brian Dickson post to NANOG repeatedly from .info Regards Marshall > > > ---Rsk > > From jra at baylink.com Sat Jun 28 10:33:18 2008 From: jra at baylink.com (Jay R. Ashworth) Date: Sat, 28 Jun 2008 11:33:18 -0400 Subject: Expired SSL cert for mms.nexteldata.net Message-ID: <20080628153317.GA29697@cgi.jachomes.com> According to my Blackberry, it expired last night at midnight UTC. RSA/1024, issued by Verisign. Serial number ends in 73aa 0f08 Is anyone at Nextel/Sprint/RIM listening here? My Blackberry tells me what the problem is, but for everyone on normal phones, it's probably just an error; calling first-tier support seems... unproductive. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com '87 e24 St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 Those who cast the vote decide nothing. Those who count the vote decide everything. -- (Joseph Stalin) From LarrySheldon at cox.net Sat Jun 28 11:01:44 2008 From: LarrySheldon at cox.net (Laurence F. Sheldon, Jr.) Date: Sat, 28 Jun 2008 11:01:44 -0500 Subject: Expired SSL cert for mms.nexteldata.net In-Reply-To: <20080628153317.GA29697@cgi.jachomes.com> References: <20080628153317.GA29697@cgi.jachomes.com> Message-ID: <48666068.3070706@cox.net> Jay R. Ashworth wrote: > According to my Blackberry, it expired last night at midnight UTC. Is this the end of the world, then? -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs From rsk at gsp.org Sat Jun 28 11:06:03 2008 From: rsk at gsp.org (Rich Kulawiec) Date: Sat, 28 Jun 2008 12:06:03 -0400 Subject: ICANN opens up Pandora's Box of new TLDs In-Reply-To: <20080628115653.GJ31980@catpipe.net> References: <20080627120549.32616.qmail@simone.iecc.com> <20080628104854.GA30532@gsp.org> <20080628115653.GJ31980@catpipe.net> Message-ID: <20080628160603.GA16339@gsp.org> On Sat, Jun 28, 2008 at 01:56:53PM +0200, Phil Regnauld wrote: > Rich Kulawiec (rsk) writes: > > > > Best practice is refuse all mail that comes from any host lacking rDNS, > > since that host doesn't meet the minimum requirements for a mail server. > > No, that's utterly stupid. You're excluding countries which have > poor infrastructure or clueless ISPs (usually legacy telco operators) > who can't be bothered to administrate IN-ADDR.ARPA delegations for > their customers. I don't see a problem with not accepting mail from clueless ISPs or their customers. The requirement for rDNS has been around for decades. Anyone who's not aware of it has no business running a mail server. > Millions of botnet PCs have valid reverses. Yes, I'm well aware of this, especially since I was AFAIK one of the first people to document the use of botnet PCs to send spam. And of course That's why this particular measure doesn't work for them, but other best practices do, e.g., rejecting mail from known-dynamic/generic IP space or known-dynamic/generic namespace unless it's your own customer or is being submitted with authentication non-port 25 > > > Yes, some of these also impact non-spamming but broken mail servers, > > however, this is usually the only way to get the attention of their > > operators and persuade them to effect repairs. > > You're kidding, right ? They don't give a rat's ass. Then they should not be troubled that their mail is being rejected. > > Locally, .name, .info and .tv are permanently blacklisted, and I recommend > > this to others: they're all heavily spammer-infested. .biz is not > > blacklisted at the moment, largely because it's been so badly ravaged > > that spammers *appear* to be abandoning it. > > "Bomb the bridge, salt the earth" approach ? I'm not the one of the people who thought .info was a good idea (what, domains in other TLDs don't provide "information"?) I'm not the one who decided to sell domains in that TLD to spammers by the tens of thousands, thus effectively devaluing it for everyone else. I'm not the one responsible for failure to enforce any meaningful requirements on registrars to control abuse by their customers. And so on. I suggest laying blame on the people who are responsible for the current state of affairs, not on the recipients of abuse. ---Rsk From regnauld at catpipe.net Sat Jun 28 11:18:44 2008 From: regnauld at catpipe.net (Phil Regnauld) Date: Sat, 28 Jun 2008 18:18:44 +0200 Subject: ICANN opens up Pandora's Box of new TLDs In-Reply-To: <20080628160603.GA16339@gsp.org> References: <20080627120549.32616.qmail@simone.iecc.com> <20080628104854.GA30532@gsp.org> <20080628115653.GJ31980@catpipe.net> <20080628160603.GA16339@gsp.org> Message-ID: <20080628161844.GT31980@catpipe.net> Rich Kulawiec (rsk) writes: > > I don't see a problem with not accepting mail from clueless ISPs or their > customers. The requirement for rDNS has been around for decades. > Anyone who's not aware of it has no business running a mail server. Requirement ? What requirement ? There's no requirement for reverse DNS for email in any RFC. Not that RFCs are ideal references for mail operation in general. Rejecting on missing or incorrectly formatted HELO/EHLO is legitimate, as well as unknown sender or recipient domain, as these are within the control of the sender, or the sender's organisation. Reverse DNS is not. It's all subjective of course. > people to document the use of botnet PCs to send spam. And of course > That's why this particular measure doesn't work for them, but other > best practices do, e.g., rejecting mail from known-dynamic/generic IP space > or known-dynamic/generic namespace unless it's your own customer or is > being submitted with authentication non-port 25 "known-dynamic" is extremely up to debate. Frankly, blacklisting entire /16s because individual customer PCs have been hijacked is absurd, but I guess colateral damage is acceptable. Probably bounces will be the next thing to disappear. > > > Yes, some of these also impact non-spamming but broken mail servers, > > > however, this is usually the only way to get the attention of their > > > operators and persuade them to effect repairs. > > > > You're kidding, right ? They don't give a rat's ass. > > Then they should not be troubled that their mail is being rejected. The operators don't care. The customers do. The customers don't have a choice, often. So you're right, the operator is not troubled that their customer's mail is being rejected. > > "Bomb the bridge, salt the earth" approach ? > > I'm not the one of the people who thought .info was a good idea (what, > domains in other TLDs don't provide "information"?) I'm not the one > who decided to sell domains in that TLD to spammers by the tens of > thousands, thus effectively devaluing it for everyone else. Because .org and .com don't do that as well ? > I suggest laying blame on the people who are responsible for the current > state of affairs, not on the recipients of abuse. I'm not laying blame here, just pointing out that rejecting mail from IP addresses for which no PTR delegation exists is unwarranted, but it's your system, so of course it's up to you. Don't go preaching it as a best practice, though. Phil From bmanning at vacation.karoshi.com Sat Jun 28 11:35:33 2008 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Sat, 28 Jun 2008 16:35:33 +0000 Subject: ICANN opens up Pandora's Box of new TLDs In-Reply-To: <20080628161844.GT31980@catpipe.net> References: <20080627120549.32616.qmail@simone.iecc.com> <20080628104854.GA30532@gsp.org> <20080628115653.GJ31980@catpipe.net> <20080628160603.GA16339@gsp.org> <20080628161844.GT31980@catpipe.net> Message-ID: <20080628163533.GA32543@vacation.karoshi.com.> ob spam... Spam is viral marketing for CHoRD? DNS can deal w/ billions of entries... order magnitude IPv4 space, with relative ease (note well the use of the term "relative") not at all convinced that unmodified DNS can deal w/ spaces on the order of magnitude of IPv6 space... *and yes, there is -zero- correlation btwn numbers and names, except if you want the pants whole. The analogy? Forward DNS is like the front half of your pants.... and the reverse map is the back half. Some folks are comfortable wearing only chaps, but I really want a complete pair thanks. --bill From michael.dillon at bt.com Sat Jun 28 11:41:52 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Sat, 28 Jun 2008 17:41:52 +0100 Subject: Mail Server best practices - was: Pandora's Box of new TLDs In-Reply-To: <20080628161844.GT31980@catpipe.net> Message-ID: > Requirement ? What requirement ? There's no requirement for > reverse DNS for email in any RFC. Not that RFCs are > ideal references > for mail operation in general. You're right, documents published by an organization whose goal is to design internetworking protocols are not the best place to find operational advice. For that you would be better to go to an organization like MAAWG which publishes this BCP: http://www.maawg.org/about/MAAWG_Sender_BCP/MAAWG_Senders_BCP_Combine.pd f On page 5 they do recommend matching reverse DNS and in Appendix A they go on to state that RFC 1912 states that all hosts on the Internet should have a valid rDNS entry. Perhaps the RFC series doesn't have as many gaps as we think. > "known-dynamic" is extremely up to debate. Frankly, > blacklisting > entire /16s because individual customer PCs have been > hijacked is > absurd, but I guess colateral damage is acceptable. If collateral damage is acceptable, then how is this absurd? Once you accept that it is better to reject good email than let bad email through, the game has changed. It may end up by destroying the business usefulness of the existing email architecture, but not without a push from someone who has a better mousetrap. > I'm not laying blame here, just pointing out that rejecting mail > from IP addresses for which no PTR delegation exists is > unwarranted, This is quite simply, wrong. It is warranted. > Don't go preaching > it as a best practice, though. Too late, the MAAWG has already published this as a best practice for quite some time. If you don't follow the MAAWG best practices then you are not a serious email operator. If email is mission critical to your business, then you really should be an MAAWG member as well. --Michael Dillon P.S. I personally have nothing to do with the MAAWG although my company is an active member. From nanog at shankland.org Sat Jun 28 12:27:15 2008 From: nanog at shankland.org (Jim Shankland) Date: Sat, 28 Jun 2008 10:27:15 -0700 Subject: ICANN opens up Pandora's Box of new TLDs In-Reply-To: <20080628161844.GT31980@catpipe.net> References: <20080627120549.32616.qmail@simone.iecc.com> <20080628104854.GA30532@gsp.org> <20080628115653.GJ31980@catpipe.net> <20080628160603.GA16339@gsp.org> <20080628161844.GT31980@catpipe.net> Message-ID: <48667473.9000201@shankland.org> Phil Regnauld wrote: > Requirement ? What requirement ? There's no requirement for > reverse DNS for email in any RFC. As a practical matter, I've found that sending out email from a host without rDNS doesn't work: too many sites bounce the mail. It will not come as news to anyone on this list that the world of SMTP is hardly well-defined or well-regulated in practice. Like Rowlf the dog, we can't live with it, we can't live without it, but we're stuck until something better comes along: http://www.youtube.com/watch?v=1vvV9LjBsNw Jim Shankland From frnkblk at iname.com Sat Jun 28 12:49:35 2008 From: frnkblk at iname.com (Frank Bulk - iNAME) Date: Sat, 28 Jun 2008 12:49:35 -0500 Subject: what problem are we solving? (was Re: ICANN opens up Pandora's Box of new TLDs) In-Reply-To: <4C0790EA-33E5-43F2-B281-215A0B37AE4F@virtualized.org> References: <171423de0806271024h73e9a181t1df338aa5fe84ef5@mail.gmail.com> <4D0B482D-8FD5-48A5-9FF6-C2011AA7ACB5@virtualized.org> <20080628035954.BC78F213C3@spunkymail-a9.g.dreamhost.com> <4C0790EA-33E5-43F2-B281-215A0B37AE4F@virtualized.org> Message-ID: One way to provide protection is too allow those who have the domain portion of any domain.(com|net|org|...) to have first dibs for the domain of any new gTLD. i.e. if nanog.org, nanog.com, nanog.net, etc. would have first dibs on nanog.thisisgreatstuff. Or is that too simplistic and fraught with division? Frank -----Original Message----- From: David Conrad [mailto:drc at virtualized.org] Sent: Saturday, June 28, 2008 7:50 AM To: WWWhatsup Cc: nanog at nanog.org Subject: Re: what problem are we solving? (was Re: ICANN opens up Pandora's Box of new TLDs) On Jun 27, 2008, at 8:59 PM, WWWhatsup wrote: > David Conrad wrote: >> With that said, personally, I agree that more attention should be >> spent on the welfare of the registrants. Unfortunately, given I work >> for ICANN, my providing comments in the RAA public consultation along >> those lines would be a bit ... awkward. > > Would you agree with Danny Younger (I believe this is his position) > then that there should be a > properly constituted & recognized registrants constituency? Obviously speaking personally, conceptually I agree, but the challenge here has always been how do you "properly constitute and recognize registrants" in a way that doesn't allow for capture. For example, you could say 'only folks who have domain names can be part of that constituency', but in reality, the majority of domain names are held by registrars. You could add the restriction that 'registrants' must be natural persons, but how would one verify this across the entire planet? It obviously isn't impossible, but people already complain about how big ICANN is -- I can't see how having some mechanism to validate a registrant constituency won't make ICANN _much_ larger... However, lacking this, I personally believe there should be strong explicit registrant protections built into the RAA. But that's just me. Regards, -drc From regnauld at catpipe.net Sat Jun 28 13:02:13 2008 From: regnauld at catpipe.net (Phil Regnauld) Date: Sat, 28 Jun 2008 20:02:13 +0200 Subject: Mail Server best practices - was: Pandora's Box of new TLDs In-Reply-To: References: <20080628161844.GT31980@catpipe.net> Message-ID: <20080628180212.GA35151@catpipe.net> michael.dillon at bt.com (michael.dillon) writes: > > > http://www.maawg.org/about/MAAWG_Sender_BCP/MAAWG_Senders_BCP_Combine.pdf Thanks for the pointer. I don't necessarily agree with all of it, but it's definitely a good reference. I just get irritated by actions that penalize end users who feel they don't have other options other than just using some horrible webmail service, because their operator/ISP is clueless. I do make a distinction. > On page 5 they do recommend matching reverse DNS and in > Appendix A they go on to state that RFC 1912 states that > all hosts on the Internet should have a valid rDNS entry. Indeed it does, but rejecting a mail based on a missing PTR is still arbitrarily useless (and I'm speaking in terms of volume of spam emanating from hosts with a missing PTR, vs spam origination from hosts that do have a PTR). > Perhaps the RFC series doesn't have as many gaps as we think. For mail operations, we're half a galaxy away from "be conservative in what you send, be liberal in what you accept". > > absurd, but I guess colateral damage is acceptable. > > If collateral damage is acceptable, then how is this > absurd? Apologies, I was being sarcastic. > Once you accept that it is better to reject > good email than let bad email through, the game has > changed. It may end up by destroying the business usefulness > of the existing email architecture, but not without a > push from someone who has a better mousetrap. Yep. > This is quite simply, wrong. It is warranted. Not agreeing :) But fair enough, any site is allowed to operate mail the way it wants. > > Don't go preaching > > it as a best practice, though. > > Too late, the MAAWG has already published this as a best practice > for quite some time. If you don't follow the MAAWG best practices > then you are not a serious email operator. If email is mission > critical to your business, then you really should be an MAAWG > member as well. We work for several customers and operate large mail installations. We implement quite a few requirements that are fairly strict, but rejecting based on missing PTR is not one of them. Neither is blacklisting entire TLDs for that matter, but I digress. I still feel like a serious mail operator, just because I don't conclude that I as the receiver should reject mail from a host with a missing PTR, because the MAAWG *Senders* BCP says that hosts should have a reverse. Phil From ml at t-b-o-h.net Sat Jun 28 13:07:27 2008 From: ml at t-b-o-h.net (Tuc at T-B-O-H.NET) Date: Sat, 28 Jun 2008 14:07:27 -0400 (EDT) Subject: what problem are we solving? (was Re: ICANN opens up In-Reply-To: Message-ID: <200806281807.m5SI7R4C048804@himinbjorg.tucs-beachin-obx-house.com> > > One way to provide protection is too allow those who have the domain portion > of any domain.(com|net|org|...) to have first dibs for the domain of any new > gTLD. i.e. if nanog.org, nanog.com, nanog.net, etc. would have first dibs > on nanog.thisisgreatstuff. > > Or is that too simplistic and fraught with division? > I think the point some people are trying to make is that a person could pony up the fees, get a new TLD, and then EXPECT ${FORTUNE_XXXX_COMPANY} to buy theirname.NEWTLD . Instant market. Might even be able to make the investment back the first year, and nice profit the subsequent ones just for companies keeping their name protected. Tuc/TBOH From frnkblk at iname.com Sat Jun 28 13:21:38 2008 From: frnkblk at iname.com (Frank Bulk - iNAME) Date: Sat, 28 Jun 2008 13:21:38 -0500 Subject: Mail Server best practices - was: Pandora's Box of new TLDs In-Reply-To: <20080628180212.GA35151@catpipe.net> References: <20080628161844.GT31980@catpipe.net> <20080628180212.GA35151@catpipe.net> Message-ID: Comments in-line. -----Original Message----- From: Phil Regnauld [mailto:regnauld at catpipe.net] Sent: Saturday, June 28, 2008 1:02 PM To: michael.dillon at bt.com Cc: nanog at nanog.org Subject: Re: Mail Server best practices - was: Pandora's Box of new TLDs michael.dillon at bt.com (michael.dillon) writes: > > > http://www.maawg.org/about/MAAWG_Sender_BCP/MAAWG_Senders_BCP_Combine.pdf Thanks for the pointer. I don't necessarily agree with all of it, but it's definitely a good reference. I just get irritated by actions that penalize end users who feel they don't have other options other than just using some horrible webmail service, because their operator/ISP is clueless. I do make a distinction. FB> You do have an option -- ask the sender to clean up their act. Then the operator/ISP will happily receive the sender's e-mail. When one of our business customers complains to us (ISP) that they can't send e-mail to an external third-party and I find out it's due to poor configuration on their part (almost 100% of the time -- the sole exception that I can recall is a business customer's IP address being blocked by a GoDaddy RBL even though another properly SWIPed customer was sending the spam. Apparently GoDaddy's minimum block size is /24 and they can't bother to look up the ranges), I don't complain about the external third-party, I educate our business customer on best practices. > On page 5 they do recommend matching reverse DNS and in > Appendix A they go on to state that RFC 1912 states that > all hosts on the Internet should have a valid rDNS entry. Indeed it does, but rejecting a mail based on a missing PTR is still arbitrarily useless (and I'm speaking in terms of volume of spam emanating from hosts with a missing PTR, vs spam origination from hosts that do have a PTR). FB> The point is that those are able to create a valid rDNS entry likely have more control of their infrastructure than those who don't. You must admit, if you can't get a proper rDNS entry created for your domain, what does that say about your ability to control your infrastructure? Of course, the inverse it not true. From yahoo at jimpop.com Sat Jun 28 13:34:55 2008 From: yahoo at jimpop.com (Jim Popovitch) Date: Sat, 28 Jun 2008 14:34:55 -0400 Subject: Mail Server best practices - was: Pandora's Box of new TLDs In-Reply-To: References: <20080628161844.GT31980@catpipe.net> <20080628180212.GA35151@catpipe.net> Message-ID: <7ff145960806281134g1c101422o9a46cdd42cfcd05e@mail.gmail.com> On Sat, Jun 28, 2008 at 2:21 PM, Frank Bulk - iNAME wrote: > FB> The point is that those are able to create a valid rDNS entry likely > have more control of their infrastructure than those who don't. You must > admit, if you can't get a proper rDNS entry created for your domain, what > does that say about your ability to control your infrastructure? And to that point, a valid rDNS entry can easily be removed by the netblock holder at smal co-lo facility. This is an easy, although not widely used enough, means for co-lo providers to retain control over leased (mail) servers without worrying about the legal issues with pre-maturely taking a customer offline. I've never seen a posted service delivery statement that guaranteed PTRs. In fact, IMHO, PTRs are a courtesy from the netblock owner, not a given. -Jim P. From rsk at gsp.org Sat Jun 28 13:51:04 2008 From: rsk at gsp.org (Rich Kulawiec) Date: Sat, 28 Jun 2008 14:51:04 -0400 Subject: ICANN opens up Pandora's Box of new TLDs In-Reply-To: <20080628161844.GT31980@catpipe.net> References: <20080627120549.32616.qmail@simone.iecc.com> <20080628104854.GA30532@gsp.org> <20080628115653.GJ31980@catpipe.net> <20080628160603.GA16339@gsp.org> <20080628161844.GT31980@catpipe.net> Message-ID: <20080628185104.GA27290@gsp.org> On Sat, Jun 28, 2008 at 06:18:44PM +0200, Phil Regnauld wrote: > Rich Kulawiec (rsk) writes: > > > > I don't see a problem with not accepting mail from clueless ISPs or their > > customers. The requirement for rDNS has been around for decades. > > Anyone who's not aware of it has no business running a mail server. > > Requirement ? What requirement ? There's no requirement for > reverse DNS for email in any RFC. There are de jure requirements (e.g., RFCs) and de facto requirements (e.g., best practices). de jure: RFC 1912, I believe, indicates that all Internet hosts should have rDNS. de facto: attempting run a mail server without rDNS is increasingly a losing proposition, as everyone with any clue at all is refusing all mail from such misconfigured/broken/ hijacked hosts. > Reverse DNS is not. Not directly, unless delegated, of course. But mail server operators who choose incompetent/lazy/cheap ISPs should not be surprised if they are given incompetent/lazy/cheap service. Quality ISPs are well aware of the de jure and de facto requirements and have no problem meeting them. > "known-dynamic" is extremely up to debate. Frankly, blacklisting > entire /16s because individual customer PCs have been hijacked is > absurd, but I guess colateral damage is acceptable. There is no such thing as "collateral damage" because there is no such thing as "damage" in this context. I explained this in detail on the ietf-asrg mailing list a couple of months ago. And given that any estimate of hijacked systems under 100 million is laughably out-of-date, it's a best practice to blacklist ALL such IP space and namespace pre-emptively. There's no point in waiting for evidence of abuse to show up: it's inevitable. End user systems should either be using their designated outbound mail relays *or* submitting on other ports with authentication. > Probably bounces will be the next thing to disappear. Bounces *should* disappear, since it's a best practive to always reject (during the SMTP conversation) and never bounce. Failure to do so leads to outscatter, which is spam, and to blacklisting of the emitting hosts. > The operators don't care. The customers do. The customers don't have > a choice, often. So you're right, the operator is not troubled > that their customer's mail is being rejected. Then that's a matter between the customer and the operator. Customers who have chosen poorly are likely to have issues. Customers who have not availed themselves of other options (such as a third-party relay through a host whose operators actually knows what they're doing) will get...what they get. > > I'm not the one of the people who thought .info was a good idea (what, > > domains in other TLDs don't provide "information"?) I'm not the one > > who decided to sell domains in that TLD to spammers by the tens of > > thousands, thus effectively devaluing it for everyone else. > > Because .org and .com don't do that as well ? I see a fundemental difference here. .org is for organizations, .com for commercial operations, .net for network service operations. I see valid uses for those. I see none for .info. Its main reason for existence is to provide a cash cow to registrars. > Don't go preaching it as a best practice, though. It's been a best practice for years. ---Rsk From johnl at iecc.com Sat Jun 28 14:38:23 2008 From: johnl at iecc.com (John Levine) Date: 28 Jun 2008 19:38:23 -0000 Subject: the business model, was what problem are we solving? (was Re: ICANN opens In-Reply-To: Message-ID: <20080628193823.33104.qmail@simone.iecc.com> >One way to provide protection is too allow those who have the domain portion >of any domain.(com|net|org|...) to have first dibs for the domain of any new >gTLD. i.e. if nanog.org, nanog.com, nanog.net, etc. would have first dibs >on nanog.thisisgreatstuff. > >Or is that too simplistic and fraught with division? I own iecc.com. A group of educators in Minnesota own iecc.org. A speculator in the UK owns iecc.net. Which, if any, of us gets first dibs on iecc.thisisgreatstuff? On the other hand, there is a school of thought voiced by the trademark lawyers that the main goal of new TLDs is to shake down trademark owners, who are advised by their lawyers that they have to buy defensive registrations in every new domain. ICANN helps this along by mandating a sunrise period for each new domain in which the trademark crowd can make their claims before the hoi polloi are allowed in. In any event the question of to what extent a domain name is a trademark or other identifier with scope beyond the DNS has been argued and litigated for over a decade, and we're not going to resolve it here. Regards, John Levine, johnl at iecc.com, Primary Perpetrator of "The Internet for Dummies", Information Superhighwayman wanna-be, http://www.johnlevine.com, ex-Mayor "More Wiener schnitzel, please", said Tom, revealingly. From davids at webmaster.com Sat Jun 28 14:52:14 2008 From: davids at webmaster.com (David Schwartz) Date: Sat, 28 Jun 2008 12:52:14 -0700 Subject: what problem are we solving? (was Re: ICANN opens up Pandora'sBox of In-Reply-To: <200806281346.m5SDkX9b094171@aurora.sol.net> Message-ID: > Yes. It completely marginalizes the remaining positive qualities of the > Domain Name System as a way to find things, in the name of giving people > "more options." That never existed and never made any sense. DNS is a naming scheme. Entities choose names that are expressive, not informative. You may have a hard time remembering the name of the Chinese restaurant around the corner from you because it's not named "The Chinese Restaurant Around the Corner from Joe Greco", but naming businesses for your convenience is just not reasonable. What's convenient for you is not what's convenient for me. You should name the restaurant, for your purposes, with a name that is convenient for you. I'll do the same. If you and I have to exchange the name of a place, we need to map our convenient names to a proper name. But we don't normally have to use proper names, they're inconvenient. These type of mappings have to be competitive because different people have different requirements. If you want an easy way for you to find a company based on what you consider its name to be, find one that works for you. But DNS works differently, it maps *authoritative* names to businesses. It's more like how you map a business name to the responsible entity when you file a lawsuit. It has no business trying to be easy for humans to use and understand if that compromises its use for its actual purpose. > Let me start by saying that I believe that the trends in the DNS have been > going the wrong way for well over a decade. The insistence on the part of > many that the namespace be flattened is just a poor choice. > People are now > used to trying ".com" to reach a company. In some cases, this makes > fair sense; I can see why "ibm.com" or "seagate.com" are that way, even > though in some cases there are namespace collisions with other trademarks. > In others, it's ridiculous - why the heck do I get someplace in California > when I go to "martyspizza.com", rather than our local very excellent pizza > place? (sadly this example is less effective now, they managed to get > "martyspizza.net" a few years back). I agree. People should not do that. They should use some kind of mapping service that works for the kinds of mappings they expect. DNS is not that service, cannot be that service, and never will be that service. DNS is a technical service to map slow-changing authoritative names to their current numbers. > We never had any business allowing small, local businesses to register in > .com, or non-networking companies to register in .net, or > non-organizations > in .org... but a whole generation of Internet "professionals" > "knew better" > and the end result at the end of the road is that DNS will end up being > almost as useless as IPv4 numbers for identifying the more obscure bits of > the Internet. Which is fine since that's not what DNS is for. DNS maps slow-changing authoritative names to fast-changing numbers. I do agree that people do in practice use DNS this way. And I do agree that making it work worse for them is not the best thing in the world. But making a bad solution a bit worse is not a particularly big deal. People have almost completely stopped even exchanging URLs with each other manually. The exchange links specifically mapped through URL mapping services so that they're easier to communicate, or they put a link on a web page or in an email. DS From jra at baylink.com Sat Jun 28 14:54:50 2008 From: jra at baylink.com (Jay R. Ashworth) Date: Sat, 28 Jun 2008 15:54:50 -0400 Subject: Expired SSL cert for mms.nexteldata.net In-Reply-To: <48666068.3070706@cox.net> References: <20080628153317.GA29697@cgi.jachomes.com> <48666068.3070706@cox.net> Message-ID: <20080628195450.GA30404@cgi.jachomes.com> On Sat, Jun 28, 2008 at 11:01:44AM -0500, Laurence F. Sheldon, Jr. wrote: > Jay R. Ashworth wrote: > >According to my Blackberry, it expired last night at midnight UTC. > > Is this the end of the world, then? End of the world, no. Important to Nextel and any of their clients who receive MMS messages? Probably. Any reasonable way to clear the report on a Saturday, other than here? Nuh uh. I would expect that anyone with a phone stupider than a BB wouldn't have gotten a reasonable error message -- indeed, it took me three passes to figure it out. (For those playing along at home: MMS messages are sent as a specially formatted SMS -- or something very close to that -- containing a URL for the actual message body; this is why the phone might be retrieving across an SSL cert.) Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com '87 e24 St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 Those who cast the vote decide nothing. Those who count the vote decide everything. -- (Joseph Stalin) From mpetach at netflight.com Sat Jun 28 15:12:39 2008 From: mpetach at netflight.com (Matthew Petach) Date: Sat, 28 Jun 2008 13:12:39 -0700 Subject: ICANN opens up Pandora's Box of new TLDs In-Reply-To: <20080628185104.GA27290@gsp.org> References: <20080627120549.32616.qmail@simone.iecc.com> <20080628104854.GA30532@gsp.org> <20080628115653.GJ31980@catpipe.net> <20080628160603.GA16339@gsp.org> <20080628161844.GT31980@catpipe.net> <20080628185104.GA27290@gsp.org> Message-ID: <63ac96a50806281312i334c2067sce6872e324cbe5d1@mail.gmail.com> On 6/28/08, Rich Kulawiec wrote: > On Sat, Jun 28, 2008 at 06:18:44PM +0200, Phil Regnauld wrote: > > Rich Kulawiec (rsk) writes: ... > And given that any estimate of hijacked systems under 100 million is > laughably out-of-date, it's a best practice to blacklist ALL such IP > space and namespace pre-emptively. There's no point in waiting for > evidence of abuse to show up: it's inevitable. End user systems should > either be using their designated outbound mail relays *or* submitting on > other ports with authentication. > > > Probably bounces will be the next thing to disappear. > > Bounces *should* disappear, since it's a best practive to always reject > (during the SMTP conversation) and never bounce. Failure to do so leads > to outscatter, which is spam, and to blacklisting of the emitting hosts. Those two statements of yours directly contraindicate each other. If end user systems should use outbound mail relays, then the relay system is the one accepting the mail from the mail client, and will be responsible for sending out to the end system; it cannot make a determination as to whether the mail will be deliverable or not during the SMTP conversation with the client machine; it will only find out if the mail is actually deliverable when it in turn goes to establish an SMTP conversation with the receiving system, at which point if the receiving system indicates the message will not be deliverable, there is no way other than by generating a bounce message for the relay system to notify the original sender that the mail was undeliverable. Or, are you proposing that outbound mail relays hold the *client* connection state in limbo until they establish an outbound connection to the final destination, determine the deliverability of the final recipient, and *only then* acknowledge receipt of the message back to the client machine? If so, I think you may hear the distributed sound of every operator of outbound mail relay systems for ISPs of any scale *plonk*ing you in their "clueless" bucket. ^_^; In case it wasn't clear, a relay system like that simply won't scale at all, as the number of simultaneous pass-through connections required would increase as the ability to batch-process sending to common recipient systems would drop to near zero, End users would quickly cry foul and abandon operators who attempted such a system, as it would mean a slow-responding MTA box at the recipient end would hang their mail client as it waited to hear back from the relay host as to whether their attempt to send mail had succeeded or not. Until the entire concept of SMTP is replaced with something drastically different, along the lines of a real-time message passing system closer to IRC or IM, bounces are the only means for notifying a sender that a message could not be delivered. Matt From lists at internetpolicyagency.com Sat Jun 28 15:14:06 2008 From: lists at internetpolicyagency.com (Roland Perry) Date: Sat, 28 Jun 2008 21:14:06 +0100 Subject: what problem are we solving? (was Re: ICANN opens up Pandora's Box of new TLDs) In-Reply-To: References: <171423de0806271024h73e9a181t1df338aa5fe84ef5@mail.gmail.com> <4D0B482D-8FD5-48A5-9FF6-C2011AA7ACB5@virtualized.org> <20080628035954.BC78F213C3@spunkymail-a9.g.dreamhost.com> <4C0790EA-33E5-43F2-B281-215A0B37AE4F@virtualized.org> Message-ID: <5OIfW5aOupZIFA1A@perry.co.uk> In article , Frank Bulk - iNAME writes >One way to provide protection is too allow those who have the domain portion >of any domain.(com|net|org|...) to have first dibs for the domain of any new >gTLD. i.e. if nanog.org, nanog.com, nanog.net, etc. would have first dibs >on nanog.thisisgreatstuff. > >Or is that too simplistic and fraught with division? perry.com perry.net perry.org perry.eu (etc...) and one of mine: perry.co.uk All have different registrants. Now, what I did think this week in Paris, listening to all this stuff, was that maybe there could be one big race/auction for something like mytrademark.sunrise, and then all the sunrise periods of all the other new tlds should automatically import as a reserved name, all the mytrademarks (but if the registration wasn't taken up by the end of the sunrise period, it could be thrown back in the pot). -- Roland Perry From frnkblk at iname.com Sat Jun 28 15:20:29 2008 From: frnkblk at iname.com (Frank Bulk - iNAME) Date: Sat, 28 Jun 2008 15:20:29 -0500 Subject: the business model, was what problem are we solving? (was Re: ICANN opens In-Reply-To: <20080628193823.33104.qmail@simone.iecc.com> References: <20080628193823.33104.qmail@simone.iecc.com> Message-ID: That's the phrase I was thinking of -- "sunrise period". All of you would get first dibs -- I don't have a good idea how it would actually be doled out or purchased. But at least you three would be first in the ring, before speculator xyz had a chance. Frank -----Original Message----- From: John Levine [mailto:johnl at iecc.com] Sent: Saturday, June 28, 2008 2:38 PM To: nanog at nanog.org Cc: frnkblk at iname.com Subject: Re: the business model, was what problem are we solving? (was Re: ICANN opens >One way to provide protection is too allow those who have the domain portion >of any domain.(com|net|org|...) to have first dibs for the domain of any new >gTLD. i.e. if nanog.org, nanog.com, nanog.net, etc. would have first dibs >on nanog.thisisgreatstuff. > >Or is that too simplistic and fraught with division? I own iecc.com. A group of educators in Minnesota own iecc.org. A speculator in the UK owns iecc.net. Which, if any, of us gets first dibs on iecc.thisisgreatstuff? On the other hand, there is a school of thought voiced by the trademark lawyers that the main goal of new TLDs is to shake down trademark owners, who are advised by their lawyers that they have to buy defensive registrations in every new domain. ICANN helps this along by mandating a sunrise period for each new domain in which the trademark crowd can make their claims before the hoi polloi are allowed in. In any event the question of to what extent a domain name is a trademark or other identifier with scope beyond the DNS has been argued and litigated for over a decade, and we're not going to resolve it here. Regards, John Levine, johnl at iecc.com, Primary Perpetrator of "The Internet for Dummies", Information Superhighwayman wanna-be, http://www.johnlevine.com, ex-Mayor "More Wiener schnitzel, please", said Tom, revealingly. From johnl at iecc.com Sat Jun 28 16:03:39 2008 From: johnl at iecc.com (John Levine) Date: 28 Jun 2008 17:03:39 -0400 Subject: the business model, was what problem are we solving? (was Re: ICANN opens In-Reply-To: References: <20080628193823.33104.qmail@simone.iecc.com> Message-ID: > That's the phrase I was thinking of -- "sunrise period". > > All of you would get first dibs -- I don't have a good idea how it would > actually be doled out or purchased. But at least you three would be first > in the ring, before speculator xyz had a chance. But in my case, iecc.net already belongs to a speculator. Why would we give him preference? In any event, ICANN's sunrise rules work adequately well, and they're not likely to change. R's, John From lists at internetpolicyagency.com Sat Jun 28 16:31:29 2008 From: lists at internetpolicyagency.com (Roland Perry) Date: Sat, 28 Jun 2008 22:31:29 +0100 Subject: the business model, was what problem are we solving? (was Re: ICANN opens In-Reply-To: References: <20080628193823.33104.qmail@simone.iecc.com> Message-ID: In article , John Levine writes >In any event, ICANN's sunrise rules work adequately well, and they're >not likely to change. Sunrise rules differ for each tld, it's one of the things that differentiates them. In Paris this week there was a short talk aimed at future tld applicants, describing what "did and didn't work" about the sunrise periods of a selection of recent new tlds. http://par.icann.org/en/node/116 -- Roland Perry From rsk at gsp.org Sat Jun 28 16:34:33 2008 From: rsk at gsp.org (Rich Kulawiec) Date: Sat, 28 Jun 2008 17:34:33 -0400 Subject: ICANN opens up Pandora's Box of new TLDs In-Reply-To: <63ac96a50806281312i334c2067sce6872e324cbe5d1@mail.gmail.com> References: <20080627120549.32616.qmail@simone.iecc.com> <20080628104854.GA30532@gsp.org> <20080628115653.GJ31980@catpipe.net> <20080628160603.GA16339@gsp.org> <20080628161844.GT31980@catpipe.net> <20080628185104.GA27290@gsp.org> <63ac96a50806281312i334c2067sce6872e324cbe5d1@mail.gmail.com> Message-ID: <20080628213433.GA6744@gsp.org> On Sat, Jun 28, 2008 at 01:12:39PM -0700, Matthew Petach wrote: > Those two statements of yours directly contraindicate each other. No, they don't. Outbound relays (which are presumably used by client systems presenting appropriate authentication) know the identity of user presenting credentials. They can thus return a NDN (or similar) to that user, i.e., there's no concern about outscatter. But worth noting is that this works *because* the mail is being submitted with user authentication -- it won't work for a relay that doesn't do that. That's a very different situation from case where the same outbound relay is talking to a random mail server elsewhere on the 'net. Attempts by such random mail servers to "return" bounces to their origin (from when they never came) are outscatter, which is why rejects are much preferred. (Yes, I'm aware of various mail authentication proposals. Whatever they are/aren't, they're not the right solution to this specific problem: the solution is to always reject, never bounce.) ---Rsk From jfmezei at vaxination.ca Sat Jun 28 16:56:23 2008 From: jfmezei at vaxination.ca (=?ISO-8859-1?Q?Jean-Fran=E7ois_Mezei?=) Date: Sat, 28 Jun 2008 17:56:23 -0400 Subject: Mail Server best practices - was: Pandora's Box of new TLDs In-Reply-To: References: <20080628161844.GT31980@catpipe.net> <20080628180212.GA35151@catpipe.net> Message-ID: <4866B387.2070900@vaxination.ca> re: reverse DNS and emails. There are well documented and fairly simple tasks to reduce spam. requiring rdns, using rbls and blocking certain IP blocks goes a long way. The biggest problem however are outfits like microsoft whose hotmail/msn properties have undocumented logic which confirm reception of the message at the SMTP/821 level but then proceed to discard the email instead of delivering it to the person's inbox (or spam folder). Because they are unfortunatly popular, this means that sending email to users of those systems has become untrustable since you need to phone them to ensure they got the email. And it is impossible to talk to a "postmaster" at hotmail to know why hotmail sometimes/often doesn't like your emails even though you abide by standard rules. (rdns, spf etc) Spam getrs you more than you bargained for, but you still get your legitimate emails. But hotmail/MSN discard legitimate emails without warning and that makes SMTP untrustable and this is a far more serious issue. The original mantra of either discarding the email during SMTP conversation, or sending a non delivery notification should be strictly adhered to. When email becomes unreliable (thanks to microsoft), people stop using it. From jfmezei at vaxination.ca Sat Jun 28 17:19:19 2008 From: jfmezei at vaxination.ca (=?ISO-8859-1?Q?Jean-Fran=E7ois_Mezei?=) Date: Sat, 28 Jun 2008 18:19:19 -0400 Subject: the business model, was what problem are we solving? (was Re: ICANN opens In-Reply-To: <20080628193823.33104.qmail@simone.iecc.com> References: <20080628193823.33104.qmail@simone.iecc.com> Message-ID: <4866B8E7.9050407@vaxination.ca> John Levine wrote: > I own iecc.com. A group of educators in Minnesota own iecc.org. A > speculator in the UK owns iecc.net. Which, if any, of us gets first > dibs on iecc.thisisgreatstuff? Well, that would depend on whatever policies the owner of "thisisgreatstuff" has. More importantly, who gets first dibs at .iecc ????? Based on what I read, it will be the highest bidder. I have not seen wording that says that in cases of legitimate conflicts from existing domains, the .tld will be made unavailable period. Speculators won't be too happy with the busines potential for registering .iecc because in the end, only 3 customers will be interested in registering domains in that .tld, and if none of those have deep pockets, none of them will be interested in buying the .tld itself from the speculator. But conflicts will arise you have multiple legitimate owners of a trademark in different countries, and one of them has much deeper pockets than the others and will get the .tld for their trademark, thus devalueing/infringing on your trademark. I think that IANA should have long ago become quite strict with domain name registrations. .COM should have been only to companies operating worldwide. Websites that have portions of their site limited to local IPs (for instance BBC, and the USA networks like ABC CBS NBC, should be forced to use a "local" .TLD of their own country since they are no longer "world wide web". aka: www.abc.us instead of www.abc.com . If you want ".com" you need to be accessible worldwide. bbc.co.uk is fine because when you access it, you are aware it is a site designed for UK residents so when they tell you you can't access parts of their web site, you understand. But they shouldn't have "bbc.com" for that web site. Similarly, IANA could have setup rules so that new .TLDs would be handed out only when they have global scope, or if the tld defines a region (such as .asia or .europe). In other words, prevent a pizza place in dubai from buying the whole .PIZZA tld unless its goal is to make it available to all pizzerias around the world. From owenc at hubris.net Sat Jun 28 17:25:16 2008 From: owenc at hubris.net (Chris Owen) Date: Sat, 28 Jun 2008 17:25:16 -0500 Subject: Mail Server best practices - was: Pandora's Box of new TLDs In-Reply-To: <4866B387.2070900@vaxination.ca> References: <20080628161844.GT31980@catpipe.net> <20080628180212.GA35151@catpipe.net> <4866B387.2070900@vaxination.ca> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Jun 28, 2008, at 4:56 PM, Jean-Fran?ois Mezei wrote: > The biggest problem however are outfits like microsoft whose hotmail/ > msn > properties have undocumented logic which confirm reception of the > message at the SMTP/821 level but then proceed to discard the email > instead of delivering it to the person's inbox (or spam folder). At some point what is the difference between putting the mail into a spam folder and sending them to /dev/null? Yesterday I received 4,932 emails. 294 of those went into my inbox. 36 of those went info my quarantine folder. The other 4,602 went straight to /dev/null (actually many of them went through various blacklist building scripts first). Had I put the full 4,638 into a "spam folder" that would have been completely worthless. It would be impossible for me to actually review all those emails. Ultimately, there wouldn't be any difference between that and /dev/null. The only difference is I would have deleted them later rather than when they came in. So should I have bounced all 4,602? Since ninety some percent of them came from forged addresses that would not only be pointless but would be contributing to the problem (and get us into bl.spamcop.com). The size of the problem presented by spam is just enormous. Before we started selective greylisting, we used to accept a million messages a day. Of those we only delivered about 50,000. And that's for a system only handling about 5,000 email accounts. I can't even imagine having to do that on the scale hotmail is talking about. Chris ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Chris Owen ~ Garden City (620) 275-1900 ~ Lottery (noun): President ~ Wichita (316) 858-3000 ~ A stupidity tax Hubris Communications Inc www.hubris.net ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) Comment: Public Key: http://home.hubris.net/owenc/pgpkey.txt Comment: Public Key ID: 0xB513D9DD iEYEARECAAYFAkhmukwACgkQElUlCLUT2d0yNgCfRhVBqk3lo3X4p6pVJ8i32c4F MIEAn18tJAhIhgvWtIbuqLxFR7TKJB/q =Cump -----END PGP SIGNATURE----- From brandon at rd.bbc.co.uk Sat Jun 28 17:51:41 2008 From: brandon at rd.bbc.co.uk (Brandon Butterworth) Date: Sat, 28 Jun 2008 23:51:41 +0100 (BST) Subject: the business model, was what problem are we solving? (was Re: ICANN opens Message-ID: <200806282251.XAA12824@sunf10.rd.bbc.co.uk> > bbc.co.uk is fine because when you access it, you are aware it is a site > designed for UK residents so when they tell you you can't access parts > of their web site, you understand. But they shouldn't have "bbc.com" for > that web site. No need to tell us we shouldn't do what we're not doing bbc.co.uk is used for UK bbc.com is used for non UK and has adverts as you non UKers don't pay brandon From randy at psg.com Sat Jun 28 18:20:39 2008 From: randy at psg.com (Randy Bush) Date: Sun, 29 Jun 2008 08:20:39 +0900 Subject: Mail Server best practices - was: Pandora's Box of new TLDs In-Reply-To: References: <20080628161844.GT31980@catpipe.net> <20080628180212.GA35151@catpipe.net> <4866B387.2070900@vaxination.ca> Message-ID: <4866C747.1070008@psg.com> some folk on this list are network operators. i.e. what you do with your personal mailbox is not highly interesting. we have this silly problem called "paying users." the issue is what an mta operator does for hundreds, thousands, or more of these pesky critters. at least in my world, they seem to have significantly higher tolerance for 100 spams than one dropped ham. they may whine about blow-back from a joe job, but they will go bleeping nuts if they lose one message from a legitimate contact. and i suspect that this aversion to beta errors is not irrational; think postal mail. the issue, at least to me, is keeping mail drop alpha error reasonably low while keeping beta error as close to zero as possible. so please excuse me if i do not take talk about blocking some form of dns silliness, or a continent of ip addresses, or ... very seriously. we now return you to our regular channel of telling icann what it should do at layer fourteen, a subject on which we have deep expertise. randy From johnl at iecc.com Sat Jun 28 18:50:30 2008 From: johnl at iecc.com (John Levine) Date: 28 Jun 2008 23:50:30 -0000 Subject: Mail Server best practices - was: Pandora's Box of new TLDs In-Reply-To: Message-ID: <20080628235030.93146.qmail@simone.iecc.com> >So should I have bounced all 4,602? Since ninety some percent of them >came from forged addresses that would not only be pointless but would >be contributing to the problem (and get us into bl.spamcop.com). Of course not. You should have rejected them. Note that rejection doesn't keep you from using them to tune your filters. My MTA does much of its filtering at the end of data, and if it decides the message isn't going into the nominal recipient's mailbox, it returns a 553 status, then dumps the message into the spamtrap. R's, John From jgreco at ns.sol.net Sat Jun 28 21:31:33 2008 From: jgreco at ns.sol.net (Joe Greco) Date: Sat, 28 Jun 2008 21:31:33 -0500 (CDT) Subject: what problem are we solving? (was Re: ICANN opens up Pandora'sBox of In-Reply-To: from "David Schwartz" at Jun 28, 2008 12:52:14 PM Message-ID: <200806290231.m5T2VXob020706@aurora.sol.net> > > Yes. It completely marginalizes the remaining positive qualities of the > > Domain Name System as a way to find things, in the name of giving people > > "more options." > > That never existed and never made any sense. DNS is a naming scheme. > Entities choose names that are expressive, not informative. > > You may have a hard time remembering the name of the Chinese restaurant > around the corner from you because it's not named "The Chinese Restaurant > Around the Corner from Joe Greco", but naming businesses for your > convenience is just not reasonable. What's convenient for you is not what's > convenient for me. I never said it was. I'm not arguing for me to be able to rename someone else's business. > You should name the restaurant, for your purposes, with a name that is > convenient for you. I'll do the same. If you and I have to exchange the name > of a place, we need to map our convenient names to a proper name. But we > don't normally have to use proper names, they're inconvenient. > > These type of mappings have to be competitive because different people have > different requirements. If you want an easy way for you to find a company > based on what you consider its name to be, find one that works for you. I do not "consider its name to be" some random thing. I consider it to be what it calls itself. There are already rules for that sort of thing outside of the Internet, for example, I am not allowed to create a company name that duplicates a company name that already exists. The problem is that while I can go and register a "Mycompany LLC" in Wisconsin and a "Mycompany LLC" in Illinois, there is only one "mycompany.com" available, though "mycompany.wi.us" and "mycompany.il.us" are both available and do not collide. > But DNS works differently, it maps *authoritative* names to businesses. It's > more like how you map a business name to the responsible entity when you > file a lawsuit. It has no business trying to be easy for humans to use and > understand if that compromises its use for its actual purpose. That's one hell of an if, and it doesn't seem to even be true. If you read 805 and other foundation documents, it seems clear that the goal was to *replace* a difficult-to-use mail relaying and routing scheme for mail addresses with something that was easier for ... ah, yes, users to use. > > Let me start by saying that I believe that the trends in the DNS have been > > going the wrong way for well over a decade. The insistence on the part of > > many that the namespace be flattened is just a poor choice. > > People are now > > used to trying ".com" to reach a company. In some cases, this makes > > fair sense; I can see why "ibm.com" or "seagate.com" are that way, even > > though in some cases there are namespace collisions with other trademarks. > > In others, it's ridiculous - why the heck do I get someplace in California > > when I go to "martyspizza.com", rather than our local very excellent pizza > > place? (sadly this example is less effective now, they managed to get > > "martyspizza.net" a few years back). > > I agree. People should not do that. They should use some kind of mapping > service that works for the kinds of mappings they expect. DNS is not that > service, cannot be that service, and never will be that service. That's not true. Perhaps you should go read RFC1480. (Before you make any comments, you should be aware that I *have* read 1480, and that one of the hosts used as an example in that document is currently running 50 feet away from me). For example, I *ought* to be able to find the Police Department for the City of Milwaukee at something reasonable, such as "police.ci.milwaukee.wi.us". If I then needed the police for Wauwatosa, "police.ci.wauwatosa.wi.us", or for Waukesha, "police.ci.waukesha.wi.us". 1480 is about trying to provide localization services that could ultimately result in a namespace containing vastly fewer collision issues. But to understand what I'm talking about, you really have to get rid of the ".com" mentality first. To extend that principle, companies that have an exclusively local presence probably don't need to be occupying space in a TLD. That's the Marty's Pizza example. > DNS is a technical service to map slow-changing authoritative names to their > current numbers. Which are also generally slow-changing. > > We never had any business allowing small, local businesses to register in > > .com, or non-networking companies to register in .net, or > > non-organizations > > in .org... but a whole generation of Internet "professionals" > > "knew better" > > and the end result at the end of the road is that DNS will end up being > > almost as useless as IPv4 numbers for identifying the more obscure bits of > > the Internet. > > Which is fine since that's not what DNS is for. > > DNS maps slow-changing authoritative names to fast-changing numbers. No, DNS is intended to map logical names, which are, among other things, supposed to be usable and useful to humans. "[W]e wish to create consistent methods for referencing particular resources that are similar but scattered throughout the environment." That 25-year old statement is still a nice summary of the purpose of DNS. The idea is that you can try for consistency, and where consistency is reasonable and possible, some of us still believe that it could exist. > I do agree that people do in practice use DNS this way. And I do agree that > making it work worse for them is not the best thing in the world. But making > a bad solution a bit worse is not a particularly big deal. People have > almost completely stopped even exchanging URLs with each other manually. The > exchange links specifically mapped through URL mapping services so that > they're easier to communicate, or they put a link on a web page or in an > email. I don't see what you're saying as supporting ICANN's actions. If DNS is irrelevant for these purposes, then why bother "making a bad solution a bit worse." Just let it become, over the next 25 years, some mid-level directory resource that users see less and less of, until it's almost as irrelevant as IP address. (*I* don't buy that, but then again, I'm making the argument that we've really screwed up with DNS) ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From bortzmeyer at nic.fr Sun Jun 29 04:45:42 2008 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Sun, 29 Jun 2008 11:45:42 +0200 Subject: ICANN opens up Pandora's Box of new TLDs In-Reply-To: <48640FC2.2000909@spaghetti.zurich.ibm.com> References: <7ff145960806261309u4eda28b7v8973556b983df63a@mail.gmail.com> <5429E6E0-382A-4711-8D8C-2A241B6E4F6A@mailchannels.com> <48640FC2.2000909@spaghetti.zurich.ibm.com> Message-ID: <20080629094542.GA10417@sources.org> On Thu, Jun 26, 2008 at 11:53:06PM +0200, Jeroen Massar wrote a message of 49 lines which said: > not even thinking of all the nice security issues which come along > (home, mycomputer and .exe etc anyone ? This requires serious elaboration. How could you use a domain in ".exe" to actually attack someone? (No handwaving, please, actual study.) > Thank you people doing all the ICANN politics for destroying the Internet. The Internet, until now, resisted to forces much more powerful than ICANN. From fernando at gont.com.ar Sun Jun 29 06:12:02 2008 From: fernando at gont.com.ar (Fernando Gont) Date: Sun, 29 Jun 2008 08:12:02 -0300 Subject: IPv4 source routing options and IPv6 Type 0 Routing Header In-Reply-To: <48633AD2.4040301@psg.com> References: <200806250758.m5P7wen1027990@venus.xmundo.net> <4862AE02.6030201@ai.net> <200806260208.m5Q28Gqq019433@venus.xmundo.net> <48633AD2.4040301@psg.com> Message-ID: <200806291115.m5TBFBAU030530@venus.xmundo.net> At 03:44 a.m. 26/06/2008, Randy Bush wrote: >source routing is still requested and sometimes mandated at inter-as >borders. for the reasons deepak stated. note that this does not expose >any vulnerability. source routing is only dangerous to hosts. Well, it can be used as an amplification mechanism for bandwidth consuption attacks (although it is not as effective as the Type 0 Routing header of v6, because of the limited space in the v4 header). Thanks! Kind regards, -- Fernando Gont e-mail: fernando at gont.com.ar || fgont at acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From rsk at gsp.org Sun Jun 29 06:22:33 2008 From: rsk at gsp.org (Rich Kulawiec) Date: Sun, 29 Jun 2008 07:22:33 -0400 Subject: Mail Server best practices - was: Pandora's Box of new TLDs In-Reply-To: <4866B387.2070900@vaxination.ca> References: <20080628161844.GT31980@catpipe.net> <20080628180212.GA35151@catpipe.net> <4866B387.2070900@vaxination.ca> Message-ID: <20080629112233.GA1761@gsp.org> On Sat, Jun 28, 2008 at 05:56:23PM -0400, Jean-Fran?ois Mezei wrote: > The original mantra of either discarding the email during SMTP > conversation, or sending a non delivery notification should be strictly > adhered to. When email becomes unreliable (thanks to microsoft), people > stop using it. I agree with your sentiments -- that notification is essential in order to provide a heads-up about problems (and that once problems are noticed, cooperation is essential in order to fix them). But mail should never be discarded without notice, and NDN's should never be sent (MTA-to-MTA, which is a different matter than MSA-to-MTA): it should either be accepted (and delivered) or rejected (and not delivered). This provides accurate notification to the sending MTA of the disposition of the message, and it avoids outscatter spam. Of course, this doesn't do anything to elicit cooperation from either side, but at least it makes problems visible (provided nobody's MTA mangles or drops the reject notice) so that there's a decent chance of figuring *whose* cooperation is needed. ---Rsk From brandon at rd.bbc.co.uk Sun Jun 29 06:34:05 2008 From: brandon at rd.bbc.co.uk (Brandon Butterworth) Date: Sun, 29 Jun 2008 12:34:05 +0100 (BST) Subject: what problem are we solving? (was Re: ICANN opens up Pandora'sBox of Message-ID: <200806291134.MAA12269@sunf10.rd.bbc.co.uk> > The problem is > that while I can go and register a "Mycompany LLC" in Wisconsin and a > "Mycompany LLC" in Illinois, there is only one "mycompany.com" available, > though "mycompany.wi.us" and "mycompany.il.us" are both available and do > not collide. 1. register .local [1] 3. n * profit! brandon [1] I know From john-nanog at johnpeach.com Sun Jun 29 07:42:12 2008 From: john-nanog at johnpeach.com (John Peach) Date: Sun, 29 Jun 2008 08:42:12 -0400 Subject: Mail Server best practices - was: Pandora's Box of new TLDs In-Reply-To: References: <20080628161844.GT31980@catpipe.net> <20080628180212.GA35151@catpipe.net> <4866B387.2070900@vaxination.ca> Message-ID: <20080629084212.04d8a9a4@milhouse.peachfamily.net> On Sat, 28 Jun 2008 17:25:16 -0500 Chris Owen wrote: [snip] > > So should I have bounced all 4,602? Since ninety some percent of > them came from forged addresses that would not only be pointless but > would be contributing to the problem (and get us into bl.spamcop.com). > Of course you shouldn't accept and bounce them; you should not accept them at all. Reject them up front. -- John From marquis at roble.com Sun Jun 29 09:55:07 2008 From: marquis at roble.com (Roger Marquis) Date: Sun, 29 Jun 2008 07:55:07 -0700 (PDT) Subject: Mail Server best practices - was: Pandora's Box of new TLDs In-Reply-To: References: Message-ID: <20080629145507.D40D72B7C00@mx5.roble.com> Rich Kulawiec wrote: > notification is essential in order to provide a heads-up about > problems (and that once problems are noticed, cooperation is > essential in order to fix them). But mail should never be > discarded without notice In practice we've found that (notification) is the core issue. Reject v discard is a non-issue by comparison. The format of those notifications does not have to be a spam folder, as many seem to assume. A summary report serves the purpose far better than tagging and delivery with far less overhead. Quoting : The only reliable way to avoid false-positives is by monitoring the email server or gateway logs and allowing end-users to receive a daily report of email sent to their account that was identified as spam and filtered. This is more or less identical to the issue ISP's like Comcast face when implementing QOS or other filtering, when they fail to notify end-users. Backscatter / NDNs are another issue. In practice they are no longer feasible without assurance that the sender is both valid and legitimate. Bounces without these validations are usually spam and will get your server blacklisted. Roger Marquis From bortzmeyer at nic.fr Sun Jun 29 11:32:13 2008 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Sun, 29 Jun 2008 18:32:13 +0200 Subject: ICANN opens up Pandora's Box of new TLDs In-Reply-To: References: <7ff145960806261309u4eda28b7v8973556b983df63a@mail.gmail.com> <5429E6E0-382A-4711-8D8C-2A241B6E4F6A@mailchannels.com> <20080627024941.GA29345@gsp.org> Message-ID: <20080629163213.GB10417@sources.org> On Thu, Jun 26, 2008 at 10:37:34PM -0500, Frank Bulk - iNAME wrote a message of 37 lines which said: > ...which is why it might be a strategy to blacklist all new TLDs (if > this proposal gets through) and whitelist just .com, .net, etc. Interesting. I do not know if this strategy will be implemented or not but, if it is, it will be a big change in Internet governance. No longer will the TLDs in the root be decided by ICANN or by its master, the US government, but they will have to be "vetted" by an informal group of network operators. A boycott by this group could have devastating effects for a business. We already see this in the email world, where a self-appointed cartel like the MAAWG can decide technical rules and policies, bypassing both IETF and ICANN. Even if only one half of the big operators enforce these rules, they will become de facto regulations, since noone can afford to have his email refused by this half. (To take a recent example, I configure rDNS on every email server I managed, even if I find the rule stupid and unfair, because I have no choice.) It will be an interesting turn back to the european cities of the Middle Age, with guilds approving (or, more often, disapproving) every technical or business novelty... From tme at multicasttech.com Sun Jun 29 11:39:00 2008 From: tme at multicasttech.com (Marshall Eubanks) Date: Sun, 29 Jun 2008 12:39:00 -0400 Subject: ICANN opens up Pandora's Box of new TLDs In-Reply-To: <20080629094542.GA10417@sources.org> References: <7ff145960806261309u4eda28b7v8973556b983df63a@mail.gmail.com> <5429E6E0-382A-4711-8D8C-2A241B6E4F6A@mailchannels.com> <48640FC2.2000909@spaghetti.zurich.ibm.com> <20080629094542.GA10417@sources.org> Message-ID: <84DF81D2-C164-4F2A-AC27-73C1A180072B@multicasttech.com> On Jun 29, 2008, at 5:45 AM, Stephane Bortzmeyer wrote: > On Thu, Jun 26, 2008 at 11:53:06PM +0200, > Jeroen Massar wrote > a message of 49 lines which said: > >> not even thinking of all the nice security issues which come along >> (home, mycomputer and .exe etc anyone ? > > This requires serious elaboration. How could you use a domain in > ".exe" to actually attack someone? (No handwaving, please, actual > study.) > I think it would be the other way around - I would assume that that was a near worthless TLD, as it would come with a built in DOS : If I had (say) program.exe as a domain name, what Windows user would ever type it in ? Regards Marshall >> Thank you people doing all the ICANN politics for destroying the >> Internet. > > The Internet, until now, resisted to forces much more powerful than > ICANN. > > > > > From rsk at gsp.org Sun Jun 29 11:50:36 2008 From: rsk at gsp.org (Rich Kulawiec) Date: Sun, 29 Jun 2008 12:50:36 -0400 Subject: Mail Server best practices - was: Pandora's Box of new TLDs In-Reply-To: <20080629145507.D40D72B7C00@mx5.roble.com> References: <20080629145507.D40D72B7C00@mx5.roble.com> Message-ID: <20080629165036.GA15547@gsp.org> On Sun, Jun 29, 2008 at 07:55:07AM -0700, Roger Marquis wrote: > Quoting : > > The only reliable way to avoid false-positives is by monitoring > the email server or gateway logs and allowing end-users to receive > a daily report of email sent to their account that was identified > as spam and filtered. Two comments: First, it is impossible to avoid false positives (unless you turn all spam filtering off) or false negatives (unless you block everything). The discussion thus shouldn't focus on 0% FP, 0% FN, but on how to minimize both simultaneously such that the percentages are acceptable to the receiving organization. (Note as well that FP and FN are always defined on recipient side, never the sender side.) Second, while in principle this isn't a bad approach, in reality it tends not to work well. It requires that users weed through the daily reports (which they won't) and determine what's spam/not-spam (which they'll get wrong) and it requires accepting and storing considerable volumes of mail which are likely spam/phish/virus/etc. It also can make FP detection difficult, since senders do not get a reject (mail was accepted, after all; why should they?) and thus may be unaware that their message was dropped in a probable-spam folder. I find it's much better to reject outright with a very clear error message (that provides recourse for senders who believe it to be in error) and then address the resulting issues at the postmaster level (since in most environments such issues are likely to effect more than one user). ---Rsk From ml at t-b-o-h.net Sun Jun 29 12:13:27 2008 From: ml at t-b-o-h.net (Tuc at T-B-O-H.NET) Date: Sun, 29 Jun 2008 13:13:27 -0400 (EDT) Subject: ICANN opens up Pandora's Box of new TLDs In-Reply-To: <84DF81D2-C164-4F2A-AC27-73C1A180072B@multicasttech.com> Message-ID: <200806291713.m5THDR6g060037@himinbjorg.tucs-beachin-obx-house.com> > > This requires serious elaboration. How could you use a domain in > > ".exe" to actually attack someone? (No handwaving, please, actual > > study.) > > > > I think it would be the other way around - I would assume that that > was a near worthless TLD, as it > would come with a built in DOS : If I had (say) program.exe as a > domain name, > what Windows user would ever type it in ? > I think this would be one of the TLDs that they'd refuse. Then again, there are DOS commands that do end in .com (CHOICE, COMMAND, CMD, DISKCOMP, HELP,etc). More can be seen at : http://support.microsoft.com/kb/72188 Tuc/TBOH From beckman at angryox.com Sun Jun 29 12:21:07 2008 From: beckman at angryox.com (Peter Beckman) Date: Sun, 29 Jun 2008 13:21:07 -0400 Subject: what problem are we solving? (was Re: ICANN opens up Pandora'sBox of In-Reply-To: <200806290231.m5T2VXob020706@aurora.sol.net> References: <200806290231.m5T2VXob020706@aurora.sol.net> Message-ID: On Sat, 28 Jun 2008, Joe Greco wrote: > For example, I *ought* to be able to find the Police Department for the City > of Milwaukee at something reasonable, such as "police.ci.milwaukee.wi.us". > If I then needed the police for Wauwatosa, "police.ci.wauwatosa.wi.us", or > for Waukesha, "police.ci.waukesha.wi.us". > > To extend that principle, companies that have an exclusively local presence > probably don't need to be occupying space in a TLD. That's the Marty's > Pizza example. martyspizza.brookfield.wi.us works great. At what point in Marty's expansion does Marty's Pizza get to move to a TLD? The RFC leaves management decisions to an alluded to but unnamed group. Plus, WTF: John-Muir.Middle.Santa-Monica.K12.CA.US Cut and Paste or die trying. I doubt parents will remember or type that. Besides, sophisticated search engines are making Domain Names less relevant anyway. I can find Marty's Pizza in Brookfield via Google or Yahoo in a matter of seconds. Let the search engines organize the web, not DNS. Schools are going short and sweet, just like businesses, using the existing TLDs. martyspizza.net is fine. So is johnmuirsl.org. No need for 30 more or 3000 more TLDs. Beckman --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com http://www.angryox.com/ --------------------------------------------------------------------------- From jabley at ca.afilias.info Sun Jun 29 13:14:58 2008 From: jabley at ca.afilias.info (Joe Abley) Date: Sun, 29 Jun 2008 14:14:58 -0400 Subject: what problem are we solving? (was Re: ICANN opens up Pandora'sBox of In-Reply-To: <200806290231.m5T2VXob020706@aurora.sol.net> References: <200806290231.m5T2VXob020706@aurora.sol.net> Message-ID: <393FF04B-6BDC-41CE-BCF3-97FC6D0226A2@ca.afilias.info> On 28 Jun 2008, at 22:31, Joe Greco wrote: > For example, I *ought* to be able to find the Police Department for > the City > of Milwaukee at something reasonable, such as > "police.ci.milwaukee.wi.us". > If I then needed the police for Wauwatosa, > "police.ci.wauwatosa.wi.us", or > for Waukesha, "police.ci.waukesha.wi.us". About as much as I ought to be able to reach the Canadian army at army.mil, or the Canadian Citizenship and Immigration department at cic.gov. There is no single namespace that makes sense for everybody. For every single person who says "I ought to be able to do X to find Y" there will be someone else for whom Y would be a surprising result for X. The boat sailed on enforcing regulations for appropriate registrations under particular TLDs long ago. I remember when registering a .NET name for a small, south-western Ontario ISP in about 1995 being told "sorry, that TLD is for ISPs only" and having to prove that I was, in fact, working for an ISP before I could get the delegation. Imagine that happening now? The DNS had its origins in a desire to use names instead of addresses, because names are easier to remember. But really, the fact that naive users type raw URLs into browsers is an indication that we have more work to do, not that naive users will always need to be exposed to raw URLs. We are already at the point where a significant proportion of the Internet population types names into Google or Yahoo! or Microsoft Live Search, and never reference URLs in the raw unless they are accessed through bookmarks. An increasing number of people use Facebook more for e-mail than they use e-mail for e-mail. If this is a trend, then perhaps we can imagine the day where the average Internet user pays about as much attention to domain names as they do to IP addresses today. All these conversations about what should or should not be possible in the namespace are pointless. The degrees of freedom are too enormous for any single person or organisation to be able to make even a vaguely accurate guess at what the stable state should be. The only decision that is required is whether new generic top-level domains are desired. If not, do nothing. Otherwise, shake as much energy into the system as possible and sit back and let it find its own steady state. Joe From johnl at iecc.com Sun Jun 29 13:44:11 2008 From: johnl at iecc.com (John Levine) Date: 29 Jun 2008 18:44:11 -0000 Subject: Internet management, was ICANN opens up Pandora's Box of new TLDs In-Reply-To: <20080629163213.GB10417@sources.org> Message-ID: <20080629184411.67007.qmail@simone.iecc.com> >We already see this in the email world, where a self-appointed cartel >like the MAAWG can decide technical rules and policies, bypassing >both IETF and ICANN. As an active participant in both the IETF and MAAWG, and a former member of the ICANN ALAC, I can assure you that MAAWG would be delighted to stop publishing its own BCPs about email and abuse management, reflecting the experience of the largest mail systems on the planet, if the IETF or ICANN would get their heads out of their navels and do so. A mail system configured according to current RFCs would be useless, since nobody would be able to find the trickle of legit mail in the torrent of spam, even assuming the mail system didn't melt down from the load. > I configure rDNS on every email server I managed, even if I > find the rule stupid and unfair, because I have no choice. All those mean old ISPs are, in case you hadn't noticed, delivering the mail you send them for free. If you find it too much trouble to configure your DNS in accordance with STD 13, which has been around for over 20 years, I expect they'll also find it too much trouble to try and tell your mail apart from the 99.999% of no-rDNS hosts that are spambots. Spam sucks, complaining about it won't make it go away. Indeed, the reason we're making so little progress against it is that far too many people just complain and expect someone else to solve the problem. R's, John From dot at dotat.at Sun Jun 29 13:49:51 2008 From: dot at dotat.at (Tony Finch) Date: Sun, 29 Jun 2008 19:49:51 +0100 Subject: ICANN opens up Pandora's Box of new TLDs In-Reply-To: <20080629163213.GB10417@sources.org> References: <7ff145960806261309u4eda28b7v8973556b983df63a@mail.gmail.com> <5429E6E0-382A-4711-8D8C-2A241B6E4F6A@mailchannels.com> <20080627024941.GA29345@gsp.org> <20080629163213.GB10417@sources.org> Message-ID: On Sun, 29 Jun 2008, Stephane Bortzmeyer wrote: > > We already see this in the email world, where a self-appointed cartel > like the MAAWG can decide technical rules and policies, bypassing both > IETF and ICANN. Even if only one half of the big operators enforce > these rules, they will become de facto regulations, since noone can > afford to have his email refused by this half. The IETF is not good at specifying operational best practice and usually avoids trying to do so, but even so, the MAAWG recommendations are in line with what most IETF email experts think. AFAIK ICANN has no remit to say anything about email. Tony. -- f.anthony.n.finch http://dotat.at/ FAEROES SOUTHEAST ICELAND: CYCLONIC 5 TO 7, OCCASIONALLY GALE 8. ROUGH OR VERY ROUGH. RAIN OR SHOWERS. MODERATE OR GOOD, OCCASIONALLY POOR. From bortzmeyer at nic.fr Sun Jun 29 14:57:09 2008 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Sun, 29 Jun 2008 21:57:09 +0200 Subject: ICANN opens up Pandora's Box of new TLDs In-Reply-To: <20080627203205.51B612B7C02@mx5.roble.com> References: <20080627203205.51B612B7C02@mx5.roble.com> Message-ID: <20080629195709.GA1569@sources.org> On Fri, Jun 27, 2008 at 01:32:05PM -0700, Roger Marquis wrote a message of 22 lines which said: > Security-aware programmers will now be unable to apply even cursory > tests for domain name validity. I am very curious of what tests a "security-aware programmer" can do, based on the domain name, which will not be possible tomorrow, should ICANN allow a few more TLDs. If you test that the TLD exists... it will still work. If you test that the name matches (com|net|org|[a-z]{2}), then you are not what I would call a "security-aware programmer". > requiring valid domain contacts. ICANN does require valid contacts. And it requires them to be published and sold. So, people lie to protect their privacy. In the world of security, stupid ideas often backfire. > I have to conclude that ICANN has failed, simply failed, and should be > returned to the US government. It never leaved it. From bortzmeyer at nic.fr Sun Jun 29 15:02:48 2008 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Sun, 29 Jun 2008 22:02:48 +0200 Subject: what problem are we solving? (was Re: ICANN opens up Pandora's Box of new TLDs) In-Reply-To: <171423de0806271024h73e9a181t1df338aa5fe84ef5@mail.gmail.com> References: <171423de0806271024h73e9a181t1df338aa5fe84ef5@mail.gmail.com> Message-ID: <20080629200248.GB1569@sources.org> On Fri, Jun 27, 2008 at 10:24:48AM -0700, Scott Francis wrote a message of 32 lines which said: > what problem is ICANN trying to solve with this > proposal? What about the current system that's broken, does this new > system fix? ICANN is simply responding to demand. Some people want to create a TLD. The existence of a TLD is not a problem for the other TLDs. If the new TLD is stupid or useless (like ".aero" or ".pro"), it will fail. So what? That's the normal life of projects. Why ICANN should evaluate the new TLD applications, apart from some simple technical checks? If something is wanted and causes no harm for the others, then why in hell ICANN should refuse it? I did not suspect that the idea of central regulation of business, with a state-like committee examining business ideas and allowing them or not, was an idea so popular among Nanog members :-) From bortzmeyer at nic.fr Sun Jun 29 15:12:35 2008 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Sun, 29 Jun 2008 22:12:35 +0200 Subject: the business model, was what problem are we solving? (was Re: ICANN opens In-Reply-To: <4866B8E7.9050407@vaxination.ca> References: <20080628193823.33104.qmail@simone.iecc.com> <4866B8E7.9050407@vaxination.ca> Message-ID: <20080629201235.GE1569@sources.org> On Sat, Jun 28, 2008 at 06:19:19PM -0400, Jean-Fran?ois Mezei wrote a message of 47 lines which said: > I think that IANA should have long ago become quite strict with > domain name registrations. .COM should have been only to companies > operating worldwide. Wow, ".fr", like many ccTLDs, spent a lot of time and money in this Soviet-style regulation a long time ago. We checked business records, asked customers for more paper, refused applications... As an obvious result, many people choosed ".com" over ".fr". In several steps (2000, 2004 and 2006), ".fr" relaxed its rules so, now, there is no human checking. Most other ccTLDs did the same at this time or before. Should ".com" had rules like the one you suggest (how do you check a business record from a company in Thailand? Or in Tadjikistan?) ".fr" would have had been in better position against it :-) From bortzmeyer at nic.fr Sun Jun 29 15:08:26 2008 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Sun, 29 Jun 2008 22:08:26 +0200 Subject: Mail Server best practices - was: Pandora's Box of new TLDs In-Reply-To: References: <20080628161844.GT31980@catpipe.net> <20080628180212.GA35151@catpipe.net> <4866B387.2070900@vaxination.ca> Message-ID: <20080629200826.GD1569@sources.org> [Wow, operational content!] On Sat, Jun 28, 2008 at 05:25:16PM -0500, Chris Owen wrote a message of 53 lines which said: > At some point what is the difference between putting the mail into a > spam folder and sending them to /dev/null? To me, there is a huge difference. I send no mail to Dave Null, everything goes into a spam folder. Do I read it? Do I review it from time to time? Never. It is too huge. So, what's the point besides bringing money to hard disk manufacturers? It is because, if someone reports (by telephone, IRC or IRL) that he sent an email and I did not receive it, I regard as VERY IMPORTANT to be able to check the spam folder (with a search tool, not by hand) and go back to him saying "No, we really did not receive it". In a professional environment, I would not accept the idea of email disappearing without being able to recover it. From yahoo at jimpop.com Sun Jun 29 15:20:16 2008 From: yahoo at jimpop.com (Jim Popovitch) Date: Sun, 29 Jun 2008 16:20:16 -0400 Subject: what problem are we solving? (was Re: ICANN opens up Pandora'sBox of In-Reply-To: References: <200806290231.m5T2VXob020706@aurora.sol.net> Message-ID: <7ff145960806291320x4a768f62x31cf7262ae945b6f@mail.gmail.com> On Sun, Jun 29, 2008 at 1:21 PM, Peter Beckman wrote: > Let the search engines organize the web, not DNS. OK, (assuming you believe that), why keep dns around. Why not go back to just IP addrs and hosts files for those that need them. -Jim P. From mack at exchange.alphared.com Sun Jun 29 15:25:10 2008 From: mack at exchange.alphared.com (mack) Date: Sun, 29 Jun 2008 15:25:10 -0500 Subject: NANOG Digest, Vol 5, Issue 92 In-Reply-To: References: Message-ID: <6F2FFD7C10F788479E354B84294036C42134F8F3@EXCH-MBX.exchange.alphared.local> > > Message: 7 > Date: Sat, 28 Jun 2008 21:31:33 -0500 (CDT) > From: Joe Greco > Subject: Re: what problem are we solving? (was Re: ICANN opens up > Pandora'sBox of > To: davids at webmaster.com > Cc: nanog at nanog.org > Message-ID: <200806290231.m5T2VXob020706 at aurora.sol.net> > Content-Type: text/plain; charset=us-ascii > [snip] > > I don't see what you're saying as supporting ICANN's actions. If DNS > is > irrelevant for these purposes, then why bother "making a bad solution a > bit > worse." Just let it become, over the next 25 years, some mid-level > directory resource that users see less and less of, until it's almost > as > irrelevant as IP address. One could make the argument this is already the case. If I want to find a particular web site for a specific local company, I usually search in google rather than try and find the web site by guessing the name. So in reality the web site name is already irrelevant for local small businesses. For large national and international companies, we can mostly depend on .com mapping correctly as they have spent large sums of money protecting their brands. Ie. mcdonalds.com maps to the fast food joint rather than some other family owned business. In 25 years a name will map to .com or be irrelevant with the current proposal. I would be happy to be proven wrong but time will tell. > > (*I* don't buy that, but then again, I'm making the argument that we've > really screwed up with DNS) > > ... JG > -- > Joe Greco - sol.net Network Services - Milwaukee, WI - > http://www.sol.net > "We call it the 'one bite at the apple' rule. Give me one chance [and] > then I > won't contact you again." - Direct Marketing Ass'n position on e-mail > spam(CNN) > With 24 million small businesses in the US alone, that's way too many > apples. > -- LR Mack McBride Network Administrator Alpha Red, Inc. From frnkblk at iname.com Sun Jun 29 15:30:15 2008 From: frnkblk at iname.com (Frank Bulk - iNAME) Date: Sun, 29 Jun 2008 15:30:15 -0500 Subject: Mail Server best practices - was: Pandora's Box of new TLDs In-Reply-To: <20080629200826.GD1569@sources.org> References: <20080628161844.GT31980@catpipe.net> <20080628180212.GA35151@catpipe.net> <4866B387.2070900@vaxination.ca> <20080629200826.GD1569@sources.org> Message-ID: You mean, you don't employ *any* spam mitigation techniques besides sorting? Because if you do anything, even as basic as RBLs, you're not being consistent with your stance. Frank -----Original Message----- From: Stephane Bortzmeyer [mailto:bortzmeyer at nic.fr] Sent: Sunday, June 29, 2008 3:08 PM To: Chris Owen Cc: nanog Subject: Re: Mail Server best practices - was: Pandora's Box of new TLDs [Wow, operational content!] On Sat, Jun 28, 2008 at 05:25:16PM -0500, Chris Owen wrote a message of 53 lines which said: > At some point what is the difference between putting the mail into a > spam folder and sending them to /dev/null? To me, there is a huge difference. I send no mail to Dave Null, everything goes into a spam folder. Do I read it? Do I review it from time to time? Never. It is too huge. So, what's the point besides bringing money to hard disk manufacturers? It is because, if someone reports (by telephone, IRC or IRL) that he sent an email and I did not receive it, I regard as VERY IMPORTANT to be able to check the spam folder (with a search tool, not by hand) and go back to him saying "No, we really did not receive it". In a professional environment, I would not accept the idea of email disappearing without being able to recover it. From LarrySheldon at cox.net Sun Jun 29 15:21:09 2008 From: LarrySheldon at cox.net (Laurence F. Sheldon, Jr.) Date: Sun, 29 Jun 2008 15:21:09 -0500 Subject: Mail Server best practices - was: Pandora's Box of new TLDs In-Reply-To: <20080629200826.GD1569@sources.org> References: <20080628161844.GT31980@catpipe.net> <20080628180212.GA35151@catpipe.net> <4866B387.2070900@vaxination.ca> <20080629200826.GD1569@sources.org> Message-ID: <4867EEB5.70903@cox.net> Stephane Bortzmeyer wrote: > It is because, if someone reports (by telephone, IRC or IRL) that he > sent an email and I did not receive it, I regard as VERY IMPORTANT to > be able to check the spam folder (with a search tool, not by hand) and > go back to him saying "No, we really did not receive it". > > In a professional environment, I would not accept the idea of email > disappearing without being able to recover it. In my view of a "professional environment" (what ever that turns out to mean) a log file would enable that, without any of the problems holding mail text might engender. "Did you get the email from...to...? "Yes" "Please tell the court what it said." -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs From ge at linuxbox.org Sun Jun 29 15:36:47 2008 From: ge at linuxbox.org (Gadi Evron) Date: Sun, 29 Jun 2008 15:36:47 -0500 (CDT) Subject: ICANN opens up Pandora's Box of new TLDs In-Reply-To: <200806291713.m5THDR6g060037@himinbjorg.tucs-beachin-obx-house.com> References: <200806291713.m5THDR6g060037@himinbjorg.tucs-beachin-obx-house.com> Message-ID: On Sun, 29 Jun 2008, Tuc at T-B-O-H.NET wrote: >>> This requires serious elaboration. How could you use a domain in >>> ".exe" to actually attack someone? (No handwaving, please, actual >>> study.) >>> >> >> I think it would be the other way around - I would assume that that >> was a near worthless TLD, as it >> would come with a built in DOS : If I had (say) program.exe as a >> domain name, >> what Windows user would ever type it in ? >> > I think this would be one of the TLDs that they'd refuse. > Then again, there are DOS commands that do end in .com (CHOICE, > COMMAND, CMD, DISKCOMP, HELP,etc). More can be seen at : > http://support.microsoft.com/kb/72188 What about .stupid? Gadi. > > > Tuc/TBOH > From frnkblk at iname.com Sun Jun 29 15:36:41 2008 From: frnkblk at iname.com (Frank Bulk - iNAME) Date: Sun, 29 Jun 2008 15:36:41 -0500 Subject: ICANN opens up Pandora's Box of new TLDs In-Reply-To: <20080629163213.GB10417@sources.org> References: <7ff145960806261309u4eda28b7v8973556b983df63a@mail.gmail.com> <5429E6E0-382A-4711-8D8C-2A241B6E4F6A@mailchannels.com> <20080627024941.GA29345@gsp.org> <20080629163213.GB10417@sources.org> Message-ID: You do have a choice if you're not concerned about the deliverability of your e-mail. Remember, the Internet remains a group of service providers/organizations/subscribers that voluntarily work together and can choose what goes in or out. And so if they decide not to receive traffic from you, for any reason at all, there's no legal requirement. If they require that all e-mail servers that want to send e-mail to them have rDNS entries then persons who want to deliver e-mail to that entity need to comply. Frank -----Original Message----- From: Stephane Bortzmeyer [mailto:bortzmeyer at nic.fr] Sent: Sunday, June 29, 2008 11:32 AM To: nanog at nanog.org Subject: Re: ICANN opens up Pandora's Box of new TLDs We already see this in the email world, where a self-appointed cartel like the MAAWG can decide technical rules and policies, bypassing both IETF and ICANN. Even if only one half of the big operators enforce these rules, they will become de facto regulations, since noone can afford to have his email refused by this half. (To take a recent example, I configure rDNS on every email server I managed, even if I find the rule stupid and unfair, because I have no choice.) From ge at linuxbox.org Sun Jun 29 15:39:28 2008 From: ge at linuxbox.org (Gadi Evron) Date: Sun, 29 Jun 2008 15:39:28 -0500 (CDT) Subject: Internet management, was ICANN opens up Pandora's Box of new TLDs In-Reply-To: <20080629184411.67007.qmail@simone.iecc.com> References: <20080629184411.67007.qmail@simone.iecc.com> Message-ID: On Sun, 29 Jun 2008, John Levine wrote: >> We already see this in the email world, where a self-appointed cartel >> like the MAAWG can decide technical rules and policies, bypassing >> both IETF and ICANN. > > As an active participant in both the IETF and MAAWG, and a former > member of the ICANN ALAC, I can assure you that MAAWG would be > delighted to stop publishing its own BCPs about email and abuse > management, reflecting the experience of the largest mail systems on > the planet, if the IETF or ICANN would get their heads out of their > navels and do so. A mail system configured according to current RFCs > would be useless, since nobody would be able to find the trickle of > legit mail in the torrent of spam, even assuming the mail system > didn't melt down from the load. > >> I configure rDNS on every email server I managed, even if I >> find the rule stupid and unfair, because I have no choice. > > All those mean old ISPs are, in case you hadn't noticed, delivering > the mail you send them for free. If you find it too much trouble to > configure your DNS in accordance with STD 13, which has been around > for over 20 years, I expect they'll also find it too much trouble to > try and tell your mail apart from the 99.999% of no-rDNS hosts that > are spambots. > > Spam sucks, complaining about it won't make it go away. Indeed, the > reason we're making so little progress against it is that far too many > people just complain and expect someone else to solve the problem. > I for one am happy MAAWG and other less public groups are out there. Nature abhors a vacuume and if one is there it will be filled. Gadi. > R's, > John > From ge at linuxbox.org Sun Jun 29 15:42:08 2008 From: ge at linuxbox.org (Gadi Evron) Date: Sun, 29 Jun 2008 15:42:08 -0500 (CDT) Subject: what problem are we solving? (was Re: ICANN opens up Pandora'sBox of In-Reply-To: <7ff145960806291320x4a768f62x31cf7262ae945b6f@mail.gmail.com> References: <200806290231.m5T2VXob020706@aurora.sol.net> <7ff145960806291320x4a768f62x31cf7262ae945b6f@mail.gmail.com> Message-ID: On Sun, 29 Jun 2008, Jim Popovitch wrote: > On Sun, Jun 29, 2008 at 1:21 PM, Peter Beckman wrote: >> Let the search engines organize the web, not DNS. > > OK, (assuming you believe that), why keep dns around. Why not go back > to just IP addrs and hosts files for those that need them. Because the Internet is not governemned, common misbelief aside. It's a mess of capitalism and anarchism. In fact, The Internet is the only functioning anarchu. I see no reason why search engines won't, they already do, whether we want to admit it or not, for the home user they ARE the Internet. Gadi. > -Jim P. > From LarrySheldon at cox.net Sun Jun 29 15:45:56 2008 From: LarrySheldon at cox.net (Laurence F. Sheldon, Jr.) Date: Sun, 29 Jun 2008 15:45:56 -0500 Subject: NANOG Digest, Vol 5, Issue 92 In-Reply-To: <6F2FFD7C10F788479E354B84294036C42134F8F3@EXCH-MBX.exchange.alphared.local> References: <6F2FFD7C10F788479E354B84294036C42134F8F3@EXCH-MBX.exchange.alphared.local> Message-ID: <4867F484.9070101@cox.net> mack wrote: > In 25 years a name will map to .com or be irrelevant with the current proposal. > I would be happy to be proven wrong but time will tell. And of course by then all but BGP (between routers) and HTTP will have been blocked as security risks. -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs From marquis at roble.com Sun Jun 29 15:49:18 2008 From: marquis at roble.com (Roger Marquis) Date: Sun, 29 Jun 2008 13:49:18 -0700 (PDT) Subject: Mail Server best practices - was: Pandora's Box of new TLDs In-Reply-To: References: Message-ID: <20080629204918.BDB092B7C01@mx5.roble.com> Rich Kulawiec wrote: >> Quoting : >> >> The only reliable way to avoid false-positives is by monitoring >> the email server or gateway logs and allowing end-users to receive >> a daily report of email sent to their account that was identified >> as spam and filtered. > > First, it is impossible to avoid false positives (unless you turn all > spam filtering off) or false negatives A bit of a Red Herring as nobody expects 100%. > Second, while in principle this isn't a bad approach, in reality it > tends not to work well. Judging by user acceptance, over a decade's use and several thousand users, it works better than any other method, certainly better than silently rejecting and discarding spam on the one hand, or tagging and delivering it on the other. Not that any ISP delivers everything (since ~1996). The ones that try learn a hard lesson in DOS or they lose customers (remember netcom.com). The issue isn't delivery, it's reporting, and only ISPs that inform users about _every_ rejected or discarded email are capable of effectively minimizing false positives. > It requires that users weed through the daily reports Looks like you haven't looked at the reports. Nothing in them is more difficult to parse than a large spam folder. I'm guessing you also don't intend to imply that users look in their spam folder? > and it requires accepting and storing considerable volumes of > mail which are likely spam/phish/virus/etc. You must be talking about some other system. Volumes of mail stored in spam folders are what reports _avoid_. Simple text reports take almost no disk and, for most users, a year's worth of searchable daily reports takes just a few MBs. > can make FP detection difficult, since senders do not get a > reject (mail was accepted, after all; why should they?) and thus > may be unaware that their message was dropped in a probable-spam > folder. You really should read the URL cited above, and have a look at the sample reports. Whether spam is rejected outright or discarded after delivery is not relevant since good reports list both. Users don't make a distinction either, as long as they know what was filtered. Whether to A) reject or B) accept and discard is also a bit of a red herring. Most spam will get reject by RBLs but you still _must_ run everything else through Spamassassin and AV, and there's no way to do those checks pre-queue without SMTP timeouts and DOS. Roger Marquis From beckman at angryox.com Sun Jun 29 16:32:51 2008 From: beckman at angryox.com (Peter Beckman) Date: Sun, 29 Jun 2008 17:32:51 -0400 Subject: what problem are we solving? (was Re: ICANN opens up Pandora'sBox of In-Reply-To: <7ff145960806291320x4a768f62x31cf7262ae945b6f@mail.gmail.com> References: <200806290231.m5T2VXob020706@aurora.sol.net> <7ff145960806291320x4a768f62x31cf7262ae945b6f@mail.gmail.com> Message-ID: On Sun, 29 Jun 2008, Jim Popovitch wrote: > On Sun, Jun 29, 2008 at 1:21 PM, Peter Beckman wrote: >> Let the search engines organize the web, not DNS. > > OK, (assuming you believe that), why keep dns around. Why not go back > to just IP addrs and hosts files for those that need them. DNS is useful in masking IP address changes, and for humans navigating the Internet. DNS is not useful for organizing the web. Additional TLDs isn't going to help organize the web. Search engines and portals organize the web. DNS will be increasingly less useful as the Internet continues to expand and grow, and normal non-geek non-nanog humans will increasingly rely on search engines and portals to find what they need, not domain names. Beckman --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com http://www.angryox.com/ --------------------------------------------------------------------------- From marquis at roble.com Sun Jun 29 16:45:55 2008 From: marquis at roble.com (Roger Marquis) Date: Sun, 29 Jun 2008 14:45:55 -0700 (PDT) Subject: ICANN opens up Pandora's Box of new TLDs In-Reply-To: References: Message-ID: <20080629214555.482862B7C03@mx5.roble.com> Stephane Bortzmeyer bortzmeyer at nic.fr wrote: > I am very curious of what tests a "security-aware programmer" can do, > based on the domain name, which will not be possible tomorrow, should > ICANN allow a few more TLDs. The difference between '[a-z0-9\-\.]*\.[a-z]{2-5}' and '[a-z0-9\-\.]*\.[a-z\-]*' is substantial from a security perspective. Aside from the IP issues it effectively precludes anyone from defining a hostname that cannot also be someone else's domain name. It's not too hard to see the problems with that. An analogous network scenario would be IP addresses of varying length and without a netmask. > If you test that the TLD exists... it will still work. Only if A) you are always online with B) reliable access to the tld's nameserver/s, and C) can deal with the latency. In practice this is often not the case. > If you test that the name matches (com|net|org|[a-z]{2}), then you are > not what I would call a "security-aware programmer". Will you still think that when someone buys the right to the .nic tld and starts harvesting your queries and query related traffic? Not that that doesn't happen now, to a far lesser degree. But it's the extent to which this presents new opportunities for black hats that should have given ICANN pause. Odds are that RBLs will be among the first targets. Bottom line is the decision was made for it's _monetization_ value, not security, and customer service was just a pretense. Roger Marquis From ml at t-b-o-h.net Sun Jun 29 16:55:53 2008 From: ml at t-b-o-h.net (Tuc at T-B-O-H.NET) Date: Sun, 29 Jun 2008 17:55:53 -0400 (EDT) Subject: ICANN opens up Pandora's Box of new TLDs In-Reply-To: Message-ID: <200806292155.m5TLtrnE062355@himinbjorg.tucs-beachin-obx-house.com> > > You do have a choice if you're not concerned about the deliverability of > your e-mail. Remember, the Internet remains a group of service > providers/organizations/subscribers that voluntarily work together and can > choose what goes in or out. And so if they decide not to receive traffic > from you, for any reason at all, there's no legal requirement. If they > require that all e-mail servers that want to send e-mail to them have rDNS > entries then persons who want to deliver e-mail to that entity need to > comply. > > Frank > So can I change my SMTP greeting to be : 220-host.example.com SMTP 220-Company agrees to the following rate chart to accept mail : 220-EHLO - $5.00 220-HELO - $2.50 220-MAIL FROM:<*> - Free 220-RCPT TO:<*> - 1-5/$4.00 , 6-10/$6.00, 11-15/$8.00, 15+/$10.00 220-DATA: $.01 per character until final "." 220-Delivery confirmation (Return-Receipt-To, X-Confirm-Reading-To, Disposition-Notification-To) - $1.50 220 Sending HELO/EHLO constitutes acceptance of this agreement Thanks, Tuc/TBOH From johnl at iecc.com Sun Jun 29 17:06:03 2008 From: johnl at iecc.com (John Levine) Date: 29 Jun 2008 22:06:03 -0000 Subject: ICANN opens up Pandora's Box of new TLDs In-Reply-To: <20080629214555.482862B7C03@mx5.roble.com> Message-ID: <20080629220603.16028.qmail@simone.iecc.com> >> If you test that the TLD exists... it will still work. > Only if A) you are always online with B) reliable access to the > tld's nameserver/s, and C) can deal with the latency. In practice > this is often not the case. Even under the most wildly optimistic scenarios, it's hard to imagine new TLDs being added more than once a month, and I presume that everyone here already knows how easy it is to get copies of the root zone. The reasonable way to validate TLDs is to fetch a copy of the zone every couple of weeks and cache it. By the way, to be sure we're all on roughly the same page, here's a quiz. How many names are there in the root zone right now? a) 11 b) 97 c) 153 d) 280 e) 974 Regards, John Levine, johnl at iecc.com, Primary Perpetrator of "The Internet for Dummies", Information Superhighwayman wanna-be, http://www.johnlevine.com, ex-Mayor "More Wiener schnitzel, please", said Tom, revealingly. From bmanning at vacation.karoshi.com Sun Jun 29 18:59:58 2008 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Sun, 29 Jun 2008 23:59:58 +0000 Subject: DNS and potential energy In-Reply-To: <393FF04B-6BDC-41CE-BCF3-97FC6D0226A2@ca.afilias.info> References: <200806290231.m5T2VXob020706@aurora.sol.net> <393FF04B-6BDC-41CE-BCF3-97FC6D0226A2@ca.afilias.info> Message-ID: <20080629235958.GA16853@vacation.karoshi.com.> On Sun, Jun 29, 2008 at 02:14:58PM -0400, Joe Abley wrote: > > The only decision that is required is whether new generic top-level > domains are desired. If not, do nothing. Otherwise, shake as much > energy into the system as possible and sit back and let it find its > own steady state. > > Joe possession and use of classV explosives is regulated in most jurisdictions. but if you think that if we pack enough C4 into the DNS and set it off, that we might find equalibrium, you might be right. :) the result will still be a flat namespace, (perhaps a crater where the namespace was). one might legitimately argue that ICANN is in need of some serious regulation.... that can happen at that national level or on the international level. --bill From hannigan at verneglobal.com Sun Jun 29 19:12:27 2008 From: hannigan at verneglobal.com (Martin Hannigan) Date: Mon, 30 Jun 2008 00:12:27 -0000 Subject: DNS and potential energy Message-ID: This is currently a mostly capex-less exercise. I agree, the load is on operations, and likely at ICANN, VeriSign, and the DoC. We need way more detail than we have, but I hope all parties and the AC's move in a stewardship -and- commerce friendly direction with this. Even if it causes an evolution in the root -- which I believe it will. Best, Marty "Nothing like having a front row seat on the Internet". ---Mary Reindeau ----- Original Message ----- From: bmanning at vacation.karoshi.com To: Joe Abley Cc: nanog at nanog.org ; Joe Greco Sent: Sun Jun 29 23:59:58 2008 Subject: DNS and potential energy On Sun, Jun 29, 2008 at 02:14:58PM -0400, Joe Abley wrote: > > The only decision that is required is whether new generic top-level > domains are desired. If not, do nothing. Otherwise, shake as much > energy into the system as possible and sit back and let it find its > own steady state. > > Joe possession and use of classV explosives is regulated in most jurisdictions. but if you think that if we pack enough C4 into the DNS and set it off, that we might find equalibrium, you might be right. :) the result will still be a flat namespace, (perhaps a crater where the namespace was). one might legitimately argue that ICANN is in need of some serious regulation.... that can happen at that national level or on the international level. --bill From fw at deneb.enyo.de Sun Jun 29 19:42:07 2008 From: fw at deneb.enyo.de (Florian Weimer) Date: Mon, 30 Jun 2008 02:42:07 +0200 Subject: ICANN opens up Pandora's Box of new TLDs In-Reply-To: <48640FC2.2000909@spaghetti.zurich.ibm.com> (Jeroen Massar's message of "Thu, 26 Jun 2008 23:53:06 +0200") References: <7ff145960806261309u4eda28b7v8973556b983df63a@mail.gmail.com> <5429E6E0-382A-4711-8D8C-2A241B6E4F6A@mailchannels.com> <48640FC2.2000909@spaghetti.zurich.ibm.com> Message-ID: <87myl3da8w.fsf@mid.deneb.enyo.de> * Jeroen Massar: > Some people are going to get very rich over this. I hope that they > drown in the money just as the Internet will drown in all the crap > TLD's, not even thinking of all the nice security issues which come > along (home, mycomputer and .exe etc anyone ? :) .exe abd .com are equivalent in this regard. Oops. > Thank you people doing all the ICANN politics for destroying the > Internet. I don't really see how this is substantially different from .me, .mobi, .cat or .eu. Basically, selling TLDs means that ICANN has some sort of implied non-technical obligation of keeping them relatively scarce, which is currently lacking AFAICT. From brunner at nic-naa.net Sun Jun 29 22:04:15 2008 From: brunner at nic-naa.net (Eric Brunner-Williams) Date: Sun, 29 Jun 2008 20:04:15 -0700 Subject: what problem are we solving? (was Re: ICANN opens up Pandora's Box of new TLDs) In-Reply-To: <4C0790EA-33E5-43F2-B281-215A0B37AE4F@virtualized.org> References: <171423de0806271024h73e9a181t1df338aa5fe84ef5@mail.gmail.com> <4D0B482D-8FD5-48A5-9FF6-C2011AA7ACB5@virtualized.org> <20080628035954.BC78F213C3@spunkymail-a9.g.dreamhost.com> <4C0790EA-33E5-43F2-B281-215A0B37AE4F@virtualized.org> Message-ID: <48684D2F.5070801@nic-naa.net> David Conrad wrote: > ... part of that constituency', but in reality, the majority of domain > names are held by registrars. ... > I didn't know that. Can you point me to some data? Eric From bmanning at vacation.karoshi.com Sun Jun 29 22:07:21 2008 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Mon, 30 Jun 2008 03:07:21 +0000 Subject: DNS and potential energy In-Reply-To: References: Message-ID: <20080630030721.GA17744@vacation.karoshi.com.> this may actually be the straw that triggers a serious redesign of the Internet's lookup system(s)... if not this, then IPv6 has a good chance. Incremental changes are good - are stable (usually), and often can be compartmentalized. But sometimes - revolutionary changes are needed. and if they have the same attributes (stable & compartmentable) - then all the better. the real issues w/ new TLDs is that they are being rolled out at the same time as IDN tlds.... the number of applications and endsystems that will need to be rebuilt, tested, debugged, shipped, and documented is nearly unimmaginable. your comment wrt operations is, dare I say, understated? the opex for this is huge. ICANN reaps the profits and the ISPs customers pay. (*) Friend Bush alluded to this earlier. It si my fond hope that DNS validation API's are built/tested soon, so that end systems have one sea change and not three within the next 24 months. Oh yeah... and make sure you get IPv6 capability in there too. This will not be your fathers Internet. --bill On Mon, Jun 30, 2008 at 12:12:27AM -0000, Martin Hannigan wrote: > > > This is currently a mostly capex-less exercise. I agree, the load is on operations, and likely at ICANN, VeriSign, and the DoC. > > We need way more detail than we have, but I hope all parties and the AC's move in a stewardship -and- commerce friendly direction with this. Even if it causes an evolution in the root -- which I believe it will. > > Best, > > Marty > > > "Nothing like having a front row seat on the Internet". > ---Mary Reindeau > > > > > ----- Original Message ----- > From: bmanning at vacation.karoshi.com > To: Joe Abley > Cc: nanog at nanog.org ; Joe Greco > Sent: Sun Jun 29 23:59:58 2008 > Subject: DNS and potential energy > > On Sun, Jun 29, 2008 at 02:14:58PM -0400, Joe Abley wrote: > > > > The only decision that is required is whether new generic top-level > > domains are desired. If not, do nothing. Otherwise, shake as much > > energy into the system as possible and sit back and let it find its > > own steady state. > > > > Joe > > possession and use of classV explosives is regulated in > most jurisdictions. > > but if you think that if we pack enough C4 into the DNS > and set it off, that we might find equalibrium, you might > be right. :) the result will still be a flat namespace, > (perhaps a crater where the namespace was). > > one might legitimately argue that ICANN is in need of > some serious regulation.... > > that can happen at that national level or on the international > level. > > --bill > From randy at psg.com Mon Jun 30 00:57:41 2008 From: randy at psg.com (Randy Bush) Date: Mon, 30 Jun 2008 14:57:41 +0900 Subject: rib dumps Message-ID: <486875D5.40909@psg.com> i am looking for date-stamped rib dumps going back years from a peering edge router that is fairly 'stable', i.e. multi-peer dfz but the number of peers changes infrequently. [ routeviews and ris do not meet the above description as they are not at all stable in the number of peers. ] [ your internal router which feeds off route reflectors does not meet the above description, as it is not peered externally to multiple peers. ] thanks! randy From bortzmeyer at nic.fr Mon Jun 30 01:46:59 2008 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Mon, 30 Jun 2008 08:46:59 +0200 Subject: ICANN opens up Pandora's Box of new TLDs In-Reply-To: <20080629214555.482862B7C03@mx5.roble.com> References: <20080629214555.482862B7C03@mx5.roble.com> Message-ID: <20080630064659.GA6095@sources.org> On Sun, Jun 29, 2008 at 02:45:55PM -0700, Roger Marquis wrote a message of 31 lines which said: > The difference between '[a-z0-9\-\.]*\.[a-z]{2-5}' If this is a regexp for the current root zone, it is wrong... (".museum" and the test IDNs, whose punycode encoding contains digits and hyphens.) > Aside from the IP issues it effectively precludes anyone from > defining a hostname that cannot also be someone else's domain > name. Interesting requirment but one which was never written down, I'm afraid. You certainly cannot expect ICANN to comply with every requirment that someone at Nanog may imagine every day. > Will you still think that when someone buys the right to the .nic > tld and starts harvesting your queries and query related traffic? Be my guest. The DNS is a tree and the existence of nic.de or nic.com was never a problem. Why should ".nic" be different? From bortzmeyer at nic.fr Mon Jun 30 01:49:23 2008 From: bortzmeyer at nic.fr ('Stephane Bortzmeyer') Date: Mon, 30 Jun 2008 08:49:23 +0200 Subject: Mail Server best practices - was: Pandora's Box of new TLDs In-Reply-To: References: <20080628161844.GT31980@catpipe.net> <20080628180212.GA35151@catpipe.net> <4866B387.2070900@vaxination.ca> <20080629200826.GD1569@sources.org> Message-ID: <20080630064923.GD6095@sources.org> On Sun, Jun 29, 2008 at 03:30:15PM -0500, Frank Bulk - iNAME wrote a message of 35 lines which said: > Because if you do anything, even as basic as RBLs, you're not being > consistent with your stance. The typical use of RBLs is to reject email at the SMTP level, when it matches an entry in the RBL. That way, the sender is warned that something went wrong, email does not disappear silently. From mpetach at netflight.com Mon Jun 30 02:36:04 2008 From: mpetach at netflight.com (Matthew Petach) Date: Mon, 30 Jun 2008 00:36:04 -0700 Subject: ICANN opens up Pandora's Box of new TLDs In-Reply-To: <20080630064659.GA6095@sources.org> References: <20080629214555.482862B7C03@mx5.roble.com> <20080630064659.GA6095@sources.org> Message-ID: <63ac96a50806300036u5c1a9bbdq4efb8e4879650434@mail.gmail.com> Terribly stupid question, but one aproppos to this thread. If my company pays for and registers a new TLD, let's call it "smtp" for grins, and I create an A record for "smtp." in my top level zone file, how will users outside my company resolve and reach that address? If they simply use "smtp" as the hostname, most of the current resolver libraries will append the local domain name, so that instead of reaching my A record for smtp, they'll end up trying to reach smtp.their.domain. Will operating system manufacturers release updated resolver libraries that no longer assume that single token names should have the local domain attached? Or should I always ensure that resolvers reach my domain explicitly by including the trailing "dot" in all uses, so that my email would be given out as "myname at smtp." in the hopes that everyone would correctly remember to add the "." at the end when entering my email address into their mail clients? In the past, this wasn't really a concern, as you never had a case of a single entity owning an entire TLD, and as such you'd never see A or MX records showing up for an entire TLD. But now, with private ownership of TLDs possible, that could very well be the case in the future. Google could register .gmail, and decide that they want to have the shortest, easiest to remember addresses, so people can just be "user at gmail" (well, until MSN gets in the business, and decides that their users should have even shorter addresses, and register .msn so that their users can be "user at msn". ^_^; ) Or does the current resolver logic already handle these cases (check root, work your way down stopping at the first match found; if you run out of tokens in the string being resolved, append the local domain name to the string and start the process over)? Simply looking to solidify my understanding of how these new names would resolve. Thanks! Matt From rob at pickering.org Mon Jun 30 03:08:35 2008 From: rob at pickering.org (Rob Pickering) Date: Mon, 30 Jun 2008 09:08:35 +0100 Subject: DNS and potential energy In-Reply-To: <20080629235958.GA16853@vacation.karoshi.com.> References: <200806290231.m5T2VXob020706@aurora.sol.net> <393FF04B-6BDC-41CE-BCF3-97FC6D0226A2@ca.afilias.info> <20080629235958.GA16853@vacation.karoshi.com.> Message-ID: --On 29 June 2008 23:59 +0000 bmanning at vacation.karoshi.com wrote: > one might legitimately argue that ICANN is in need of > some serious regulation.... > > that can happen at that national level or on the international > level. It is very likely that "serious regulation" particularly at an "international level" would have a way more degenerate effect on DNS operations than adding a bunch of new entries into the root. Be careful about what you legitimately argue for... I'm still having a hard time seeing what everyone is getting worked up about. Can anyone point to an example of a reasonably plausible bad thing, that could happen as a result of doubling, tripling, or even increasing by an order of magnitude the size of the root zone. Sure, nefarious use of say .local could cause a few problems but this is pretty inconceivable given that: 1) most estimates I've seen of the cost of setting up a TLD start at around $500,000 (probably a bit over the credit limit on a stolen credit card #). 2) These are easily fixed by adding known large uses like to this to the formal reserved list. 3) I'm sure that these will in any case be caught well before deployment under the proposed filtering process. So, other than a change in the number of various DNS related money chutes and their net recipients, what are the actual operational issues here? -- Rob. From regnauld at catpipe.net Mon Jun 30 03:53:38 2008 From: regnauld at catpipe.net (Phil Regnauld) Date: Mon, 30 Jun 2008 10:53:38 +0200 Subject: ICANN opens up Pandora's Box of new TLDs In-Reply-To: <63ac96a50806300036u5c1a9bbdq4efb8e4879650434@mail.gmail.com> References: <20080629214555.482862B7C03@mx5.roble.com> <20080630064659.GA6095@sources.org> <63ac96a50806300036u5c1a9bbdq4efb8e4879650434@mail.gmail.com> Message-ID: <20080630085337.GC39571@catpipe.net> Matthew Petach (mpetach) writes: > If they simply use "smtp" as the hostname, most of the > current resolver libraries will append the local domain > name, so that instead of reaching my A record for smtp, > they'll end up trying to reach smtp.their.domain. Actually, that's a good point -- although it will try first with the domains specified in the search list first. So I wouldn't worry too much about this kind of thing. But considering the amount of flag waving and "Caution: Wet Floor" signs ICANN placed when it rolled out something has harmless as the IDN tests in the root, I'm surprised that they haven't thought about all the non-FQDNs that will suddenly resolve, including all the private TLDs that people use internally. It's bad practice, and isn't recommended anyway, but I do expect it will cause many more fun (read: annoying) calls to helpdesks of the sort "where did my mail go ?". And mail won't be the only thing. > Will operating system manufacturers release updated > resolver libraries that no longer assume that single > token names should have the local domain attached? I know a lot of mail clients that won't accept to send mail to user at tld, but they certainly will accept user at smtp as the outgoing mail name. Luckily, that will match the search list as well first. > Or should I always ensure that resolvers reach my > domain explicitly by including the trailing "dot" in > all uses, so that my email would be given out as > "myname at smtp." in the hopes that everyone would > correctly remember to add the "." at the end when > entering my email address into their mail clients? A fair number will barf on this (for now). > Or does the current resolver logic already handle > these cases (check root, work your way down > stopping at the first match found; if you run out > of tokens in the string being resolved, append the > local domain name to the string and start the process > over)? The other way around. And if I ping 'dk', my resolver stops after "catpipe.net" and my other private domain. It doesn't try "dk.", even though dk. has an A record associated with it. I get NXDOMAIN. > Simply looking to solidify my understanding of how > these new names would resolve. Not too many problems, I think, except for resolver libraries that fail to find the name in the domains listed in the search list, and continue to '.'. It's not standard practice though. Phil From regnauld at catpipe.net Mon Jun 30 04:38:29 2008 From: regnauld at catpipe.net (Phil Regnauld) Date: Mon, 30 Jun 2008 11:38:29 +0200 Subject: ICANN opens up Pandora's Box of new TLDs In-Reply-To: <20080629220603.16028.qmail@simone.iecc.com> References: <20080629214555.482862B7C03@mx5.roble.com> <20080629220603.16028.qmail@simone.iecc.com> Message-ID: <20080630093829.GE39571@catpipe.net> John Levine (johnl) writes: > d) 280 # dig @f.root-servers.net axfr . | egrep 'IN[[:space:]]NS' | awk '{ print $1 }' | sort -u |wc -l 281 (with . itself) From drc at virtualized.org Mon Jun 30 07:28:20 2008 From: drc at virtualized.org (David Conrad) Date: Mon, 30 Jun 2008 05:28:20 -0700 Subject: ICANN opens up Pandora's Box of new TLDs In-Reply-To: <63ac96a50806300036u5c1a9bbdq4efb8e4879650434@mail.gmail.com> References: <20080629214555.482862B7C03@mx5.roble.com> <20080630064659.GA6095@sources.org> <63ac96a50806300036u5c1a9bbdq4efb8e4879650434@mail.gmail.com> Message-ID: <5322A84A-F48C-4299-A024-A61A641F07EE@virtualized.org> On Jun 30, 2008, at 12:36 AM, Matthew Petach wrote: > If my company pays for and registers a new TLD, let's > call it "smtp" for grins, and I create an A record for "smtp." > in my top level zone file, how will users outside my company > resolve and reach that address? I suspect the assumption is that no one will actually do this since it would have operational issues (as you note) and it would be challenging to recover costs in the "traditional" manner (i.e., selling names under the TLD). If someone were to try, perhaps it would demonstrate the quote "stupidity, like virtue, is its own reward"? Regards, -drc From tme at multicasttech.com Mon Jun 30 07:36:29 2008 From: tme at multicasttech.com (Marshall Eubanks) Date: Mon, 30 Jun 2008 08:36:29 -0400 Subject: ICANN opens up Pandora's Box of new TLDs In-Reply-To: <5322A84A-F48C-4299-A024-A61A641F07EE@virtualized.org> References: <20080629214555.482862B7C03@mx5.roble.com> <20080630064659.GA6095@sources.org> <63ac96a50806300036u5c1a9bbdq4efb8e4879650434@mail.gmail.com> <5322A84A-F48C-4299-A024-A61A641F07EE@virtualized.org> Message-ID: <33EEDD09-AB6C-421E-8F8A-16387C0D3F9C@multicasttech.com> It seems to me that there are technical reasons to try and block .local, and maybe some other potential TLDs, but that for .exe, .smtp, and other choices that confuse current browser implementations, a warning note is about all the registrant can expect. Of course, it would not surprise me if people are right now going through web logs and search logs and saying, hmm, .smtp and .exe occur so often, they would make GREAT TLDs. Regards Marshall On Jun 30, 2008, at 8:28 AM, David Conrad wrote: > On Jun 30, 2008, at 12:36 AM, Matthew Petach wrote: >> If my company pays for and registers a new TLD, let's >> call it "smtp" for grins, and I create an A record for "smtp." >> in my top level zone file, how will users outside my company >> resolve and reach that address? > > I suspect the assumption is that no one will actually do this since > it would have operational issues (as you note) and it would be > challenging to recover costs in the "traditional" manner (i.e., > selling names under the TLD). If someone were to try, perhaps it > would demonstrate the quote "stupidity, like virtue, is its own > reward"? > > Regards, > -drc > > From drc at virtualized.org Mon Jun 30 07:41:59 2008 From: drc at virtualized.org (David Conrad) Date: Mon, 30 Jun 2008 05:41:59 -0700 Subject: ICANN opens up Pandora's Box of new TLDs In-Reply-To: <20080630085337.GC39571@catpipe.net> References: <20080629214555.482862B7C03@mx5.roble.com> <20080630064659.GA6095@sources.org> <63ac96a50806300036u5c1a9bbdq4efb8e4879650434@mail.gmail.com> <20080630085337.GC39571@catpipe.net> Message-ID: <3BB28A67-1837-4374-A5F5-574EB05853E2@virtualized.org> On Jun 30, 2008, at 1:53 AM, Phil Regnauld wrote: > But considering the amount of flag waving and "Caution: Wet > Floor" signs ICANN placed when it rolled out something has > harmless as the IDN tests in the root, I'm surprised that they > haven't thought about all the non-FQDNs that will suddenly > resolve, including all the private TLDs that people use > internally. 1) The new gTLD stuff hasn't gotten as far as the point where the testing of IDN stuff started. 2) ICANN (or rather, the technical side of ICANN staff) has thought about this and there is a 'technical evaluation' phase of the application evaluation 3) We've already run into the 'private TLD' thing: lots of global companies (apparently) have internal domains organized on regional/ continental boundaries. When '.asia' was put into the root, the Internet did not break. > The other way around. And if I ping 'dk', my resolver > stops after "catpipe.net" and my other private domain. > It doesn't try "dk.", even though dk. has an A record > associated with it. I get NXDOMAIN. Your resolver appears to be broken. Works for me: % dig +short dk 193.163.102.23 % traceroute dk. traceroute to dk (193.163.102.23), 64 hops max, 40 byte packets 1 10.0.1.1 (10.0.1.1) 4.484 ms 3.933 ms 1.163 ms 2 * * * 3 * ge-2-14-ur01.santaclara.ca.sfba.comcast.net (68.86.248.65) 13.600 ms 10.250 ms ... 20 netgroup.r2.dk-hostmaster.dk (217.116.254.58) 204.900 ms 200.835 ms 199.208 ms ^C (doesn't appear to answer to pings) Regards, -drc From regnauld at catpipe.net Mon Jun 30 08:15:57 2008 From: regnauld at catpipe.net (Phil Regnauld) Date: Mon, 30 Jun 2008 15:15:57 +0200 Subject: ICANN opens up Pandora's Box of new TLDs In-Reply-To: <3BB28A67-1837-4374-A5F5-574EB05853E2@virtualized.org> References: <20080629214555.482862B7C03@mx5.roble.com> <20080630064659.GA6095@sources.org> <63ac96a50806300036u5c1a9bbdq4efb8e4879650434@mail.gmail.com> <20080630085337.GC39571@catpipe.net> <3BB28A67-1837-4374-A5F5-574EB05853E2@virtualized.org> Message-ID: <20080630131557.GL39571@catpipe.net> David Conrad (drc) writes: > > 1) The new gTLD stuff hasn't gotten as far as the point where the testing > of IDN stuff started. Mhh, ok :) > 2) ICANN (or rather, the technical side of ICANN staff) has thought about > this and there is a 'technical evaluation' phase of the application > evaluation Fair enough. > 3) We've already run into the 'private TLD' thing: lots of global companies > (apparently) have internal domains organized on regional/continental > boundaries. When '.asia' was put into the root, the Internet did not break. > >> The other way around. And if I ping 'dk', my resolver >> stops after "catpipe.net" and my other private domain. >> It doesn't try "dk.", even though dk. has an A record >> associated with it. I get NXDOMAIN. > > Your resolver appears to be broken. Works for me: dig doesn't use the resolver the same way other applications do. Try "ping dk" vs "ping dk.", or "telnet dk" vs. telnet "dk." Of course, depends on the OS -- but at least on a few BSDs (OS X, FreeBSD), Linuxes (Debian, Ubuntu), it behaves the same way. From johnl at iecc.com Mon Jun 30 09:47:23 2008 From: johnl at iecc.com (John Levine) Date: 30 Jun 2008 14:47:23 -0000 Subject: ICANN opens up Pandora's Box of new TLDs In-Reply-To: <63ac96a50806300036u5c1a9bbdq4efb8e4879650434@mail.gmail.com> Message-ID: <20080630144723.3290.qmail@simone.iecc.com> In article <63ac96a50806300036u5c1a9bbdq4efb8e4879650434 at mail.gmail.com> you write: >Terribly stupid question, but one aproppos to this thread. > >If my company pays for and registers a new TLD, let's >call it "smtp" for grins, and I create an A record for "smtp." >in my top level zone file, how will users outside my company >resolve and reach that address? In the usual way. Try typing this into your browser's address bar: http://museum/ R's, John From mpetach at netflight.com Mon Jun 30 11:05:41 2008 From: mpetach at netflight.com (Matthew Petach) Date: Mon, 30 Jun 2008 09:05:41 -0700 Subject: ICANN opens up Pandora's Box of new TLDs In-Reply-To: <20080630144723.3290.qmail@simone.iecc.com> References: <63ac96a50806300036u5c1a9bbdq4efb8e4879650434@mail.gmail.com> <20080630144723.3290.qmail@simone.iecc.com> Message-ID: <63ac96a50806300905s168c3da9m6d636067bafe3c45@mail.gmail.com> On 30 Jun 2008 14:47:23 -0000, John Levine wrote: > In article <63ac96a50806300036u5c1a9bbdq4efb8e4879650434 at mail.gmail.com> you write: > >Terribly stupid question, but one aproppos to this thread. > > > >If my company pays for and registers a new TLD, let's > >call it "smtp" for grins, and I create an A record for "smtp." > >in my top level zone file, how will users outside my company > >resolve and reach that address? > > In the usual way. Try typing this into your browser's address bar: > > http://museum/ That was amusing. Firefox very handily took me to a search results page listing results for the word "museum", none of which was the actual page in question. In order to reach that page, in Firefox 1.5.0.12, I had to actually enter "http://museum./ and add the trailing dot to force the browser to *not* treat it as a stub token. IE was a little more normal, and simply returned a 'host unknown" error. Annoyingly enough, however, IE returned the "host unknown" for *both* "http://museum/" and "http://museum./" so it failed to follow proper resolution practice and ignored the trailing dot. Thanks for all the pointers! I guess I won't be suggesting the use of such TLDs as gmail and ymail as a way to shorten up email addresses for people, given the inconsistent behaviour of client resolvers. ^_^; > R's, > John Thanks! Matt From regnauld at catpipe.net Mon Jun 30 11:12:52 2008 From: regnauld at catpipe.net (Phil Regnauld) Date: Mon, 30 Jun 2008 18:12:52 +0200 Subject: ICANN opens up Pandora's Box of new TLDs In-Reply-To: <63ac96a50806300905s168c3da9m6d636067bafe3c45@mail.gmail.com> References: <63ac96a50806300036u5c1a9bbdq4efb8e4879650434@mail.gmail.com> <20080630144723.3290.qmail@simone.iecc.com> <63ac96a50806300905s168c3da9m6d636067bafe3c45@mail.gmail.com> Message-ID: <20080630161251.GQ39571@catpipe.net> Matthew Petach (mpetach) writes: > > That was amusing. Firefox very handily took me to a search > results page listing results for the word "museum", none of > which was the actual page in question. ... and Safari took me to www.museum.com. > Thanks for all the pointers! I guess I won't be suggesting the > use of such TLDs as gmail and ymail as a way to shorten up > email addresses for people, given the inconsistent behaviour > of client resolvers. ^_^; This is not only about client resolvers, it's equally about the individual applications and their choice of how to handle a single-label domain name, or just domain names (FQDN or not) in particular. Most often you'll see that the regular expressions used to parse what is considered to be a valid domain -- or even the policy that decides whether a given name has a special meaning or not -- will vary wildly. Most of them are wrong, or don't do the expected thing. From johnl at iecc.com Mon Jun 30 11:24:45 2008 From: johnl at iecc.com (John Levine) Date: Mon, 30 Jun 2008 12:24:45 -0400 (EDT) Subject: ICANN opens up Pandora's Box of new TLDs In-Reply-To: <63ac96a50806300905s168c3da9m6d636067bafe3c45@mail.gmail.com> References: <63ac96a50806300036u5c1a9bbdq4efb8e4879650434@mail.gmail.com> <20080630144723.3290.qmail@simone.iecc.com> <63ac96a50806300905s168c3da9m6d636067bafe3c45@mail.gmail.com> Message-ID: >> In the usual way. Try typing this into your browser's address bar: >> >> http://museum/ > > That was amusing. Firefox very handily took me to a search > results page listing results for the word "museum", none of > which was the actual page in question. Gee, it works fine for me in Firefox 2.0.0.14. I'd suggest filing a bug report against your OS vendor to fix their resolver library. > Thanks for all the pointers! I guess I won't be suggesting the > use of such TLDs as gmail and ymail as a way to shorten up > email addresses for people, given the inconsistent behaviour > of client resolvers. ^_^; Too bad. You might try writing the guy whose address is n at ai (yes, his name is Ian) and see what his experience has been. Regards, John Levine, johnl at iecc.com, Primary Perpetrator of "The Internet for Dummies", Information Superhighwayman wanna-be, http://www.johnlevine.com, ex-Mayor "More Wiener schnitzel, please", said Tom, revealingly. From jason.iannone at gmail.com Mon Jun 30 12:03:07 2008 From: jason.iannone at gmail.com (Jason Iannone) Date: Mon, 30 Jun 2008 11:03:07 -0600 Subject: rib dumps In-Reply-To: <486875D5.40909@psg.com> References: <486875D5.40909@psg.com> Message-ID: renesys? On Sun, Jun 29, 2008 at 11:57 PM, Randy Bush wrote: > i am looking for date-stamped rib dumps going back years from a peering > edge router that is fairly 'stable', i.e. multi-peer dfz but the number > of peers changes infrequently. > > [ routeviews and ris do not meet the above description as they are not > at all stable in the number of peers. ] > > [ your internal router which feeds off route reflectors does not meet > the above description, as it is not peered externally to multiple peers. ] > > thanks! > > randy > > > From Valdis.Kletnieks at vt.edu Mon Jun 30 11:54:40 2008 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 30 Jun 2008 12:54:40 -0400 Subject: ICANN opens up Pandora's Box of new TLDs In-Reply-To: Your message of "Sun, 29 Jun 2008 17:55:53 EDT." <200806292155.m5TLtrnE062355@himinbjorg.tucs-beachin-obx-house.com> References: <200806292155.m5TLtrnE062355@himinbjorg.tucs-beachin-obx-house.com> Message-ID: <29008.1214844880@turing-police.cc.vt.edu> On Sun, 29 Jun 2008 17:55:53 EDT, "Tuc at T-B-O-H.NET" said: > 220 Sending HELO/EHLO constitutes acceptance of this agreement Even in a UCITA state that has onerous rules regarding shrink-wrapped EULA terms, I think you'd have a very hard time getting a court to enforce an alleged contract based on this. And it's different from the usual suggestion to put "all activity may be monitored" in your telnet/ssh login banners, because there's an expectation that the human will look at a login banner when they login, but there's no expectation that an SMTP server will look at the 220 banner any further than checking the first digit is a '2' (go read the section on SMTP reply codes in RFC2821). Feel free to cite any relevant case law (in fact, even the case law on login banners read by humans is a tad skimpy - in most cases, it does nothing for intruders, but it protects you from your own users complaining their privacy was violated)... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From simonw at zynet.net Mon Jun 30 12:21:10 2008 From: simonw at zynet.net (Simon Waters) Date: Mon, 30 Jun 2008 18:21:10 +0100 Subject: ICANN opens up Pandora's Box of new TLDs In-Reply-To: References: <63ac96a50806300036u5c1a9bbdq4efb8e4879650434@mail.gmail.com> <63ac96a50806300905s168c3da9m6d636067bafe3c45@mail.gmail.com> Message-ID: <200806301821.10958.simonw@zynet.net> On Monday 30 June 2008 17:24:45 John Levine wrote: > >> In the usual way. Try typing this into your browser's address bar: > >> > >> http://museum/ > > > > That was amusing. Firefox very handily took me to a search > > results page listing results for the word "museum", none of > > which was the actual page in question. > > Gee, it works fine for me in Firefox 2.0.0.14. I'd suggest filing a bug > report against your OS vendor to fix their resolver library. I think that the following hold ... but I have a headache.... Since the hostname part of the URI does not contain a dot, RFC1034 section 3.1 applies (according to RFC 2396), the name is treated as relative initially, and the interpretation "varies from implementation to implementation". In particular if a "museum" name exists in your current domain, and/or other searches that may be applied to the lookup that may be correctly returned first. The language implies that "." need not be part of the search, so the URL need not work and the implementation could still be RFC conforming. Certainly there is scope for confusion here. My machines resolver is configurable - option ndots in resolv.conf - but ndots defaults to 1 - I'm sure the folks who wrote the resolver code considered the default carefully. Clearly an area ICANN need to ponder, if they haven't already, as changing the resolver defaults globally might undermine the stability of the root name servers. And introducing new domains will encourage vendors to change their resolvers default behaviour (even for areas where it is already technically RFC conforming, if not "least surprise" conforming). > > Thanks for all the pointers! I guess I won't be suggesting the > > use of such TLDs as gmail and ymail as a way to shorten up > > email addresses for people, given the inconsistent behaviour > > of client resolvers. ^_^; > > Too bad. You might try writing the guy whose address is n at ai (yes, his > name is Ian) and see what his experience has been. Now that is an email address not a URI, so section 5 of RFC 2821 applies, and treating the domain as "relative" is "discouraged". So I'd expect his email address to work (with a few exceptions - just like addresses with apostrophes - some folks will have bad implementations). IE gets to the correct page here. Firefox on Windows did something else again - sigh (I'm sure it is can be corrected in the browser configuration somewhere). There is a squid proxy behind both of them. On the other hand if people need short domain names, my employers may have a couple to sell of the old fashioned variety the same total length as "museum" but without the added complications, and the ICANN fee is a lot less ;) From warren at kumari.net Mon Jun 30 12:22:04 2008 From: warren at kumari.net (Warren Kumari) Date: Mon, 30 Jun 2008 13:22:04 -0400 Subject: ICANN opens up Pandora's Box of new TLDs In-Reply-To: <29008.1214844880@turing-police.cc.vt.edu> References: <200806292155.m5TLtrnE062355@himinbjorg.tucs-beachin-obx-house.com> <29008.1214844880@turing-police.cc.vt.edu> Message-ID: <8CF9F0E7-708A-4478-8838-765085639DEF@kumari.net> On Jun 30, 2008, at 12:54 PM, Valdis.Kletnieks at vt.edu wrote: > On Sun, 29 Jun 2008 17:55:53 EDT, "Tuc at T-B-O-H.NET" said: > >> 220 Sending HELO/EHLO constitutes acceptance of this agreement > > Even in a UCITA state that has onerous rules regarding shrink- > wrapped EULA > terms, I think you'd have a very hard time getting a court to > enforce an > alleged contract based on this. And it's different from the usual > suggestion > to put "all activity may be monitored" in your telnet/ssh login > banners, because > there's an expectation that the human will look at a login banner > when they > login, but there's no expectation that an SMTP server will look at > the 220 > banner any further than checking the first digit is a '2' (go read > the section > on SMTP reply codes in RFC2821). > > Feel free to cite any relevant case law (in fact, even the case law on > login banners read by humans is a tad skimpy - in most cases, it > does nothing > for intruders, but it protects you from your own users complaining > their > privacy was violated)... I have found the biggest advantage of banners to be the fact that you learn to recognize your own devices *before* typing your password... It you *always* have a banner on *all* of your devices, you quickly learn to expect them... For example: ssh router1.example.net ************************************************************** * This device belongs to example.net. Don't login if you * are not supposed to be here... Blah blah blah. * <><><><><><><><><><><><><><><><><><><><><> ************************************************************* wkumari at router1.example.net's password: versus: ssh router1.exsmple.net wkumari at router1.exsmple.net's password: Having a cute, customized banner (not the default from the standard security templates) helps with this... W -- If the bad guys have copies of your MD5 passwords, then you have way bigger problems than the bad guys having copies of your MD5 passwords. -- Richard A Steenbergen From pauldotwall at gmail.com Mon Jun 30 12:34:00 2008 From: pauldotwall at gmail.com (Paul Wall) Date: Mon, 30 Jun 2008 13:34:00 -0400 Subject: Anyone from Qwest? In-Reply-To: References: Message-ID: <620fd17c0806301034i5c99267ch2a5078dd1906f10b@mail.gmail.com> Mehmet, Qwest is a rather large entity, so it would help to provide specifics about the nature of your problem and what department(s) you're looking for specifically. If this is the office DSL you've been trying to cancel on account of them not offering IPv6, I'm not sure the NANOG list is the best place to discuss it. A better place might be the dslreports.com forums, or: Customer Support Qwest DSL? Residential or Small Business Customers For questions on repair, trouble shooting or missing equipment, please call 800-247-7285. DSL Pro Customers For questions on repair, trouble shooting or missing equipment, please call 800-903-5003. Qwest DSL? Host Customers (such as ISP) Need your password? Call 888-234-XDSL (9375) and choose option #2 and options #2. For all other information, get help here. Sales and Ordering Information For your home: 800-244-1111 For business: 800-603-6000 Sincerely, Paul On Fri, Jun 27, 2008 at 8:22 PM, Mehmet Akcin wrote: > Anyone from Qwest senior sales team or VP can please contact me offlist? > > Thank you > > Mehmet > From sam_mailinglists at spacething.org Mon Jun 30 12:35:12 2008 From: sam_mailinglists at spacething.org (Sam Stickland) Date: Mon, 30 Jun 2008 18:35:12 +0100 Subject: IPv4 source routing options and IPv6 Type 0 Routing Header In-Reply-To: <4862AE02.6030201@ai.net> References: <200806250758.m5P7wen1027990@venus.xmundo.net> <4862AE02.6030201@ai.net> Message-ID: <48691950.1060009@spacething.org> Deepak Jain wrote: >> Quite a few times it has been mentioned to me that some peering >> agreements require support for the IPv4 source routing options. I was >> wondering whether this is still the case for some ISPs, or it is not >> the case anymore. > > Before we decommissioned our last open peering fabric, source-routing > was important to make sure your peer wasn't pointing default (or > similar) to you. With the advent of private (and far more limited) > bilateral peering as a preference to fabric based peering (at least > among the ones who set peering policies globally) this has become > less of an issue. > > RFC 5095 aside. > > Can someone give an example of how to use source routing to check a peers routing policy? Thanks, Sam From dot at dotat.at Mon Jun 30 12:36:06 2008 From: dot at dotat.at (Tony Finch) Date: Mon, 30 Jun 2008 18:36:06 +0100 Subject: ICANN opens up Pandora's Box of new TLDs In-Reply-To: <20080629195709.GA1569@sources.org> References: <20080627203205.51B612B7C02@mx5.roble.com> <20080629195709.GA1569@sources.org> Message-ID: On Sun, 29 Jun 2008, Stephane Bortzmeyer wrote: > > I am very curious of what tests a "security-aware programmer" can do, > based on the domain name, which will not be possible tomorrow, should > ICANN allow a few more TLDs. It makes the "public suffix list" project harder, but so long as the list of TLDs changes reasonably slowly, it shouldn't become impossible. http://publicsuffix.org/ Tony. -- f.anthony.n.finch http://dotat.at/ SOUTHEAST FITZROY: VARIABLE 3 OR 4 BECOMING SOUTHWESTERLY 5 OR 6. MODERATE, BECOMING ROUGH LATER. RAIN LATER. GOOD BECOMING MODERATE. From pauldotwall at gmail.com Mon Jun 30 12:38:04 2008 From: pauldotwall at gmail.com (Paul Wall) Date: Mon, 30 Jun 2008 13:38:04 -0400 Subject: what problem are we solving? (was Re: ICANN opens up Pandora'sBox of In-Reply-To: References: <200806290231.m5T2VXob020706@aurora.sol.net> <7ff145960806291320x4a768f62x31cf7262ae945b6f@mail.gmail.com> Message-ID: <620fd17c0806301038v7135675x1dcbce4de32fd866@mail.gmail.com> Gadi, I tried to find even the smallest token of operational relevance on your postings on this thread, and I'm coming up short. Could you please do us a favor and stop posting until such a time when you're able to comply with the list's AUP? Paul (not a member of MLC, my opinions only) From jgreco at ns.sol.net Mon Jun 30 12:38:51 2008 From: jgreco at ns.sol.net (Joe Greco) Date: Mon, 30 Jun 2008 12:38:51 -0500 (CDT) Subject: what problem are we solving? (was Re: ICANN opens up Pandora'sBox In-Reply-To: from "Peter Beckman" at Jun 29, 2008 01:21:07 PM Message-ID: <200806301738.m5UHcpo2084058@aurora.sol.net> > On Sat, 28 Jun 2008, Joe Greco wrote: > > For example, I *ought* to be able to find the Police Department for the City > > of Milwaukee at something reasonable, such as "police.ci.milwaukee.wi.us". > > If I then needed the police for Wauwatosa, "police.ci.wauwatosa.wi.us", or > > for Waukesha, "police.ci.waukesha.wi.us". > > > > To extend that principle, companies that have an exclusively local presence > > probably don't need to be occupying space in a TLD. That's the Marty's > > Pizza example. > > martyspizza.brookfield.wi.us works great. At what point in Marty's > expansion does Marty's Pizza get to move to a TLD? The RFC leaves > management decisions to an alluded to but unnamed group. That doesn't need to be a "management decision" by some third party group. That *could* be something we would have guided people through, in the same way that 1480 provides other guidance. I see usefulness in having scopes that are local (city/village/etc), state, country, and global. There's no reason that you couldn't start out local, and as you grew, get a state level domain (martyspizza.wi.us), and if you went national (martyspizza.us), etc. In many (most!) cases, businesses do not make significant growth in a rapid fashion. > Plus, WTF: John-Muir.Middle.Santa-Monica.K12.CA.US > Cut and Paste or die trying. I doubt parents will remember or type that. Actually, that has to do with what I was talking about in continuing to develop a reasonable system. Quite frankly, if I was in that school district, I see no reason why my computer couldn't be aware of that domain, and actually have "http://john-muir" or some similar mechanism actually work. The ideal is probably more complex in implementation, but does not need to be more complex in use. > Besides, sophisticated search engines are making Domain Names less > relevant anyway. I can find Marty's Pizza in Brookfield via Google or > Yahoo in a matter of seconds. Let the search engines organize the web, > not DNS. > > Schools are going short and sweet, just like businesses, using the > existing TLDs. martyspizza.net is fine. So is johnmuirsl.org. No need > for 30 more or 3000 more TLDs. I would agree that we don't need more TLD's. But the namespace, as it exists, is messy, and it's nasty to expect that people will always have to use a browser and a search engine to find their destination's domain name. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From LarrySheldon at cox.net Mon Jun 30 12:45:32 2008 From: LarrySheldon at cox.net (Laurence F. Sheldon, Jr.) Date: Mon, 30 Jun 2008 12:45:32 -0500 Subject: what problem are we solving? (was Re: ICANN opens up Pandora'sBox of In-Reply-To: <620fd17c0806301038v7135675x1dcbce4de32fd866@mail.gmail.com> References: <200806290231.m5T2VXob020706@aurora.sol.net> <7ff145960806291320x4a768f62x31cf7262ae945b6f@mail.gmail.com> <620fd17c0806301038v7135675x1dcbce4de32fd866@mail.gmail.com> Message-ID: <48691BBC.9060005@cox.net> Paul Wall wrote: [bagged and tagged] P,K,B. From dot at dotat.at Mon Jun 30 12:47:30 2008 From: dot at dotat.at (Tony Finch) Date: Mon, 30 Jun 2008 18:47:30 +0100 Subject: ICANN opens up Pandora's Box of new TLDs In-Reply-To: <63ac96a50806300036u5c1a9bbdq4efb8e4879650434@mail.gmail.com> References: <20080629214555.482862B7C03@mx5.roble.com> <20080630064659.GA6095@sources.org> <63ac96a50806300036u5c1a9bbdq4efb8e4879650434@mail.gmail.com> Message-ID: On Mon, 30 Jun 2008, Matthew Petach wrote: > > Or should I always ensure that resolvers reach my domain explicitly by > including the trailing "dot" in all uses, so that my email would be > given out as "myname at smtp." in the hopes that everyone would correctly > remember to add the "." at the end when entering my email address into > their mail clients? Trailing dots in email addresses are a syntax error. > In the past, this wasn't really a concern, as you never had a case of a > single entity owning an entire TLD, and as such you'd never see A or MX > records showing up for an entire TLD. Not true. There have been TLDs with MX and A records for a long time, though they tend to be badly set up, and many MTAs treat single-component domains specially such that email to these TLDs will often not work. http://fanf.livejournal.com/72486.html Tony. -- f.anthony.n.finch http://dotat.at/ HUMBER THAMES DOVER WIGHT PORTLAND: SOUTHWEST BACKING SOUTHEAST 3 OR 4, OCCASIONALLY 5 AT FIRST AND LATER. SLIGHT OR MODERATE. MAINLY FAIR. MAINLY GOOD. From frnkblk at iname.com Mon Jun 30 13:02:29 2008 From: frnkblk at iname.com (Frank Bulk) Date: Mon, 30 Jun 2008 13:02:29 -0500 Subject: ICANN opens up Pandora's Box of new TLDs In-Reply-To: <200806301821.10958.simonw@zynet.net> References: <63ac96a50806300036u5c1a9bbdq4efb8e4879650434@mail.gmail.com> <63ac96a50806300905s168c3da9m6d636067bafe3c45@mail.gmail.com> <200806301821.10958.simonw@zynet.net> Message-ID: It would be helpful if someone could put together of web page of different links so that people could test the native resolvers for each OS and applications (web browsers primarily, but also DNS clients separated from the OS stack such as dig and nslookup). Perhaps some of this brokenness can be illuminated sooner rather than later. Frank -----Original Message----- From: Simon Waters [mailto:simonw at zynet.net] Sent: Monday, June 30, 2008 12:21 PM To: nanog at nanog.org Subject: Re: ICANN opens up Pandora's Box of new TLDs On Monday 30 June 2008 17:24:45 John Levine wrote: > >> In the usual way. Try typing this into your browser's address bar: > >> > >> http://museum/ > > > > That was amusing. Firefox very handily took me to a search > > results page listing results for the word "museum", none of > > which was the actual page in question. > > Gee, it works fine for me in Firefox 2.0.0.14. I'd suggest filing a bug > report against your OS vendor to fix their resolver library. I think that the following hold ... but I have a headache.... Since the hostname part of the URI does not contain a dot, RFC1034 section 3.1 applies (according to RFC 2396), the name is treated as relative initially, and the interpretation "varies from implementation to implementation". In particular if a "museum" name exists in your current domain, and/or other searches that may be applied to the lookup that may be correctly returned first. The language implies that "." need not be part of the search, so the URL need not work and the implementation could still be RFC conforming. Certainly there is scope for confusion here. My machines resolver is configurable - option ndots in resolv.conf - but ndots defaults to 1 - I'm sure the folks who wrote the resolver code considered the default carefully. Clearly an area ICANN need to ponder, if they haven't already, as changing the resolver defaults globally might undermine the stability of the root name servers. And introducing new domains will encourage vendors to change their resolvers default behaviour (even for areas where it is already technically RFC conforming, if not "least surprise" conforming). > > Thanks for all the pointers! I guess I won't be suggesting the > > use of such TLDs as gmail and ymail as a way to shorten up > > email addresses for people, given the inconsistent behaviour > > of client resolvers. ^_^; > > Too bad. You might try writing the guy whose address is n at ai (yes, his > name is Ian) and see what his experience has been. Now that is an email address not a URI, so section 5 of RFC 2821 applies, and treating the domain as "relative" is "discouraged". So I'd expect his email address to work (with a few exceptions - just like addresses with apostrophes - some folks will have bad implementations). IE gets to the correct page here. Firefox on Windows did something else again - sigh (I'm sure it is can be corrected in the browser configuration somewhere). There is a squid proxy behind both of them. On the other hand if people need short domain names, my employers may have a couple to sell of the old fashioned variety the same total length as "museum" but without the added complications, and the ICANN fee is a lot less ;) From brunner at nic-naa.net Mon Jun 30 13:16:12 2008 From: brunner at nic-naa.net (Eric Brunner-Williams) Date: Mon, 30 Jun 2008 11:16:12 -0700 Subject: ICANN opens up Pandora's Box of new TLDs In-Reply-To: References: <20080627203205.51B612B7C02@mx5.roble.com> <20080629195709.GA1569@sources.org> Message-ID: <486922EC.8030308@nic-naa.net> Tony Finch wrote: > On Sun, 29 Jun 2008, Stephane Bortzmeyer wrote: > >> I am very curious of what tests a "security-aware programmer" can do, >> based on the domain name, which will not be possible tomorrow, should >> ICANN allow a few more TLDs. >> > > It makes the "public suffix list" project harder, but so long as the list > of TLDs changes reasonably slowly, it shouldn't become impossible. > http://publicsuffix.org/ > > Tony. > Assuming O(1k) applications, and the numbers ICANN staff were using in February were 300 to 600, with the determining factors (a) existence of subsequent rounds and their temporal offsets, (b) actual application fee, originally guesstimated in the USD 100k range, now twice that, a sort of "self-imposed auction based on pain", or rumor mill run amok, depending on one point of view, and (c) the number of sunspots in the quarter that ICANN actually accepts applications; and application survival rates of 10% to 50% in the evaluation processes; then the root string insertion frequency may be as bounded above by 24 hours on average and below by 168 hours on average. It will be different. I pointed this out in the Registrar Constituency meeting in Paris Tuesday last, that our assumptions about the size of the registrars was already off by more than an order of magnitude, and our assumption about the size of the registries was about to fail as well, and that there were some additional non-scaling reasons to revisit the EPP design. Eric From dot at dotat.at Mon Jun 30 13:19:45 2008 From: dot at dotat.at (Tony Finch) Date: Mon, 30 Jun 2008 19:19:45 +0100 Subject: DNS and potential energy In-Reply-To: <20080629235958.GA16853@vacation.karoshi.com.> References: <200806290231.m5T2VXob020706@aurora.sol.net> <393FF04B-6BDC-41CE-BCF3-97FC6D0226A2@ca.afilias.info> <20080629235958.GA16853@vacation.karoshi.com.> Message-ID: On Sun, 29 Jun 2008, bmanning at vacation.karoshi.com wrote: > > one might legitimately argue that ICANN is in need of > some serious regulation.... > > that can happen at that national level or on the international > level. Doesn't ICANN already work like an international regulator? Tony. -- f.anthony.n.finch http://dotat.at/ SHANNON ROCKALL: MAINLY SOUTHERLY 5 TO 7, OCCASIONALLY GALE 8 AND BECOMING CYCLONIC FOR A TIME, DECREASING 4 IN NORTH ROCKALL. ROUGH OR VERY ROUGH. RAIN THEN SHOWERS. POOR BECOMING GOOD. From jra at baylink.com Mon Jun 30 13:49:19 2008 From: jra at baylink.com (Jay R. Ashworth) Date: Mon, 30 Jun 2008 14:49:19 -0400 Subject: ICANN opens up Pandora's Box of new TLDs In-Reply-To: <63ac96a50806300905s168c3da9m6d636067bafe3c45@mail.gmail.com> References: <63ac96a50806300036u5c1a9bbdq4efb8e4879650434@mail.gmail.com> <20080630144723.3290.qmail@simone.iecc.com> <63ac96a50806300905s168c3da9m6d636067bafe3c45@mail.gmail.com> Message-ID: <20080630184919.GD8195@cgi.jachomes.com> On Mon, Jun 30, 2008 at 09:05:41AM -0700, Matthew Petach wrote: > > In the usual way. Try typing this into your browser's address bar: > > > > http://museum/ > > That was amusing. Firefox very handily took me to a search > results page listing results for the word "museum", none of > which was the actual page in question. > > In order to reach that page, in Firefox 1.5.0.12, I had to actually > enter "http://museum./ and add the trailing dot to force the > browser to *not* treat it as a stub token. FWIW, FF3.0/Win dealt with that properly for me. It also deals properly, on the same machine, with several internal webservers, which I also hit with one-word names, but which actually resolve, of course, by the search list on the machine. So FF3, at least, will try to resolve oneword as oneword., before moving along. Cheers, -- jra -- Jay R. Ashworth jra at baylink.com Designer +-Internetworking------+---------+ RFC 2100 Ashworth & Associates | Best Practices Wiki | | '87 e24 St Petersburg FL USA +-http://bestpractices.wikia.com-+ +1 727 647 1274 If you can read this... thank a system administrator. Or two. --me From josmon at rigozsaurus.com Mon Jun 30 14:10:46 2008 From: josmon at rigozsaurus.com (John Osmon) Date: Mon, 30 Jun 2008 13:10:46 -0600 Subject: IPv4 source routing options and IPv6 Type 0 Routing Header In-Reply-To: <48691950.1060009@spacething.org> References: <200806250758.m5P7wen1027990@venus.xmundo.net> <4862AE02.6030201@ai.net> <48691950.1060009@spacething.org> Message-ID: <20080630191046.GA3753@jeeves.rigozsaurus.com> On Mon, Jun 30, 2008 at 06:35:12PM +0100, Sam Stickland wrote: > Can someone give an example of how to use source routing to check a > peers routing policy? Channelling from a similar private conversation I had many years ago: Seeing if packets directed to prefixes that you're not announcing come back to you is interesting (and can be an indicator that someone is pointing default at you). Seeing if packets directed to prefixes you *are* announcing *do* come back to you is also interesting. So, an example might be to send a traceroute across a peer's link via source routing, and watching the result. From beckman at angryox.com Mon Jun 30 14:16:15 2008 From: beckman at angryox.com (Peter Beckman) Date: Mon, 30 Jun 2008 15:16:15 -0400 Subject: what problem are we solving? (was Re: ICANN opens up Pandora'sBox In-Reply-To: <200806301738.m5UHcpo2084058@aurora.sol.net> References: <200806301738.m5UHcpo2084058@aurora.sol.net> Message-ID: On Mon, 30 Jun 2008, Joe Greco wrote: > I see usefulness in having scopes that are local (city/village/etc), > state, country, and global. There's no reason that you couldn't start > out local, and as you grew, get a state level domain (martyspizza.wi.us), > and if you went national (martyspizza.us), etc. In many (most!) cases, > businesses do not make significant growth in a rapid fashion. The selfish will abuse the lack of RFC1480 management and go straight to martyspizza.us, even though they have one store, because it's available at the time. > Actually, that has to do with what I was talking about in continuing to > develop a reasonable system. Quite frankly, if I was in that school > district, I see no reason why my computer couldn't be aware of that > domain, and actually have "http://john-muir" or some similar mechanism > actually work. The ideal is probably more complex in implementation, > but does not need to be more complex in use. Does the DNS provider or ISP decide that? Or are you just referring to a bookmarking feature in your browser? Which then makes moot any RFC1480 friendly URL. Namespaces in DNS that are globally recognized are different than your example above. > I would agree that we don't need more TLD's. But the namespace, as it > exists, is messy, and it's nasty to expect that people will always have > to use a browser and a search engine to find their destination's domain > name. Nobody can or will cleanup the existing namespaces. New TLDs will continue to make them more messy. More court battles over new TLDs will come up. The wealthy will get their own TLDs (I can't afford .beckman, but I'm sure Beckman Instruments can, who already own beckman.com, and I'll just be screwed again), and small guys will not. Search engines and browser tools will render the value of domain names to approaching zero, .com will remain the namespace of choice, and that new TLDs will be for the wealthy i.e. http://google/ and http://coke/ and there will be more court battles for those trademarks. Beckman --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com http://www.angryox.com/ --------------------------------------------------------------------------- From brunner at nic-naa.net Mon Jun 30 14:36:27 2008 From: brunner at nic-naa.net (Eric Brunner-Williams) Date: Mon, 30 Jun 2008 12:36:27 -0700 Subject: what problem are we solving? (was Re: ICANN opens up Pandora'sBox In-Reply-To: References: <200806301738.m5UHcpo2084058@aurora.sol.net> Message-ID: <486935BB.5060206@nic-naa.net> Peter Beckman wrote: > On Mon, 30 Jun 2008, Joe Greco wrote: > >> I see usefulness in having scopes that are local (city/village/etc), >> state, country, and global. There's no reason that you couldn't start >> out local, and as you grew, get a state level domain >> (martyspizza.wi.us), >> and if you went national (martyspizza.us), etc. In many (most!) cases, >> businesses do not make significant growth in a rapid fashion. > > The selfish will abuse the lack of RFC1480 management and go straight to > martyspizza.us, even though they have one store, because it's > available at > the time. > ... For which, if you are so inclined, you may credit, or damn, NeuStar. The original bid to the US DoC did not envision the "dotless" or "flat" model displacing the "dotfull" or "hierarchical" model. The US DoC has not yet seen fit to solicit tenders from operators intending to offer a policy model other than that of the current operator. For those of you in the US, who think its worth doing something about, you've about three years to get your congress critter motivated to enable the DoC to find an alternative criteria to the one that allowed the incumbent operator to win the renewal. Some reason(s) why "flat" and all its "first-come, only-served" model is less useful than something else. From lists at internetpolicyagency.com Mon Jun 30 15:12:09 2008 From: lists at internetpolicyagency.com (Roland Perry) Date: Mon, 30 Jun 2008 21:12:09 +0100 Subject: Mail Server best practices - was: Pandora's Box of new TLDs In-Reply-To: References: <20080628161844.GT31980@catpipe.net> <20080628180212.GA35151@catpipe.net> <4866B387.2070900@vaxination.ca> <20080629200826.GD1569@sources.org> Message-ID: >On Sat, Jun 28, 2008 at 05:25:16PM -0500, > Chris Owen wrote > a message of 53 lines which said: >It is because, if someone reports (by telephone, IRC or IRL) that he >sent an email and I did not receive it, I regard as VERY IMPORTANT to >be able to check the spam folder (with a search tool, not by hand) and >go back to him saying "No, we really did not receive it". In article , Frank Bulk - iNAME writes >You mean, you don't employ *any* spam mitigation techniques besides sorting? >Because if you do anything, even as basic as RBLs, you're not being >consistent with your stance. I agree completely with Chris Owen's approach, even though I use spam mitigation techniques. The reason for this is because those "lost" emails that I very occasionally rescue from the spam bucket are: NOT sent by someone on an RBL NOT sent to an unpublished and unused address (eg sales at internetpolicyagency.com) etc. -- Roland Perry From jra at baylink.com Mon Jun 30 15:36:07 2008 From: jra at baylink.com (Jay R. Ashworth) Date: Mon, 30 Jun 2008 16:36:07 -0400 Subject: ICANN opens up Pandora's Box of new TLDs In-Reply-To: References: <63ac96a50806300036u5c1a9bbdq4efb8e4879650434@mail.gmail.com> <63ac96a50806300905s168c3da9m6d636067bafe3c45@mail.gmail.com> <200806301821.10958.simonw@zynet.net> Message-ID: <20080630203607.GF8195@cgi.jachomes.com> On Mon, Jun 30, 2008 at 01:02:29PM -0500, Frank Bulk wrote: > It would be helpful if someone could put together of web page of different > links so that people could test the native resolvers for each OS and > applications (web browsers primarily, but also DNS clients separated from > the OS stack such as dig and nslookup). Doing that comlpetely generally turns out to have more layers than you might expect. My first cut is here: http://bestpractices.wikia.com/wiki/Unusual_Domain_Names Cheers, -- jra -- Jay R. Ashworth jra at baylink.com Designer +-Internetworking------+---------+ RFC 2100 Ashworth & Associates | Best Practices Wiki | | '87 e24 St Petersburg FL USA +-http://bestpractices.wikia.com-+ +1 727 647 1274 If you can read this... thank a system administrator. Or two. --me From jra at baylink.com Mon Jun 30 15:45:23 2008 From: jra at baylink.com (Jay R. Ashworth) Date: Mon, 30 Jun 2008 16:45:23 -0400 Subject: ICANN opens up Pandora's Box of new TLDs In-Reply-To: References: <20080629214555.482862B7C03@mx5.roble.com> <20080630064659.GA6095@sources.org> <63ac96a50806300036u5c1a9bbdq4efb8e4879650434@mail.gmail.com> Message-ID: <20080630204523.GG8195@cgi.jachomes.com> On Mon, Jun 30, 2008 at 06:47:30PM +0100, Tony Finch wrote: > On Mon, 30 Jun 2008, Matthew Petach wrote: > > Or should I always ensure that resolvers reach my domain explicitly by > > including the trailing "dot" in all uses, so that my email would be > > given out as "myname at smtp." in the hopes that everyone would correctly > > remember to add the "." at the end when entering my email address into > > their mail clients? > > Trailing dots in email addresses are a syntax error. RFC 2822 3.4 punts the components of dot-atom to STD 3/13/14. STD 13 is RFC 1035, which, in 2.3.1, suggests (but does not impose) a standard for domain name literals which appears to expand to a pattern which does not in fact permit a trailing dot. In fact, Mutt (1.2.5) permits the trailing dot, and delivers the mail, and all the intervening MTAs (I only tested local mail on my machine, running Postfix) let the message through -- it came through apparently having been rewritten by Postfix to lose the trailing dot; there was an X-Original-To header. Tony: what authority were you depending on for your assertion, and in which context do you make it? Cheers, -- jr 'comp.mail.headers lives!' -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com '87 e24 St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 Those who cast the vote decide nothing. Those who count the vote decide everything. -- (Joseph Stalin) From morrowc.lists at gmail.com Mon Jun 30 16:06:17 2008 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 30 Jun 2008 17:06:17 -0400 Subject: ICANN opens up Pandora's Box of new TLDs In-Reply-To: <20080630204523.GG8195@cgi.jachomes.com> References: <20080629214555.482862B7C03@mx5.roble.com> <20080630064659.GA6095@sources.org> <63ac96a50806300036u5c1a9bbdq4efb8e4879650434@mail.gmail.com> <20080630204523.GG8195@cgi.jachomes.com> Message-ID: <75cb24520806301406m6b3d7bdfu3e19f78ad1e8c08@mail.gmail.com> On Mon, Jun 30, 2008 at 4:45 PM, Jay R. Ashworth wrote: > > RFC 2822 3.4 punts the components of dot-atom to STD 3/13/14. > > STD 13 is RFC 1035, which, in 2.3.1, suggests (but does not impose) a > standard for domain name literals which appears to expand to a pattern > which does not in fact permit a trailing dot. > > In fact, Mutt (1.2.5) permits the trailing dot, and delivers the mail, > and all the intervening MTAs (I only tested local mail on my machine, > running Postfix) let the message through -- it came through apparently > having been rewritten by Postfix to lose the trailing dot; there was an > X-Original-To header. > > Tony: what authority were you depending on for your assertion, and in > which context do you make it? This whole set of arguements is one of the points Bill Manning was bringing up, yes? Clients and OS's and other things make oddball assumptions (museum really is www.museum.com for some versions of FF or IE or ....) Without adequate time to fix this in code (properly fix this) support calls and mis-direction are going to be an issue :( Now, lump on IDN foo!!! wee! How fast will IEX be out of normal use? FFY? who runs a largish traffic magnet and can tell when the last Windows 98 IE4 client hit them? Matt Petach, let's nominate him for that stat update :) -Chris From jra at baylink.com Mon Jun 30 16:06:40 2008 From: jra at baylink.com (Jay R. Ashworth) Date: Mon, 30 Jun 2008 17:06:40 -0400 Subject: what problem are we solving? (was Re: ICANN opens up Pandora's Box of new TLDs) In-Reply-To: References: <171423de0806271024h73e9a181t1df338aa5fe84ef5@mail.gmail.com> <4D0B482D-8FD5-48A5-9FF6-C2011AA7ACB5@virtualized.org> <20080628035954.BC78F213C3@spunkymail-a9.g.dreamhost.com> <4C0790EA-33E5-43F2-B281-215A0B37AE4F@virtualized.org> Message-ID: <20080630210640.GH8195@cgi.jachomes.com> On Sat, Jun 28, 2008 at 12:49:35PM -0500, Frank Bulk - iNAME wrote: > One way to provide protection is too allow those who have the domain portion > of any domain.(com|net|org|...) to have first dibs for the domain of any new > gTLD. i.e. if nanog.org, nanog.com, nanog.net, etc. would have first dibs > on nanog.thisisgreatstuff. > > Or is that too simplistic and fraught with division? Oh, ick. No, it's just dumb. Could someone, anyone, anywhere, point me to *any case law in any jurisdiction whatsoever* which tends even to *suggest* that the mere purchase and deployment of a domain name *in itself* in any way constitutes infringement upon the rights of some holder of a trademark to some component of that domain name? or else shut the hell up about it, already? Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com '87 e24 St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 Those who cast the vote decide nothing. Those who count the vote decide everything. -- (Joseph Stalin) From jra at baylink.com Mon Jun 30 16:13:14 2008 From: jra at baylink.com (Jay R. Ashworth) Date: Mon, 30 Jun 2008 17:13:14 -0400 Subject: what problem are we solving? (was Re: ICANN opens up Pandora's Box of new TLDs) In-Reply-To: <486555D3.7090107@vaxination.ca> References: <171423de0806271024h73e9a181t1df338aa5fe84ef5@mail.gmail.com> <486555D3.7090107@vaxination.ca> Message-ID: <20080630211314.GI8195@cgi.jachomes.com> On Fri, Jun 27, 2008 at 05:04:19PM -0400, Jean-Fran?ois Mezei wrote: > Bill Nash wrote: > > Off the top of my head, I can see some high dollar fist fights breaking > > out for .sex, .porn, .games, .hotel, etc. It'll be like the .alt tree on > > usenet for people with money. There may also be an actual fist fight over > > TLDs like .irc, .leet, .goatse, and .krad. Maybe not .krad. > > Say I am a pastry chef, and I pay $40 per year for "pastry.com", I got > it because I signed up early and now cherish my domain name. I am a > small business. > > But now, some rich guy can come in and bid for .pastry > > I have no money to participate in this endeavour, and no intentions of > running my own TLD. All I can do is voice an objection, but if the other > guy is also involved in food, he is likely to convince ICANN's comittees > that it is a legitimate request. > > Then you end up with pastry.com being the original small business, and > .pastry being anything else. This will lead to a lot of confusion. I don't see that, and I don't see why a holder of pastry.com would have any valid reason at all to block a .pastry TLD registry -- let's remember; we're talking about registries here, not registrars. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com '87 e24 St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 Those who cast the vote decide nothing. Those who count the vote decide everything. -- (Joseph Stalin) From jra at baylink.com Mon Jun 30 16:22:16 2008 From: jra at baylink.com (Jay R. Ashworth) Date: Mon, 30 Jun 2008 17:22:16 -0400 Subject: what problem are we solving? (was Re: ICANN opens up Pandora's Box of In-Reply-To: <200806281346.m5SDkX9b094171@aurora.sol.net> References: <171423de0806271024h73e9a181t1df338aa5fe84ef5@mail.gmail.com> <200806281346.m5SDkX9b094171@aurora.sol.net> Message-ID: <20080630212216.GJ8195@cgi.jachomes.com> On Sat, Jun 28, 2008 at 08:46:33AM -0500, Joe Greco wrote: > Yes. It completely marginalizes the remaining positive qualities of the > Domain Name System as a way to find things, in the name of giving people > "more options." The Domain Name System is not now, and never has been, away to *find* things, anymore than 123 Elm St, Worcester MA is a way to *find* a house. It's a way to *denote* things, uniquely. You *find* an address by looking in a map directory, and then on the map. You find things on the Internet using a search engine, and the second-order derivatives. > Let me start by saying that I believe that the trends in the DNS have been > going the wrong way for well over a decade. The insistence on the part of > many that the namespace be flattened is just a poor choice. People are now > used to trying ".com" to reach a company. In some cases, this makes > fair sense; I can see why "ibm.com" or "seagate.com" are that way, even > though in some cases there are namespace collisions with other trademarks. "Famous trademarks". > In others, it's ridiculous - why the heck do I get someplace in California > when I go to "martyspizza.com", rather than our local very excellent pizza > place? (sadly this example is less effective now, they managed to get > "martyspizza.net" a few years back). Sure. Local collisions are inevitable. Blocker Transfer, a local moving company client of mine, wanted to register a domain back in 1997... when the company was 99 years old. blocker.com was taken. They took blocker100.com, and promoted it. > We never had any business allowing small, local businesses to register in > .com, or non-networking companies to register in .net, or non-organizations > in .org... but a whole generation of Internet "professionals" "knew better" > and the end result at the end of the road is that DNS will end up being > almost as useless as IPv4 numbers for identifying the more obscure bits of > the Internet. Correct; this is exactly the problem. But a lot of it stems, Joe, from the misconception you led with. > It would have been much better for us to fix some of the obvious problems > with DNS back in the day. Instead, we didn't bother, and instead allowed > "market forces" to dictate what happened next. This of course got buyers > whatever they wanted (which was generally "short names!"), but what buyers > wanted didn't necessarily map well into what would have made sense for > /users/ of the system, which would have been "predictability of names." See all the debates about area code overlays vs splits, and the extension of US telephone Directory Numbers to 12 digits. > We are now reaping the evolution of that into even further mayhem. Yep. > I look forward to many more years of having to remember that Marty's > Pizza is "martyspizza.net" instead of "martyspizza.brookfield.wi.us", > that Milwaukee's Department of Public Works is at "mpw.net" instead of > "dpw.ci.milwaukee.wi.us", etc. I am, in turn, very pleased with a lot of my local municipalities. Some of them, admittedly, *have* silly pinellascounty.org or pinellas-park.com names, but they also answer to the long-form .fl.us names you would prefer. Sometimes they redirect one way, sometimes the other; sometimes each domain merely overlays the other. But at least they are, as you say, deterministic. I don't think it's fixable anymore, either. But I remain determined to spit into the wind, Jim notwithstanding. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com '87 e24 St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 Those who cast the vote decide nothing. Those who count the vote decide everything. -- (Joseph Stalin) From jra at baylink.com Mon Jun 30 16:26:10 2008 From: jra at baylink.com (Jay R. Ashworth) Date: Mon, 30 Jun 2008 17:26:10 -0400 Subject: what problem are we solving? (was Re: ICANN opens up Pandora'sBox of In-Reply-To: References: <200806290231.m5T2VXob020706@aurora.sol.net> Message-ID: <20080630212610.GK8195@cgi.jachomes.com> On Sun, Jun 29, 2008 at 01:21:07PM -0400, Peter Beckman wrote: > Plus, WTF: John-Muir.Middle.Santa-Monica.K12.CA.US > Cut and Paste or die trying. I doubt parents will remember or type that. No one does either. They search for it, or pick it out of an email. But *I can read that domain name and know what it points to*. More importantly, it is possible for me to learn that k12.ca.us is picky about whom it hands it's subdomains to, and therefore I can have a reasonable guess that (DNS spoofing aside) that domain actually belongs to a school. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com '87 e24 St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 Those who cast the vote decide nothing. Those who count the vote decide everything. -- (Joseph Stalin) From davidu at everydns.net Mon Jun 30 16:41:27 2008 From: davidu at everydns.net (David Ulevitch) Date: Mon, 30 Jun 2008 14:41:27 -0700 Subject: Contacts at Indom (aka, indomco) Message-ID: <48695307.9080400@everydns.net> NANOG, I'm having a heck of a time reaching anyone at Indom, a large French DNS provider. If anyone has a real human contact there (not simply technique at indom dot com) that'd be of great help. Thanks, David Ulevitch From jfmezei at vaxination.ca Mon Jun 30 19:34:25 2008 From: jfmezei at vaxination.ca (=?ISO-8859-1?Q?Jean-Fran=E7ois_Mezei?=) Date: Mon, 30 Jun 2008 20:34:25 -0400 Subject: ICANN opens up Pandora's Box of new TLDs In-Reply-To: <20080630184919.GD8195@cgi.jachomes.com> References: <63ac96a50806300036u5c1a9bbdq4efb8e4879650434@mail.gmail.com> <20080630144723.3290.qmail@simone.iecc.com> <63ac96a50806300905s168c3da9m6d636067bafe3c45@mail.gmail.com> <20080630184919.GD8195@cgi.jachomes.com> Message-ID: <48697B91.7050603@vaxination.ca> Jay R. Ashworth wrote: > It also deals properly, on the same machine, with several internal > webservers, which I also hit with one-word names, but which actually > resolve, of course, by the search list on the machine. > > So FF3, at least, will try to resolve oneword as oneword., before > moving along. Firefox has a gazillion "advanced" config settings that allow you to remove all the fluff added to try to emulate Microsoft's virus explorer. When I switched platform I went from Mozilla to Firefox and spent a fair amount of time finding out how to disable those unwanted features. Disabling the feature that send all your URL typos to Google was one of the first things I strived to do. When I type http://museum/ I get a "not found " error message. But nslookup museum works. With all the phishing shananigans, you'd think the folks outside of microsoft who would strive to avoid features that could bring you to unwanted destinations and they should just stick to feeding your host name string to the resolver and letting resolver decide how to manipulate that string to resolve it. From christopher.morrow at gmail.com Mon Jun 30 20:08:19 2008 From: christopher.morrow at gmail.com (Christopher Morrow) Date: Mon, 30 Jun 2008 21:08:19 -0400 Subject: ICANN opens up Pandora's Box of new TLDs In-Reply-To: <48697B91.7050603@vaxination.ca> References: <63ac96a50806300036u5c1a9bbdq4efb8e4879650434@mail.gmail.com> <20080630144723.3290.qmail@simone.iecc.com> <63ac96a50806300905s168c3da9m6d636067bafe3c45@mail.gmail.com> <20080630184919.GD8195@cgi.jachomes.com> <48697B91.7050603@vaxination.ca> Message-ID: <75cb24520806301808i70fff185q8cd24e905f4a2ef@mail.gmail.com> On Mon, Jun 30, 2008 at 8:34 PM, Jean-Fran?ois Mezei wrote: > With all the phishing shananigans, you'd think the folks outside of > microsoft who would strive to avoid features that could bring you to > unwanted destinations and they should just stick to feeding your host > name string to the resolver and letting resolver decide how to > manipulate that string to resolve it. You sure would... hurrah for paxfire/barefruit/... :( enabling phishing one typo at a time. -Chris From jgreco at ns.sol.net Mon Jun 30 20:23:21 2008 From: jgreco at ns.sol.net (Joe Greco) Date: Mon, 30 Jun 2008 20:23:21 -0500 (CDT) Subject: what problem are we solving? (was Re: ICANN opens up Pandora'sBox In-Reply-To: from "Peter Beckman" at Jun 30, 2008 03:16:15 PM Message-ID: <200807010123.m611NMUe008556@aurora.sol.net> > On Mon, 30 Jun 2008, Joe Greco wrote: > > I see usefulness in having scopes that are local (city/village/etc), > > state, country, and global. There's no reason that you couldn't start > > out local, and as you grew, get a state level domain (martyspizza.wi.us), > > and if you went national (martyspizza.us), etc. In many (most!) cases, > > businesses do not make significant growth in a rapid fashion. > > The selfish will abuse the lack of RFC1480 management and go straight to > martyspizza.us, even though they have one store, because it's available at > the time. That's probably a reasonable reason to do a modest amount of research on registrants. Of course, the idea that a registrar has any duty other than to take money and "make it so" is heretical, I know. > > Actually, that has to do with what I was talking about in continuing to > > develop a reasonable system. Quite frankly, if I was in that school > > district, I see no reason why my computer couldn't be aware of that > > domain, and actually have "http://john-muir" or some similar mechanism > > actually work. The ideal is probably more complex in implementation, > > but does not need to be more complex in use. > > Does the DNS provider or ISP decide that? Or are you just referring to a > bookmarking feature in your browser? Which then makes moot any RFC1480 > friendly URL. Namespaces in DNS that are globally recognized are > different than your example above. I would actually like to have seen a continued evolution of DNS towards something slightly more useful. Implementation as a bookmark in a browser would not make any sense; the Internet is not just the World Wide Web. The search feature within a resolver is one reasonable starting point for considering how you might go about this sort of thing, but I expect that the solution might not really resemble anything currently existing. > > I would agree that we don't need more TLD's. But the namespace, as it > > exists, is messy, and it's nasty to expect that people will always have > > to use a browser and a search engine to find their destination's domain > > name. > > Nobody can or will cleanup the existing namespaces. New TLDs will > continue to make them more messy. More court battles over new TLDs will > come up. The wealthy will get their own TLDs (I can't afford .beckman, > but I'm sure Beckman Instruments can, who already own beckman.com, and > I'll just be screwed again), and small guys will not. > > Search engines and browser tools will render the value of domain names > to approaching zero, .com will remain the namespace of choice, and that > new TLDs will be for the wealthy i.e. http://google/ and http://coke/ and > there will be more court battles for those trademarks. It may go that way, but should we let it do so without comment? ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From jgreco at ns.sol.net Mon Jun 30 20:40:15 2008 From: jgreco at ns.sol.net (Joe Greco) Date: Mon, 30 Jun 2008 20:40:15 -0500 (CDT) Subject: what problem are we solving? (was Re: ICANN opens up Pandora's In-Reply-To: <20080630212216.GJ8195@cgi.jachomes.com> from "Jay R. Ashworth" at Jun 30, 2008 05:22:16 PM Message-ID: <200807010140.m611eFic008996@aurora.sol.net> > On Sat, Jun 28, 2008 at 08:46:33AM -0500, Joe Greco wrote: > > Yes. It completely marginalizes the remaining positive qualities of the > > Domain Name System as a way to find things, in the name of giving people > > "more options." > > The Domain Name System is not now, and never has been, away to *find* > things, anymore than 123 Elm St, Worcester MA is a way to *find* a > house. > > It's a way to *denote* things, uniquely. > > You *find* an address by looking in a map directory, and then on the > map. You find things on the Internet using a search engine, and the > second-order derivatives. It seems clear that the authors of 1480 did not agree with this. This may have been because there were no "search engines", as we know them today, at that time. > > Let me start by saying that I believe that the trends in the DNS have been > > going the wrong way for well over a decade. The insistence on the part of > > many that the namespace be flattened is just a poor choice. People are now > > used to trying ".com" to reach a company. In some cases, this makes > > fair sense; I can see why "ibm.com" or "seagate.com" are that way, even > > though in some cases there are namespace collisions with other trademarks. > > "Famous trademarks". > > > In others, it's ridiculous - why the heck do I get someplace in California > > when I go to "martyspizza.com", rather than our local very excellent pizza > > place? (sadly this example is less effective now, they managed to get > > "martyspizza.net" a few years back). > > Sure. Local collisions are inevitable. Blocker Transfer, a local > moving company client of mine, wanted to register a domain back in > 1997... when the company was 99 years old. blocker.com was taken. > > They took blocker100.com, and promoted it. That doesn't seem to be a "local collision," except insofar as the Internet can be collectively considered "local." In any case, company's solution is only useful if you already know the domain name (or have a way to find it). > > We never had any business allowing small, local businesses to register in > > .com, or non-networking companies to register in .net, or non-organizations > > in .org... but a whole generation of Internet "professionals" "knew better" > > and the end result at the end of the road is that DNS will end up being > > almost as useless as IPv4 numbers for identifying the more obscure bits of > > the Internet. > > Correct; this is exactly the problem. But a lot of it stems, Joe, from > the misconception you led with. Not a misconception. Simply a different view of how the system could have evolved, had it followed the lead of RFC1480, instead of having everyone and their brother load on in to .com... It could be said that search engines doomed any hope of trying to make the DNS sensible. > > It would have been much better for us to fix some of the obvious problems > > with DNS back in the day. Instead, we didn't bother, and instead allowed > > "market forces" to dictate what happened next. This of course got buyers > > whatever they wanted (which was generally "short names!"), but what buyers > > wanted didn't necessarily map well into what would have made sense for > > /users/ of the system, which would have been "predictability of names." > > See all the debates about area code overlays vs splits, and the > extension of US telephone Directory Numbers to 12 digits. Sure. I'm familiar. > > We are now reaping the evolution of that into even further mayhem. > > Yep. > > > I look forward to many more years of having to remember that Marty's > > Pizza is "martyspizza.net" instead of "martyspizza.brookfield.wi.us", > > that Milwaukee's Department of Public Works is at "mpw.net" instead of > > "dpw.ci.milwaukee.wi.us", etc. > > I am, in turn, very pleased with a lot of my local municipalities. > > Some of them, admittedly, *have* silly pinellascounty.org or > pinellas-park.com names, but they also answer to the long-form .fl.us > names you would prefer. Sometimes they redirect one way, sometimes the > other; sometimes each domain merely overlays the other. That's fine, I have been wishing for DNAME support for years. Locally, in the pre-1480 days, we were "mil.wi.us", then became "milwaukee.wi.us", but only through the magic of duplicating everything between the zones, and in the more recent "delegate elsewhere" model, that means that some registrants invariably only configure one or the other, so "foo.mil.wi.us" works while "foo.milwaukee.wi.us" doesn't... > But at least they are, as you say, deterministic. > > I don't think it's fixable anymore, either. But I remain determined to > spit into the wind, Jim notwithstanding. :-) ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From jfmezei at vaxination.ca Mon Jun 30 23:02:33 2008 From: jfmezei at vaxination.ca (=?ISO-8859-1?Q?Jean-Fran=E7ois_Mezei?=) Date: Tue, 01 Jul 2008 00:02:33 -0400 Subject: ICANN opens up Pandora's Box of new TLDs In-Reply-To: <20080630175137.BD65E66B@resin17.mta.everyone.net> References: <20080630175137.BD65E66B@resin17.mta.everyone.net> Message-ID: <4869AC59.9020302@vaxination.ca> Scott Weeks wrote: > How'd you do that? I use FF on FreeBSD, but parhaps there're similar settings. Since a few people asked. in the url line: about:config This is the magic incantation that gets you a page with just about all configuration settings. you can serach for a particular setting in the "filter". To disable the google searching, look for the string "keyword". set keyword.enabled to "false". You can alco zap the value of keyword.URL To get a button to easily enable and disable javascript: http://prefbar.mozdev.org/ This allows you to put up a whole series of buttons such as java, images, javascript, kill cache, and a "UA" selection box to fake other browsers and much more. Another extension is the Web Develoer extension: http://chrispederick.com/work/web-developer/ It gives you plenty of options, including disabling CSS, viewing source etc etc. Good support available in the mozilla.support.* newsgroups (such as mozilla.support.firefox). If you are on an ISP that have cut down NNTP, it is available on the NNTP server: news.mozilla.org From hannigan at verneglobal.com Mon Jun 30 23:01:34 2008 From: hannigan at verneglobal.com (Martin Hannigan) Date: Tue, 1 Jul 2008 04:01:34 -0000 Subject: DNS and potential energy References: <200806290231.m5T2VXob020706@aurora.sol.net><393FF04B-6BDC-41CE-BCF3-97FC6D0226A2@ca.afilias.info><20080629235958.GA16853@vacation.karoshi.com.> Message-ID: > Doesn't ICANN already work like an international regulator? No. They are more like the IETF than the ITU, but not quite the IETF. It's hard to describe. The origins are Berkman Center for Internet and Soceity at Harvard, and what is in existence today is a far cry from the original social desire of folks that are still there today who, based on my knowledge and perception, have been mostly disenfranchised. But not quite a regulator. -M< From smb at cs.columbia.edu Mon Jun 30 23:13:09 2008 From: smb at cs.columbia.edu (Steven M. Bellovin) Date: Tue, 1 Jul 2008 00:13:09 -0400 Subject: ICANN opens up Pandora's Box of new TLDs In-Reply-To: <4869AC59.9020302@vaxination.ca> References: <20080630175137.BD65E66B@resin17.mta.everyone.net> <4869AC59.9020302@vaxination.ca> Message-ID: <20080701001309.3ba4a9d5@cs.columbia.edu> On Tue, 01 Jul 2008 00:02:33 -0400 Jean-Fran?ois Mezei wrote: > > To get a button to easily enable and disable javascript: > > http://prefbar.mozdev.org/ > While I do use prefbar, for dealing with Javascript I much prefer NoScript, since that gives me per-site control. --Steve Bellovin, http://www.cs.columbia.edu/~smb