- NANOG - lists.nanog.org

zone transfers
by bmanning＠ISI.EDU 05 Nov '97

05 Nov '97

I am running an audit of the in-addr zone to determin the extent of defective delegations. If your systems have delegations for zones under in-addr.arpa, they will be probed during the course of the audit. It is expected that the audit will complete within the next 8-10 days, if there are no interuptions. --bill

2 2

Re: moving to IPv6
by Sean M. Doran 05 Nov '97

05 Nov '97

I apologize that the quality of this message will be somewhat limited by pressures of time and having to use a really weird Microsoft keyboard that leaves me prone to speeling mistakes, but I couldn't resist some of the things being talked about in this thread. Phil Howard <phil(a)charon.milepost.com> writes: > The transition to IPv6 is clearly going to have some difficulties. We are > waiting on: > > 1. Network equipment, with translation > translation > have to have translations > routing software includes translation Bingo! The thing that amazes me about people who are fans of IPv6 is that they have realized that NAT is THE fundamental scaling technology for the Internet. Translation of addresses, whether it is between IPv4 and IPv4 or involves protocol translations as well (as is the case in IPv4->IPv6->IPv4, or IPv6->IPv4->IPv6), is simply the most practical and effective way of overcoming the two principal scaling problems of the Internet, namely the narrowness of the IPv4 address and the fact that deployed routing protocols simply suck. Observe that so long as a translatable subset of transport layer options are used, there is absolutely no difference between NAT between IPv4 addresses and protocol translation between IPv4 and IPv6. Moreover, in the latter case, you are not restricted to IPv6s4 (who comes up with these acronyms anyway? Does anyone mind if I call IPv4 IP? If you do, well, tough.) The technical goal is that end to end services will work, period, in all cases. This is possible provided that the higher order protocols do not make invalid assumptions about the transport layer. Most importantly, just as CIDR requires that protocol implementations respect that IP addresses may change over time, NAT as THE new fundamental scaling technology requires that protocol implementations respect that IP addresses may change over space as well. That is, so long as protocols do not assume that an IP address is the same from the point of view of all locations throughout the concatenated Internet, they will do just fine with either NAT or protocol translation or both. Returning to the observation that NAT and protocol translation are semantically equivalent from an end-to-end perspective, we now need to consider whether simple address translation or protocol translation is a better idea. > But just having [network routing software] translating IPv4 <-> IPv6s4 is not enough. > We will need to manage the new IPv6 network. Deployed base is a strong engineering consderation in an industry which is experiencing enormous growth. NAT has the advantage that reasonably designed existing technologies ought not even notice that NAT is happening. Protocol translation, on the other hand, requires, as you say, new management techniques, which will generally involve lots of learning time on the part of lots of engineers and operators, wherever the new protocol is deployed. The fact is, that there may be a reason to deploy a new protocol that makes this worthwhile, however, you should also note that so long as a translation between transport layers is straightforward, there is no reason why the new protocol needs to be IPv6. In fact, I welcome IPv6's fan base working on protocol translation because there are also some more interesting experimental protocols which could be deployed in precisely the same fashion that do not suffer some of the brokenesses of IPv6. Most notably: > Routing issues will become different in IPv6. This is simply untrue. Routing issues are EXACTLY the same in IP and IPv6, the only difference is the width of the addresses, which worsens the poor scaling properties of IP with current routing protocols. The only attractive (and this is very very very speculative) aspect of the IPv6 address scheme is that it may be wide enough to experiment with something like using a modified IS-IS that works on multiple hierarchical areas encoded as fields in the IPv6 address, with the thought of using that to supplant current interdomain routing protocols. I'm sure this thought will go over well with the IPv6 crowd... > If IPv6 allocations will have varying sizes like CIDR, then we might > continue to have issues of size based route filtering. Please understand that the size-based filtering is done to limit the number of prefixes carried, and that this is completely independent of IP vs IPv6. If the number of prefixes must be kept to some maximum by filtering at, say, the 19 bit mark, the same maximum will be maintained even if the address space is much wider, and the straightforward way of doing that is to retain filters at the 19 bit mark. > OTOH, with the > right methods of allocating IPv6 space, no one should ever have to come > back to get more space. Eventually that should mean fewer routes as > IPv4/IPv6s4 closes down. Route filtering should be encouraged on IPv4 > space and prohibited on IPv6 space, at that point, IMHO. Could you pleace elaborate? I am completely lost by your logic here. Sean.

