February 2003 - Test - lists.nanog.org

RE: IPv6 Peering Request
by Irwin Lazar 16 Feb '03

16 Feb '03

I have a collection of links to info about IPv6 at: www.itprc.com/tcp_ip.htm http://www.ipv6forum.org/ is probably the best starting place. irwin > -----Original Message----- > From: Scott Granados [mailto:scott@wworks.net] > Sent: Sunday, February 16, 2003 4:38 PM > To: Mike Leber; Nicolas DEFFAYET > Cc: Jeffrey Wheat; nanog(a)merit.edu > Subject: Re: IPv6 Peering Request > > > > Can someone give me a good pointer as to places to start > learning more about > ipv6? > > > ----- Original Message ----- > From: "Mike Leber" <mleber(a)he.net> > To: "Nicolas DEFFAYET" <nicolas.deffayet(a)ndsoftware.net> > Cc: "Jeffrey Wheat" <jeff(a)cetlink.net>; <nanog(a)merit.edu> > Sent: Saturday, February 15, 2003 2:47 PM > Subject: Re: IPv6 Peering Request > > > > > > > > All the IPv6 routers in our network are cisco. > > > > We host about 1500 IPv6 over IPv4 tunnels via our tunnel broker. > > > > Many of the tunnel broker users are running cisco routers. > > > > Yes I was going too fast and missed his comment (it didn't parse) > > otherwise I would have pointed out that if he is running a > cisco with an > > IOS that supports IPv6 he can run IPv6 in tunnels over IPv4. > > > > For example: > > > > interface Tunnel1 > > description An IPv6 tunnel peer > > no ip address > > ipv6 address <IPv6-address-for-your-side>/127 > > ipv6 enable > > tunnel source <IPv4-address-on-your-router> > > tunnel destination <IPv4-address-on-peer's-router> > > tunnel mode ipv6ip > > > > Mike. > > > > On 15 Feb 2003, Nicolas DEFFAYET wrote: > > > > > On Sat, 2003-02-15 at 02:39, Mike Leber wrote: > > > > We operate a free IPv6 tunnel broker at http://tunnelbroker.com > > > > > > Jeffrey Wheat said: "so brokers are no an option for us". > > > > > > > On Fri, 14 Feb 2003, Jeffrey Wheat wrote: > > > > > > > > > > > > > > Is there anyone that would be interested in providing a tunnel > > > > > to the 6bone for us? We are in Charlotte, NC and would prefer > > > > > to establish a tunnel with someone close by. We'd be > doing this > > > > > via a cisco router so brokers are no an option for us. We are > > > > > AS8175. > > > > > > -- > > > Nicolas DEFFAYET, NDSoftware > > > NDSoftware NOC: http://noc.ndsoftwarenet.com/ > > > FNIX6: http://www.fnix6.net/ > > > EuroNOG: http://www.euronog.org/ > > > > > > > +----------------- H U R R I C A N E - E L E C T R I C > -----------------+ > > | Mike Leber Direct Internet Connections Voice > 510 580 4100 | > > | Hurricane Electric Web Hosting Colocation Fax > 510 580 4151 | > > | mleber(a)he.net > http://www.he.net | > > > +------------------------------------------------------------- > ----------+ > > > > > > > >

1 0

"Selfish Routing"
by Pete Kruckenberg 15 Feb '03

15 Feb '03

http://www.scienceblog.com/community/article1018.html --- "The Internet is 'fault-tolerant,' so there are always many routes a message can take. A packet of data traveling from New York to San Francisco might go by way of Chicago or Dallas, or might even hop from New York to Columbus to Miami to Omaha to Denver to San Francisco. "Routers have many ways to decide. Sometimes they send out test packets and time them. Sometimes routers exchange information about the condition of the network in their vicinities. But if routers choose the route that looks the least congested, they are doing selfish routing. As soon as that route clogs up, the routers change their strategies and choose other, previously neglected routes. "Roughgarden has a suggestion that wouldn't be expensive to implement. Before deciding which way to send information, he says, routers should consider not only which route seems the least congested, but also should take into account the effect that adding its own new messages will have on the route it has chosen. That would be, he says, 'just a bit altruistic' in that some routers would end up choosing routes that were not necessarily the fastest, but the average time for all users would decrease." --- This might be easier to understand if it was more technical, but I'm only aware of a lot of disabled features on my routers that are supposed to in theory do some of these things. Abstractions and analogies aside, is this really a problem, and is it really worth solving? Sounds like a lot of additional complexity for the supposed benefits. Pete.

8 10

lft traceroute
by Rodney Joffe 15 Feb '03

15 Feb '03