13 20

fwd: RealPlayer 5.0/Linux (from RedHat-Announce)
by Jay R. Ashworth 05 Nov '97

05 Nov '97

Pertinent to a conversation played out here just before NANOG. -----Forwarded message from Steven Krikstone <triden(a)scooby.cheney.net>----- From: Steven Krikstone <triden(a)scooby.cheney.net> To: redhat-announce-list(a)redhat.com Subject: RealPlayer 5.0 Beta Message-ID: <Pine.LNX.3.95.971104170549.17532A-100000(a)scooby.cheney.net> Just to let everyone know, RealAudio has released RealPlayer 5.0 Beta 1 for Linux. I've been using it for a few days and haven't come across any glaring bugs. The major difference between 3.0 and 5.0 is that streaming video can be displayed. Even more important than that, you don't have to start netscape with a private colormap; a much needed addition. The gzip'ed tar file is easy to install, and you need only to complete a few steps to get it working on RH. (I'd make a .rpm, but I think the license I read forbids it, someone let me know if I'm wrong) NOTE: Read the README.FIRST that is contained in the tarball. It contains important steps needed to correctly setup RealPlayer. The program can be found at: http://www.real.com/products/player/download_player.html --- Steven Krikstone Cheney Communications -----End of forwarded message----- HTH. Cheers, -- jra -- Jay R. Ashworth jra(a)baylink.com Member of the Technical Staff Unsolicited Commercial Emailers Sued The Suncoast Freenet "Pedantry. It's not just a job, it's an Tampa Bay, Florida adventure." -- someone on AFU +1 813 790 7592

1 0

tcsender email bombing
by Dennis Simpson 05 Nov '97

05 Nov '97

Having seen fairly heavy loading on our mail server today, I decided to see what might be going on. Is anyone else seeing concerted bombing from tcsender@<a couple of addresses> where the relayhost covers many hosts? I have attached a tiny bit of today's mail syslog contents below to illustrate. Approximately one third of our email traffic today has come from this. I am going to be blocking a number of the ip's at our router, due to the heavy load this is causing us. Is anyone else having to handle this nonsense (tcsender specifically) or should I be looking for someone attacking us? Thx, dennis Nov 4 04:05:48 bconnex.net sendmail[4697]: Ruleset check_mail (<tcsender(a)get-more-hits.com>) rejection: 451 <tcsender(a)get-more-hits.com>... Domain must resolve Nov 4 04:05:48 bconnex.net sendmail[4697]: EAA04697: from=<tcsender(a)get-more-hits.com>, size=0, class=0, pri=0, nrcpts=0, proto=ESMTP, relay=root(a)astra.genghis.com [205.139.15.34] Nov 4 04:05:54 bconnex.net sendmail[4698]: Ruleset check_mail (<tcsender(a)get-more-hits.com>) rejection: 451 <tcsender(a)get-more-hits.com>... Domain must resolve Nov 4 04:05:54 bconnex.net sendmail[4698]: EAA04698: from=<tcsender(a)get-more-hits.com>, size=0, class=0, pri=0, nrcpts=0, proto=SMTP, relay=root(a)busche.com [206.83.162.16] Nov 4 04:05:57 bconnex.net sendmail[4703]: Ruleset check_mail (<tcsender(a)get-more-hits.com>) rejection: 451 <tcsender(a)get-more-hits.com>... Domain must resolve Nov 4 04:05:57 bconnex.net sendmail[4703]: EAA04703: from=<tcsender(a)get-more-hits.com>, size=0, class=0, pri=0, nrcpts=0, proto=SMTP, relay=root(a)www.fredrick.com [209.113.166.92] Nov 4 04:06:04 bconnex.net sendmail[4705]: Ruleset check_mail (<tcsender(a)need-hits.com>) rejection: 451 <tcsender(a)need-hits.com>... Domain must resolve Nov 4 04:06:04 bconnex.net sendmail[4705]: EAA04705: from=<tcsender(a)need-hits.com>, size=0, class=0, pri=0, nrcpts=0, proto=ESMTP, relay=bay.wiznet.ca [207.139.40.1] Nov 4 04:06:08 bconnex.net sendmail[4712]: Ruleset check_mail (<tcsender(a)get-more-hits.com>) rejection: 451 <tcsender(a)get-more-hits.com>... Domain must resolve Nov 4 04:06:08 bconnex.net sendmail[4712]: EAA04712: from=<tcsender(a)get-more-hits.com>, size=0, class=0, pri=0, nrcpts=0, proto=ESMTP, relay=root(a)[204.254.231.160] Nov 4 04:06:22 bconnex.net sendmail[4723]: Ruleset check_mail (<tcsender(a)get-more-hits.com>) rejection: 451 <tcsender(a)get-more-hits.com>... Domain must resolve Nov 4 04:06:22 bconnex.net sendmail[4723]: EAA04723: from=<tcsender(a)get-more-hits.com>, size=0, class=0, pri=0, nrcpts=0, proto=ESMTP, relay=root(a)linked.net [209.24.1.201] Nov 4 04:06:27 bconnex.net sendmail[4731]: Ruleset check_mail (<tcsender(a)need-hits.com>) rejection: 451 <tcsender(a)need-hits.com>... Domain must resolve Nov 4 04:06:27 bconnex.net sendmail[4731]: EAA04731: from=<tcsender(a)need-hits.com>, size=0, class=0, pri=0, nrcpts=0, proto=ESMTP, relay=emke.com [204.152.178.10] Nov 4 04:06:43 bconnex.net sendmail[4758]: Ruleset check_mail (<tcsender(a)get-more-hits.com>) rejection: 451 <tcsender(a)get-more-hits.com>... Domain must resolve Nov 4 04:06:43 bconnex.net sendmail[4758]: EAA04758: from=<tcsender(a)get-more-hits.com>, size=0, class=0, pri=0, nrcpts=0, proto=ESMTP, relay=adzone.com [205.147.5.1] Nov 4 04:06:50 bconnex.net sendmail[4776]: Ruleset check_mail (<tcsender(a)get-more-hits.com>) rejection: 451 <tcsender(a)get-more-hits.com>... Domain must resolve Nov 4 04:06:50 bconnex.net sendmail[4776]: EAA04776: from=<tcsender(a)get-more-hits.com>, size=0, class=0, pri=0, nrcpts=0, proto=ESMTP, relay=[209.63.20.193] Nov 4 04:07:12 bconnex.net sendmail[4800]: Ruleset check_mail (<tcsender(a)need-hits.com>) rejection: 451 <tcsender(a)need-hits.com>... Domain must resolve Nov 4 04:07:12 bconnex.net sendmail[4800]: EAA04800: from=<tcsender(a)need-hits.com>, size=0, class=0, pri=0, nrcpts=0, proto=SMTP, relay=mercury.webserve.net [206.96.226.5] Nov 4 04:07:13 bconnex.net sendmail[4802]: Ruleset check_mail (<tcsender(a)need-hits.com>) rejection: 451 <tcsender(a)need-hits.com>... Domain must resolve Nov 4 04:07:13 bconnex.net sendmail[4802]: EAA04802: from=<tcsender(a)need-hits.com>, size=0, class=0, pri=0, nrcpts=0, proto=ESMTP, relay=root(a)server3.homecom.com [204.198.149.6] Nov 4 04:07:16 bconnex.net sendmail[4804]: Ruleset check_mail (<tcsender(a)get-more-hits.com>) rejection: 451 <tcsender(a)get-more-hits.com>... Domain must resolve Nov 4 04:07:16 bconnex.net sendmail[4804]: EAA04804: from=<tcsender(a)get-more-hits.com>, e=0, class=0, pri=0, nrcpts=0, proto=ESMTP, relay=metallus.ias.net [206.214.209.8] Nov 4 04:07:23 bconnex.net sendmail[4808]: Ruleset check_mail ) rejection: 451 <tcsender(a)get-more-hits.com>... Domain must resolve Nov 4 04:07:23 bconnex.net sendmail[4808]: EAA04808: from=<tcsender(a)get-more-hits.com>, e=0, class=0, pri=0, nrcpts=0, proto=ESMTP, relay=france-travel.com [192.41.4.181] Nov 4 04:08:04 bconnex.net sendmail[4852]: Ruleset check_mail ) rejection: 451 <tcsender(a)get-more-hits.com>... Domain must resolve Nov 4 04:08:04 bconnex.net sendmail[4852]: EAA04852: from=<tcsender(a)get-more-hits.com>, e=0, class=0, pri=0, nrcpts=0, proto=SMTP, relay=fox.plaza.nl [195.108.180.1] Nov 4 04:08:05 bconnex.net sendmail[4858]: Ruleset check_mail ) rejection: 451 <tcsender(a)get-more-hits.com>... Domain must resolve Nov 4 04:08:05 bconnex.net sendmail[4858]: EAA04858: from=<tcsender(a)get-more-hits.com>, e=0, class=0, pri=0, nrcpts=0, proto=ESMTP, relay=dnai.com [140.174.162.28] Nov 4 04:08:17 bconnex.net sendmail[4865]: Ruleset check_mail (<tcsender(a)need-hits.com>) jection: 451 <tcsender(a)need-hits.com>... Domain must resolve Nov 4 04:08:17 bconnex.net sendmail[4865]: EAA04865: from=<tcsender(a)need-hits.com>, class=0, pri=0, nrcpts=0, proto=ESMTP, relay=virtual.icanect.net [208.202.14.126] Nov 4 04:08:45 bconnex.net sendmail[4881]: Ruleset check_mail ) rejection: 451 <tcsender(a)get-more-hits.com>... Domain must resolve Nov 4 04:08:45 bconnex.net sendmail[4881]: EAA04881: from=<tcsender(a)get-more-hits.com>, e=0, class=0, pri=0, nrcpts=0, proto=SMTP, relay=100t.lauderdale.net [207.141.140.10] Nov 4 04:09:09 bconnex.net sendmail[4895]: Ruleset check_mail ) rejection: 451 <tcsender(a)get-more-hits.com>... Domain must resolve Nov 4 04:09:09 bconnex.net sendmail[4895]: EAA04895: from=<tcsender(a)get-more-hits.com>, e=0, class=0, pri=0, nrcpts=0, proto=ESMTP, relay=fred.ic2do.com [38.218.186.11] Nov 4 04:09:14 bconnex.net sendmail[4902]: Ruleset check_mail (<tcsender(a)need-hits.com>) jection: 451 <tcsender(a)need-hits.com>... Domain must resolve Nov 4 04:09:14 bconnex.net sendmail[4902]: EAA04902: from=<tcsender(a)need-hits.com>, class=0, pri=0, nrcpts=0, proto=ESMTP, relay=ch.promega.com [198.150.28.10] Nov 4 04:09:15 bconnex.net sendmail[4905]: Ruleset check_mail (<tcsender(a)need-hits.com>) jection: 451 <tcsender(a)need-hits.com>... Domain must resolve Nov 4 04:09:15 bconnex.net sendmail[4905]: EAA04905: from=<tcsender(a)need-hits.com>, class=0, pri=0, nrcpts=0, proto=ESMTP, relay=root(a)ns.falconsoft.com [206.112.39.112] Nov 4 04:09:28 bconnex.net sendmail[4916]: Ruleset check_mail ) rejection: 451 <tcsender(a)get-more-hits.com>... Domain must resolve Nov 4 04:09:28 bconnex.net sendmail[4916]: EAA04916: from=<tcsender(a)get-more-hits.com>, e=0, class=0, pri=0, nrcpts=0, proto=ESMTP, relay=root(a)web12.ntx.net [209.1.144.158] Nov 4 04:09:45 bconnex.net sendmail[4928]: Ruleset check_mail ) rejection: 451 <tcsender(a)get-more-hits.com>... Domain must resolve Nov 4 04:09:45 bconnex.net sendmail[4928]: EAA04928: from=<tcsender(a)get-more-hits.com>, e=0, class=0, pri=0, nrcpts=0, proto=ESMTP, relay=root(a)realbeer.com [204.152.97.15] Nov 4 04:09:45 bconnex.net sendmail[4929]: Ruleset check_mail ) rejection: 451 <tcsender(a)get-more-hits.com>... Domain must resolve Nov 4 04:09:45 bconnex.net sendmail[4929]: EAA04929: from=<tcsender(a)get-more-hits.com>, e=0, class=0, pri=0, nrcpts=0, proto=ESMTP, relay=gost3.indirect.com [165.247.198.3] Nov 4 04:09:46 bconnex.net sendmail[4930]: Ruleset check_mail ) rejection: 451 <tcsender(a)get-more-hits.com>... Domain must resolve Nov 4 04:09:46 bconnex.net sendmail[4930]: EAA04930: from=<tcsender(a)get-more-hits.com>, e=0, class=0, pri=0, nrcpts=0, proto=ESMTP, relay=[205.217.137.150] Nov 4 04:09:54 bconnex.net sendmail[4936]: Ruleset check_mail (<tcsender(a)need-hits.com>) jection: 451 <tcsender(a)need-hits.com>... Domain must resolve Nov 4 04:09:54 bconnex.net sendmail[4936]: EAA04936: from=<tcsender(a)need-hits.com>, class=0, pri=0, nrcpts=0, proto=ESMTP, relay=root(a)jab1.roc.servtech.com [204.181.4.152] Nov 4 04:10:31 bconnex.net sendmail[4956]: Ruleset check_mail (<tcsender(a)need-hits.com>) jection: 451 <tcsender(a)need-hits.com>... Domain must resolve Nov 4 04:10:31 bconnex.net sendmail[4956]: EAA04956: from=<tcsender(a)need-hits.com>, class=0, pri=0, nrcpts=0, proto=ESMTP, relay=wcc.wcc.net [208.6.232.10] Nov 4 04:10:45 bconnex.net sendmail[4972]: Ruleset check_mail ) rejection: 451 <tcsender(a)get-more-hits.com>... Domain must resolve Nov 4 04:10:45 bconnex.net sendmail[4972]: EAA04972: from=<tcsender(a)get-more-hits.com>, e=0, class=0, pri=0, nrcpts=0, proto=ESMTP, relay=root(a)vp2.netgate.net [204.145.147.60] Nov 4 04:10:48 bconnex.net sendmail[4974]: Ruleset check_mail ) rejection: 451 <tcsender(a)get-more-hits.com>... Domain must resolve Nov 4 04:10:48 bconnex.net sendmail[4974]: EAA04974: from=<tcsender(a)get-more-hits.com>, e=0, class=0, pri=0, nrcpts=0, proto=ESMTP, relay=root(a)kitchen.virtual-cafe.com 3] Nov 4 04:10:58 bconnex.net sendmail[4980]: Ruleset check_mail ) rejection: 451 <tcsender(a)get-more-hits.com>... Domain must resolve Nov 4 04:10:58 bconnex.net sendmail[4980]: EAA04980: from=<tcsender(a)get-more-hits.com>, e=0, class=0, pri=0, nrcpts=0, proto=ESMTP, relay=[151.196.85.2] Nov 4 04:11:04 bconnex.net sendmail[4985]: Ruleset check_mail ) rejection: 451 <tcsender(a)get-more-hits.com>... Domain must resolve Nov 4 04:11:04 bconnex.net sendmail[4985]: EAA04985: from=<tcsender(a)get-more-hits.com>, e=0, class=0, pri=0, nrcpts=0, proto=SMTP, relay=www.fixation.com [206.144.185.101] Nov 4 04:11:06 bconnex.net sendmail[4991]: Ruleset check_mail (<tcsender(a)need-hits.com>) jection: 451 <tcsender(a)need-hits.com>... Domain must resolve Nov 4 04:11:06 bconnex.net sendmail[4991]: EAA04991: from=<tcsender(a)need-hits.com>, class=0, pri=0, nrcpts=0, proto=SMTP, relay=ns2.kalamazoo.net [206.31.33.2] Nov 4 04:11:26 bconnex.net sendmail[5016]: Ruleset check_mail ) rejection: 451 <tcsender(a)get-more-hits.com>... Domain must resolve Nov 4 04:11:26 bconnex.net sendmail[5016]: EAA05016: from=<tcsender(a)get-more-hits.com>, e=0, class=0, pri=0, nrcpts=0, proto=SMTP, relay=fox.plaza.nl [195.108.180.1] Nov 4 04:12:07 bconnex.net sendmail[5042]: Ruleset check_mail ) rejection: 451 <tcsender(a)get-more-hits.com>... Domain must resolve Nov 4 04:12:07 bconnex.net sendmail[5042]: EAA05042: from=<tcsender(a)get-more-hits.com>, e=0, class=0, pri=0, nrcpts=0, proto=ESMTP, relay=[151.196.88.4] Nov 4 04:12:08 bconnex.net sendmail[5043]: Ruleset check_mail ) rejection: 451 <tcsender(a)get-more-hits.com>... Domain must resolve Nov 4 04:12:08 bconnex.net sendmail[5043]: EAA05043: from=<tcsender(a)get-more-hits.com>, e=0, class=0, pri=0, nrcpts=0, proto=SMTP, relay=yakko.x-statik.com [198.68.248.2] Nov 4 04:12:13 bconnex.net sendmail[5046]: Ruleset check_mail (<tcsender(a)need-hits.com>) jection: 451 <tcsender(a)need-hits.com>... Domain must resolve Nov 4 04:12:13 bconnex.net sendmail[5046]: EAA05046: from=<tcsender(a)need-hits.com>, class=0, pri=0, nrcpts=0, proto=ESMTP, relay=root(a)[140.174.206.23]