I have been asked by some folks for the link to the lft traceroute I used this morning in my presentation. It is available at http://www.mainnerve.com/lft/ -- Rodney Joffe CenterGate Research Group, LLC. http://www.centergate.com "Technology so advanced, even we don't understand it!"(R)

3 2

Multicast / UUnet
by Ejay Hire 14 Feb '03

14 Feb '03

Anyone clueful about multicast at UUnet on-list? I'm getting the telephone equivalent of blank stares when I call in. I'm trying to find out if multicast services are offered and how much $ We already have a ds-3 w/ uu. Thanks, Ejay

2 1

Thanks
by Jeffrey Wheat 14 Feb '03

14 Feb '03

I'd like to thank everyone that emailed me information about IPv6 calculators. It was much appreciated! Regards, Jeff --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com) Version: 6.0.449 / Virus Database: 251 - Release Date: 1/27/2003

1 0

The Cidr Report
by cidr-report＠potaroo.net 14 Feb '03

14 Feb '03

This report has been generated at Fri Feb 14 00:46:03 2003 AEST. The report analyses the BGP Routing Table of an AS4637 (Reach) router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org/as4637 for a current version of this report. Recent Table History Date Prefixes CIDR Agg 07-02-03 118526 85124 08-02-03 118568 85173 09-02-03 118579 85149 10-02-03 118627 85137 11-02-03 118637 85198 12-02-03 118760 85310 13-02-03 118989 85108 14-02-03 119071 85326 AS Summary 14555 Number of ASes in routing system 5721 Number of ASes announcing only one prefix 1571 Largest number of prefixes announced by an AS AS701 : ALTERNET-AS UUNET Technologies, Inc. 73048064 Largest address span announced by an AS (/32s) AS568 : SUMNET-AS DISO-UNRRA 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'). --- 14Feb03 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 119071 85433 33638 28.3% All ASes AS3908 1056 565 491 46.5% SUPERNETASBLK SuperNet, Inc. AS18566 474 7 467 98.5% COVAD Covad Communications AS4151 523 102 421 80.5% USDA-1 USDA AS701 1571 1161 410 26.1% ALTERNET-AS UUNET Technologies, Inc. AS7018 1425 1033 392 27.5% ATT-INTERNET4 AT&T WorldNet Services AS4323 528 169 359 68.0% TW-COMM Time Warner Communications, Inc. AS7843 569 240 329 57.8% ADELPHIA-AS Adelphia Corp. AS6197 476 157 319 67.0% BATI-ATL BellSouth Network Solutions, Inc AS1221 1130 824 306 27.1% ASN-TELSTRA Telstra Pty Ltd AS7046 566 274 292 51.6% UUNET-CUSTOMER UUNET Technologies, Inc. AS4355 405 119 286 70.6% ERMS-EARTHLNK EARTHLINK, INC AS1239 958 674 284 29.6% SPRINTLINK Sprint AS6347 368 85 283 76.9% DIAMOND SAVVIS Communications Corporation AS22927 295 14 281 95.3% AR-TEAR2-LACNIC TELEFONICA DE ARGENTINA AS705 446 196 250 56.1% ASN-ALTERNET UUNET Technologies, Inc. AS4814 261 15 246 94.3% CHINANET-BEIJING-AP China Telecom (Group) AS1 663 435 228 34.4% GNTY-1 Genuity AS6198 434 220 214 49.3% BATI-MIA BellSouth Network Solutions, Inc AS22291 242 32 210 86.8% CHARTER-LA Charter Communications AS17676 224 24 200 89.3% GIGAINFRA XTAGE CORPORATION AS690 498 308 190 38.2% MERIT-AS-27 Merit Network Inc. AS4134 306 119 187 61.1% ERX-CHINALINK Data Communications Bureau AS209 523 337 186 35.6% ASN-QWEST Qwest AS2386 439 259 180 41.0% INS-AS AT&T Data Communications Services AS2048 260 87 173 66.5% LANET-1 State of Louisiana AS852 606 446 160 26.4% ASN852 Telus Advanced Communications AS17557 339 188 151 44.5% PKTELECOM-AS-AP Pakistan Telecom AS22773 177 27 150 84.7% CCINET-2 Cox Communications Inc. Atlanta AS6140 285 136 149 52.3% IMPSAT-USA ImpSat AS6327 186 40 146 78.5% SHAWFIBER Shaw Fiberlink Limited Total 16233 8293 7940 48.9% Top 30 total Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog(a)merit.edu eof-list(a)ripe.net apops(a)lists.apnic.net routing-wg(a)ripe.net afnog(a)afnog.org

1 0

[dmoore@caida.org: Re: Symantec detected Slammer worm "hours" before]
by k claffy 14 Feb '03