5 4

Re: tcsender email bombing
by Dennis Simpson 05 Nov '97

05 Nov '97

> From jdc(a)milehigh.denver.net Tue Nov 4 23:24:56 1997 > Date: Tue, 4 Nov 1997 21:25:07 -0700 > From: John-David Childs <jdc(a)nterprise.net> > To: Dennis Simpson <dennis(a)bconnex.net> > Cc: nanog(a)merit.edu > Subject: Re: tcsender email bombing > > On Tuesday November 4, 1997, Dennis Simpson <dennis(a)bconnex.net> > had this to say about "tcsender email bombing": > > > Having seen fairly heavy loading on our mail server today, I decided > > to see what might be going on. > > Yes...2741 entries in my maillog since 11:00pm yesterday...but our > mailserver barely hiccuped and I wouldn't have noticed for a day or two > unless I came across your post. What prompted you to go looking? > > > Approximately one third of our email traffic today has come from this. We keep a fairly close eye on our servers (most of the time :-) and when we suddenly see one source responsible for a third of the spam, it is worth making some effort to knock them off. Taking the connections just to reject them seems like a real waste to me, and so does logging it all. > You may want to change your 451 errors into 571 errors at least for this > particular domain. From RFC1893: Interesting point. I wonder how many people care what the reject code is, compared to how many just note that it failed, and follow it up as they would any failure, regardless of the failure code? Thx, dennis

2 1

Re: tcsender email bombing
by Dennis Simpson 05 Nov '97

05 Nov '97

It seems a number of people have been hit with this tcsender bulk mailer (my assumption at this time). I have complied this list of relay hosts from today's 5400+ messages fron this bulk mailer, and attach it below. We have blocked the 149 hosts below (many are nameservers and such, not even mail hosts). If you are in the list below, and wish to be removed from our filters, disable mail relaying on the host in question, and send me an email to let me know you have done this. Thx, dennis Hosts (sorted) relaying tcsender junk mail (probably automatically): 100t.lauderdale.net 140.174.206.23 151.196.77.254 151.196.85.2 151.196.86.2 151.196.88.4 195.174.42.30 204.254.231.160 205.136.174.5 205.217.137.150 205.242.140.6 206.10.45.200 206.160.206.67 206.168.161.1 206.40.130.13 206.58.85.201 206.79.156.10 207.14.226.2 207.213.148.64 207.225.237.126 207.240.167.1 207.7.23.17 208.10.235.1 208.137.49.1 208.196.180.2 208.224.58.2 208.9.75.2 209.125.1.12 209.41.247.88 209.63.20.193 NS1.Content.Net adzone.com alpha.cyberplex.com amyda.foe.co.uk astra.genghis.com athena.digimark.net atlas.novagate.net bay.wiznet.ca blueshift.com btci.org busche.com bw7.webex.net bytewe.com carlsbad.idir.net ch.promega.com challenge.e-net.com ck-internet-server.ckinc.com cosmo.armigeron.com cyberhost3.com cyberhost5.com dilbert.vcity.net dilbert2.southwindnet.com dnai.com draco.bv.sgi.net emke.com firstsystem.com fishmarket.com fivepoints.com flury.com forte.versilia.toscana.it fox.plaza.nl fozzie.bignet.net fr.promega.com frampton.saltmine.com france-travel.com fred.ic2do.com free-thought.com free-vacation.com gateway.foliage.com gemini.speakeasy.org gost19.indirect.com gost3.indirect.com helix.promega.com instorm.ni.net internet-designs.com intersessions.com it.InetTech.com jab1.roc.servtech.com kitchen.virtual-cafe.com lambdatel.com limerock.chunkstyle.com linked.net local33.4websites.com loki.domainnameservers.net mail.brainstorm.net mail.devontax.com mail.tmninc.com mail1.eni.net main.visionol.net mediabuy.com mercury.webserve.net metallus.ias.net mizzen.wantabe.com money.fsonline.com moon.pouch.com multi16.netcomi.com multi2.netcomi.com mustang.detroit.usweb.com new.mcgnet.com ns.falconsoft.com ns.intersessions.com ns1.ktc.com ns1.vie.com ns2.kalamazoo.net ntnot.acmenet.net oyster.covesoft.com pages.inthe.net poconos.net rabbit.supranet.net realbeer.com rockweb.meer.net sequoia.barnworth.com serv1.fwi.com server3.homecom.com server7.homecom.com server8.homecom.com shire.middleearth.net shire2.middleearth.net smartphone1.smartserv.com sparc10.alphawave.com taz.sb.west.net vgernet.net virtual.icanect.net vp2.netgate.net w3.cinternet.net wagner.mtco.com wcc.wcc.net web1.liberty.com web12.ntx.net web40.ntx.net web50.ntx.net winter.vcity.net winter2.southwindnet.com winter3.southwindnet.com woodstock.fissiontech.com www.fitertown.com www.fixation.com www.fredrick.com www.inetcomm.com www.knowledgeexpress.com www.neosoft.com www.sparknet.net www.thejetset.com www.unitedmedia.com www3.babenet.com x-1.nts-online.net xenon.xe.net yakko.x-statik.com zeus.total-access.net