14 Feb '03

[david not on nanog list so am forwarding for him] ----- Forwarded message from David Moore <dmoore(a)caida.org> ----- Date: Thu, 13 Feb 2003 10:42:18 -0800 From: David Moore <dmoore(a)caida.org> Subject: Re: Symantec detected Slammer worm "hours" before To: k claffy <kc(a)caida.org> Cc: Sean Donelan <sean(a)donelan.com>, nanog(a)merit.edu, David Moore <dmoore(a)caida.org> > On Thu, Feb 13, 2003 at 11:59:48AM -0500, Sean Donelan wrote: > Wow, Symantec is making an amazing claim. They were able to detect > the slammer worm "hours" before. Did anyone receive early alerts from > Symantec about the SQL slammer worm hours earlier? Academics have > estimated the worm spread world-wide, and reached its maximum scanning > rate in less than 10 minutes. So actually thinking about this a bit more, our numbers count from when single well connected or a set of less well connected hosts are infected. If a single (or small number) of infected machines were on slow links (dsl/cable modem/etc) it might take them up to about an hour to find the next vulnerable host (also depending on luck and which cycle of the RNG they are in). So there might be a longer startup period than we suggested if the worm was launched in a poor environment. However, at those rates, the scanning by the worm (small number of hosts with tiny total bandwidth) would be well below the noise of even "normal" port scanning activity. I find it difficult to believe that that _at the time_ it would have been flagged as suspicious. Perhaps going back through their logs after the growth was over would have yielded something. If it was running at a rate which on average took it an hour to find the next vulnerable host, then if they had effective monitoring of a /8, then they would have only seen 100-300 packets in that hour (fewer the more vulnerable hosts that were out there; slower scanning to not find one in an hour). It's a little hard for me to believe that symantec would have noticed this level of traffic, figured out that it was bad (although perhaps some simple x86 code detector might have helped) and have told people about it at this rate. In any case, if they did, then it's because the worm was launched from a poor bandwidth environment, presumably something that symantec can't control in the future. -- david ----- End forwarded message -----

2 1

APNIC new block of addresses
by John Tran 14 Feb '03

14 Feb '03

Dear colleagues APNIC received IPv4 address blocks 222/8 and 223/8 from IANA in February 2003 and will be making allocations from these ranges in the near future. This announcement is being made for the information of the Internet community so that network configurations such as routing filters may be updated as appropriate. For more information on the resources administered by APNIC, see: http://www.apnic.net/db/ranges.html For information on the minimum allocation sizes within address ranges administered by APNIC, see: http://www.apnic.net/db/min-alloc.html Kind regards Son ____________________________________________________________________ Resources Services Manager <Son(a)apnic.net> Asia Pacific Network Information Centre phone: +61 7 3858 3100 http://www.apnic.net fax: +61 7 3858 3199 Helpdesk phone: +61 7 3858 3188 email: helpdesk(a)apnic.net Please send Internet Resource Requests to <hostmaster(a)apnic.net> _____________________________________________________________________

1 0

FYI New IPv4 allocation ot APNIC
by John L Crain 13 Feb '03

13 Feb '03

Hello all, This is to let you know that the IANA has allocated 222/8 and 223/8 to APNIC for further distribution. A notation of the allocation has been made at <http://www.iana.org/assignments/ipv4-address-space>. If you are filtering these ranges you need to be aware that they will be bought into use and you may wish to adjust those filters. John Crain ============ Technical Operations Manager IANA/ICANN

3 2

BGP/OSPF configurations
by Patrick Felt 13 Feb '03

13 Feb '03

This is a little off the topic, but it still applies. As such, feel free to respond to me personally on this. I am working on some research for one of my university classes on TCP/IP. Later in the semester we will be discussing OSPF and BGP4. I am editing my teachers notes on the subject because I have more experience with them practically than does he. I have only run them in my own organization/configuration, and because of that, my knowledge is a little limited. I would very much like to know different configurations that are currently being used with both of these protocols, so that I might be able to add valuable "industry tested" information to his lecture notes. (Zebra, gated, cisco, nortel.... etc. info welcome). If any of you are using either of these protocols, and would not mind sending me information on it, I would be very thankful. Info that I am looking for... BGP: Use of loopback interfaces Confederations eBGP vs iBGP Reflectors # of upstream peers (non local-as peers) OSPF: Area configuration Virtual Links # of ABR # of ASBR stuff like that.. Thanks again for any help that can be given. I, my fellow students, and my teacher thank you. Patrick Felt pfelt(a)quintam.com Sr. Software Eng./Network Eng. Quintam Corporation (Senior at Utah Valley State College, Orem Utah)

1 0