1 0

Operational issues: AS10297 leaking routes
by dlr＠bungi.com 04 Nov '97

04 Nov '97

AS10297 is leaking routes to sprint from AS7018/6478/... Sprint has been alerted. No answer at the NOC phones for AS10297. Dave Rand +1 408 254-7111 -- Dave Rand dlr(a)bungi.com http://www.bungi.com

3 4

route-views.oregon-ix.net back up
by David M. Meyer 04 Nov '97

04 Nov '97

Thanks to a generous grant from Cisco Systems and cooperation from many people around the network, route-views.oregon-ix.net is back up. route-views.oregon-ix.net currently has the following views: CERFnet (San Diego) 134.24.127.3 through AS1740 Europe (RIPE) 193.0.0.242 through AS3333 IAGnet (Chicago) 131.103.20.49 through AS1225 LINX (London) 194.68.130.254 through AS5459 MCI (San Francisco) 204.70.4.89 through AS3561 PIPEX (London) 158.43.133.48 through AS1849 Sprint (Stockton) 144.228.240.93 through AS1239 Verio (MAE-WEST) 205.238.48.3 through AS2914 blackrose.org (Ann Arbor) 204.212.44.128 through AS234 Please have a look and let me know if there are ways we might improve the service (or if you have any other questions or comments). Thanks, Dave

1 0

A First Byte of IPv8
by Jim Fleming 04 Nov '97

04 Nov '97

To NANOG list members... Thanks for the interesting comments on IPv6 and IPv4. It is always interesting to see why IPv6 is the way it is. As you might know, IPv8 is not that way... All you have to do is look at the first byte of IPv8 to realize that it was designed for performance, not to satisfy or calm the press. There are 8 bits in that byte and they have been carefully allocated as follows: 1OSSSDDD 1 - The IPv8 flag bit (IPv4 and IPv6 are 0) O - Options Present (0 - no, 1 - yes) SSS - Source Galaxy DDD - Destination Galaxy By looking at only this first byte, routers can sort packets destined for one of the 8 Galaxies very quickly. Routers can also discover whether the header contains options and route those packets locally for further processing. IPv8 has exactly the same size header as IPv4. It is therefore easy to learn and understand. IPv8 has been designed with 48 byte ATM payloads in mind. Therefore, the performance people and QOS people will be happy. IPV8 has been designed for the emerging world of circuit switched routing, where packets are moved a long way without "hops" so that they can be delivered to their intended destination as quickly as possible. IPv8 was designed to address the routing problem as well as the Address Management and Governance problems. The 11 bits of addressing added to the 32 bit IPv4 addresses are divided into 3 bits and 8 bits and a natural hierarchy takes shape. The core has 8 regions each with 256 distribution centers and from there full 32 bit Internets. This is 2,048 address spaces. If these address spaces are managed well, they can be used in IPv6 addressing. NANOG people may want to consider focusing on address space management without being concerned about the protocol header format. NANOG could help to make a contribution in making sure these emerging address spaces are managed the way your members desire. That would be a major contribution to the future of all the 2,048 Internets. Jim Fleming Unir Corporation IBC, Tortola, BVI

4 4

Sausage making, SS7 and protocols
by Sean Donelan 04 Nov '97

04 Nov '97

>In a world where the internet industry is becoming >more and more like the telecoms industry, the >necessity of users to have protocol level access >to the network is diminishing, and the dangers >of doing so are becoming greater. Which telcos >will blithely hand out SS7 interconnects to >users? Without (routable) IP access, there >would be no SYN floods of distant networks, no >source spoofing, less hacking, easier traceability, >and the BGP table need only be OTO 1 entry per >non-leaf node on a provider interconnection >graph. Strange how people in the telecom industry think they need to become more like the internet industry, and people in the internet industry think they need to become more like the telecom industry. If you want to see some sausage being made, take a look at the "Advance Intelligent Network" and the Internet interface working group PINT. In the US, with telecom deregulation, the distinction between 'users' and 'telephone companies' is becoming less distinct. When an insurance company, an university, or an ISP files the paperwork to become a CLEC, are they a 'user' or a 'telco?' What telco would refuse SS7 interconnects to a CLEC? The trust model in SS7 makes rlogin look like a high-security protocol. SS7 was developed in an environment where there would be a few trusted 'users.' As the number of 'telco'-like entities explodes, you might see some interesting security issues showing up with SS7. There is some 'screening' between networks, but gateway STP nodes have many of the same problems as Internet firewalls. Internet providers give both less and more access to their networks than telcos. Generally ISPs don't give other ISPs more access to their networks than any other untrusted user. Even read-only SNMP between providers is almost non-existant. Most ISPs would probally consider giving SS7 level access into their network to another ISP a huge security hole. In some sense, interconnecting ISPs is easier than telcos because the security risk of connecting to another ISP is the same as connecting to a user. Today's SS7 network is far more risky than anything Capt. Crunch could do with his whistle. On the other hand, it seems like many ISPs don't consider it a duty to screen or filter their customer's ingress or their own egress. While telco's almost always screen information such as directory numbers when they originate from a customer PBX. This has less to do with the SS7 protocol, than the trust relationship between telcos. Telcos trust other telcos to only send SS7 packets with screened customer phone numbers. This 'trust' is formalized into extremely complicated agreements between telcos, especially who is liable when the trust is broken. ISPs have very simple 'trust' relationships (i.e. trust no one), and correspondingly simple agreements between them. Since there is a much lower trust relationship between ISPs, tracing malicious behavior is much more difficult. At a simple level, look how caller-id information is treated between telcos. Telcos pass caller-id information, more or less, on an end-to-end basis through the SS7 network 'sharing' it with all the telco's along the way. However, telcos don't pass the caller-id information to the 'user' if the presentation-restricted flag is set. ISPs don't normally provide any more information to another ISP than they do to an user. Which model causes less problems when the CLEC turns out to be an private investigative company, or a university. It will be interesting to see which trust model works better as the number of CLECs grows or the number of ISPs shrinks, depending on which consulting group you want to believe. Will ISPs start trusting each other more, or will telcos start trusting each other less? At some companies, the Internet connection is the most secure outside communications connection they have. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

2 1