- NZNOG - lists.nznog.org

nz spam
by Thomas Salmen 18 Aug '03

18 Aug '03

so this is your fault juha http://www.nzherald.co.nz/storydisplay.cfm?storyID=3518682&thesection=news&t hesubsection=general

5 7

RE: [nznog] Weird pings
by Drazen Babich 18 Aug '03

18 Aug '03

Looks to be related to the stuff below : http://securityresponse.symantec.com/avcenter/venc/data/w32.welchia.worm.htm l <http://securityresponse.symantec.com/avcenter/venc/data/w32.welchia.worm.ht ml> PSS Security Response Team Alert - New Worm: Nachi, Blaster-D, Welchia<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" /> SEVERITY: CRITICAL DATE: 08/18/2003 PRODUCTS AFFECTED: Windows 2000 and XP, Internet Information Services 5.0 ********************************************************************** WHAT IS IT? A new worm is spreading in the wild. The Microsoft Product Support Services Security Team is issuing this alert to advise customers to be on the alert for this virus as it spreads in the wild. Customers are advised to review the information and take the appropriate action for their environments. IMPACT OF ATTACK: Network Propagation, Patch Installation TECHNICAL DETAILS: Similar to the earlier Blaster worm and its variants, this worm also exploits the vulnerability patched by Microsoft Security Bulletin MS03-026, and instructs target systems to download its copy from the affected system using the TFTP program. In addition to exploiting the RPC vulnerability patched by Microsoft Security Bulletin <?xml:namespace prefix = st2 ns = "schemas-microsoft-com/microsoft" />MS03-026 this worm also uses a previously patched vulnerability in Microsoft Security Bulletin MS03-007 directed at IIS 5.0 over port 80 to propagate to un-patched systems. In addition upon successful infection this worm also patches systems with the patch for Microsoft Security Bulletin MS03-026. It does this by first determining the operating system and then downloading the associated patch for that operating system. For additional details on this worm from anti-virus software vendors participating in the Microsoft Virus Information Alliance (VIA) please visit the following links: Network Associates: http://vil.nai.com/vil/content/v_100559.htm <http://vil.nai.com/vil/content/v_100559.htm> Trend Micro: http://www.trendmicro.com/vinfo/virusencyclo/default5.asp?VName=WORM_MSBLAST .D <http://www.trendmicro.com/vinfo/virusencyclo/default5.asp?VName=WORM_MSBLAS T.D> Symantec http://securityresponse.symantec.com/avcenter/venc/data/w32.welchia.worm.htm l <http://securityresponse.symantec.com/avcenter/venc/data/w32.welchia.worm.ht ml> For more information on Microsoft's Virus Information Alliance please visit this link: http://www.microsoft.com/technet/security/virus/via.asp <http://www.microsoft.com/technet/security/virus/via.asp> Please contact your Antivirus Vendor for additional details on this virus. PREVENTION: Turn on Internet Connection Firewall (Windows XP or Windows Server 2003) or use a third party firewall to block incoming TCP ports 80, 135, 139, 445 and 593; UDP ports 135, 137, 38. To enable the Internet Connection Firewall in Windows XP please see the instructions below or visit this Knowledge Base Article: http://support.microsoft.com/?id=283673 <http://support.microsoft.com/?id=283673> * In Control Panel, double-click Networking and Internet Connections, and then click Network Connections. * Right-click the connection on which you would like to enable ICF, and then click Properties. * On the Advanced tab, click the box to select the option to Protect my computer or network. This worm utilizes two previously-announced vulnerabilities as part of its infection method. Because of this, customers must ensure that their computers are patched for the vulnerabilities that are identified in the following Microsoft Security Bulletins. Microsoft Security Bulletin MS03-026 http://www.microsoft.com/technet/security/bulletin/MS03-026.asp <http://www.microsoft.com/technet/security/bulletin/MS03-026.asp> Microsoft Security Bulletin MS03-007 http://www.microsoft.com/technet/security/bulletin/MS03-007.asp <http://www.microsoft.com/technet/security/bulletin/MS03-007.asp> In order to assist customers with the installation of the patch for Microsoft Security Bulletin MS03-026 Microsoft has released a tool which can be used to scan a network for the presence of systems which have not had the MS03-026 patch installed. More details on this tool are available in Microsoft Knowledge Base article 826369. RECOVERY: If your computer has been infected with this virus, please contact your preferred antivirus vendor or Product Support Services for assistance with removing it. RELATED KB ARTICLES: http://support.microsoft.com/default.aspx?scid=kb;en-us;826234 This article will be available within 24 hours. RELATED SECURITY BULLETINS: Microsoft Security Bulletin MS03-026 http://www.microsoft.com/technet/security/bulletin/MS03-026.asp <http://www.microsoft.com/technet/security/bulletin/MS03-026.asp> Microsoft Security Bulletin MS03-007 http://www.microsoft.com/technet/security/bulletin/MS03-007.asp <http://www.microsoft.com/technet/security/bulletin/MS03-007.asp> VIRUS ALERT LINK: http://www.microsoft.com/technet/security/virus/alerts/nachi.asp <http://www.microsoft.com/technet/security/virus/alerts/nachi.asp> As always please make sure to use the latest Anti-Virus detection from your Anti-Virus vendor to detect new viruses and their variants. -----Original Message----- From: Perry Lorier [mailto:perry(a)deeper.co.nz] Sent: Tuesday, 19 August 2003 1:09 a.m. To: nznog(a)list.waikato.ac.nz Subject: [nznog] Weird pings _____ This e-mail message has been scanned and cleared by MailMarshal at www.gen-i.co.nz <http://www.gen-i.co.nz> _____

1 0

Weird pings
by Perry Lorier 18 Aug '03

18 Aug '03

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Is everyone else seeing ICMP echo request packets sent to random IP's from what appear to be insecure windows machines? The pings seem to be appearing every few minutes, and don't seem to be isolated to any particular ISP, or even anywhere in particular in the world, which is easily confirmed by ssh'ing to machines in the US and EU and doing tcpdump and seeing exactly the same traffic. The pings look like: 00:53:59.511049 61.85.33.233 > xx.xx.xx.xx: icmp: echo request (ttl 114, id 32026, len 92) 0x0000 4500 005c 7d1a 0000 7201 028e 3d55 21e9 E..\}...r...=U!. 0x0010 xxxx xxxx 0800 fba0 0400 a309 aaaa aaaa .m.M............ 0x0020 aaaa aaaa aaaa aaaa aaaa aaaa aaaa aaaa ................ 0x0030 aaaa aaaa aaaa aaaa aaaa aaaa aaaa aaaa ................ 0x0040 aaaa aaaa aaaa aaaa aaaa aaaa aaaa aaaa ................ 0x0050 aaaa aaaa aaaa aaaa aaaa aaaa ............ This seems to have been going on for quite a long time (a week? two weeks?) and the source addresses seem rather varied. Current speculation is that this is an attack on the source address done by spoofing the source to be the target and sending to legitimate destination addresses. Does anyone have any more information? - -- Xerox does it again and again and again and ... -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Only when you are sure they have you, can you stop being paranoid iD8DBQE/QM/rcAgRpy8z8UQRAjAIAKC8So3A3cRgOuIjJYx9M6GwMMQ0ewCgj5+u kmG5NtMLnUx71k7c6eyQpyI= =LEDs -----END PGP SIGNATURE-----

6 6

RE: [nznog] blaster worm
by Simon Byrnand 17 Aug '03

17 Aug '03

At 14:16 16/08/2003 +1000, Nathan Mercer wrote: >If you are having problems with WU can I suggest you try this URL >https://v4.windowsupdate.microsoft.com/en/default.asp > >Cheers >Nathan Yep that works, it reports updates that are needed. However, two days later and the normal Windows Update URL, that everyone else in the world uses, still doesn't work - it just reports that there are no updates needed, and it doesn't perform the scanning step (33%....66%) that it should. I just checked on a Windows 2000 machine that hadn't already been updated for the Blaster Worm, and the normal Windows Update (as accessed from the Start menu or through Tools -> Windows Update) cheerfully announced that there were no critical updates (or indeed updates of any kind) while your link revealed that the patch was needed. I wonder just how widespread this is and how many people are getting lulled into a false sense of security thinking they're protected against the worm because Windows Update doesn't offer any updates.... Regards, Simon

1 0

RE: [nznog] blaster worm
by Nathan Mercer 17 Aug '03

17 Aug '03

Infected systems begin the attack when their system clocks reach 16 August, and continue until December 31. From January through July, infected systems will only conduct the DDoS attack from the 15th through the end of each month Nathan -----Original Message----- From: Steve Withers [mailto:swithers(a)mmp.org.nz] Sent: Saturday, 16 August 2003 12:52 a.m. To: NZ NOG Subject: Re: [nznog] blaster worm On Fri, 2003-08-15 at 23:22, Malcolm Lockyer wrote: > Should be a more interesting 24 hours then eh? :-| It's supposed to start on the 16th.....do we know for sure if it is set to stop on the 17th? Or will it keep going until the PCs concerned are disconnected from the network? -- Steve Withers <swithers(a)mmp.org.nz> _______________________________________________ Nznog mailing list Nznog(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog

7 6

RE: [nznog] microsoft.com
by Jithen Singh 16 Aug '03

16 Aug '03

Whoops !! Sorry, missed that .. -----Original Message----- From: Craig Spiers [mailto:craig(a)concept.net.nz] Sent: Sunday, 17 August 2003 5:57 p.m. To: 'Jithen Singh' Cc: nznog(a)list.waikato.ac.nz Subject: RE: [nznog] microsoft.com Friday august 1.. Last Friday was Friday august 15th.. :) -----Original Message----- From: Jithen Singh [mailto:jsingh(a)net4u.co.nz] Sent: Sunday, August 17, 2003 5:55 PM To: nznog(a)list.waikato.ac.nz Subject: RE: [nznog] microsoft.com Microsofts downtime on Friday was in fact due to a denial of service attack http://www.microsoft.com/homepage/features/2003/denialofservice.htm Quote : "Overnight, microsoft.com has suffered an outage of a little over an hour. Microsoft have posted to the effect that this was caused by a [presumably non-http] denial of service that is not associated with any known vulnerability in Microsoft's own software. Speculation on Information Week that the outage might be part of a broader attack on internet infrastructure or linked to the start of the Defcon conference seems implausible, as only one other Fortune 100 site has shown an outage in the last 24 hours. Three of the 52 leading hosting providers monitored by Netcraft are showing outages in the last 24 hours, but all three are outside the US." Regards, Jithen -----Original Message----- From: Barry Murphy [mailto:barry(a)unix.co.nz] Sent: Saturday, 16 August 2003 6:12 p.m. To: Craig Spiers Cc: nznog(a)list.waikato.ac.nz Subject: Re: [nznog] microsoft.com Contentm not logs. They have 31gig or something (stand to be corrected, just read the link), but they currently have 102gig of content. If they creating 4gig of content a day, that would mean in 25 days they would have 204gigs of content. Surely this cannot be correct. Maybe it's just the beers doing the math, but thats the way I understand it. Barry ----- Original Message ----- From: "Craig Spiers" <craig(a)concept.net.nz> Cc: <nznog(a)list.waikato.ac.nz> Sent: Saturday, August 16, 2003 6:06 PM Subject: RE: [nznog] microsoft.com > That would be about right.. Logfiles and all.. > > Surely they don't keep logs more than 7 days :) > > -----Original Message----- > From: Barry Murphy [mailto:barry(a)unix.co.nz] > Sent: Saturday, August 16, 2003 6:05 PM > To: Nathan Mercer; Juha Saarinen > Cc: nznog(a)list.waikato.ac.nz > Subject: Re: [nznog] microsoft.com > > Sorry, it also says on the MS site ... > > "102 GB of content" then goes on to say "Content created around the clock. > Approximately 4 GB of new and updated content published daily". That > would mean that every 25 days it would create or update the same > amount of content > that is currently on the server. Surely this isnt correct? > > Barry > > ----- Original Message ----- > From: "Nathan Mercer" <nmercer(a)microsoft.com> > To: "Juha Saarinen" <juha(a)saarinen.org> > Cc: <nznog(a)list.waikato.ac.nz> > Sent: Saturday, August 16, 2003 5:32 PM > Subject: RE: [nznog] microsoft.com > > > Microsoft.com is run on IIS6 with Windows Server 2003 > http://www.microsoft.com/backstage/inside.htm > > Akamai provide a content distribution network and dns to get download files > closer to end users to improve the overall end user experience by > speeding up file downloads. > > http://uptime.netcraft.com/up/graph?site=www.microsoft.com reports > that MS is running IIS6 on Linux! How is that possible? > > http://uptime.netcraft.com/up/accuracy.html#impossible > > Why do you report impossible operating system/server combinations ? > > Webservers that operate behind a caching system, load balancer, > reverse proxy server or a firewall may sometimes report the operating > system of the > intermediate machine. Hence reports of 'Microsoft/IIS on Linux' may indicate > that either the web server is behind a Linux server that is acting as > a reverse proxy, or has configured the Akamai caching system such that > the first request to the site goes to one of Akamai's servers [which > run Linux], > or as in the case of www.walmart.com has been configured to send a > misleading signature. > > -----Original Message----- > From: Juha Saarinen [mailto:juha(a)saarinen.org] > Sent: Saturday, 16 August 2003 9:12 a.m. > To: Joe Abley > Cc: nznog(a)list.waikato.ac.nz > Subject: Re: [nznog] microsoft.com > > Joe Abley wrote: > > > That power outage knocked out bits of the North Eastern US and most > > of > > > South-Western Ontario (including my house -- still no power here, > > just > > > laptops and cellphones). To the best of my knowledge most > > Microsoft-branded services are served out of Redmond, and Hotmail is > in > > the Bay Area somewhere (used to be in an MFN/AboveNet facility in > > San Jose, but I seem to remember they moved a while ago). > > > > Most large exchange facilities in New York seem to have survived on > > battery and diesel power, and I don't believe the outage stretched > > as far as Virginia (where it might have stood a fighting chance of > > impacting some high concentrations of network operators). > > > > So probably not related to the power outage. > > It's also interesting to note that a good chunk of Microsoft's Web > content is served from Linux boxes. "Akamaighost" apparently runs on Linux. > > Here's an example: > > http://uptime.netcraft.com/up/graph?site=a100.ms.a.microsoft.com > > Looks like Windows Update arrives to you via Linux as well. > > -- > Juha > > _______________________________________________ > Nznog mailing list > Nznog(a)list.waikato.ac.nz > http://list.waikato.ac.nz/mailman/listinfo/nznog > > > _______________________________________________ > Nznog mailing list > Nznog(a)list.waikato.ac.nz > http://list.waikato.ac.nz/mailman/listinfo/nznog > > > > > _______________________________________________ > Nznog mailing list > Nznog(a)list.waikato.ac.nz > http://list.waikato.ac.nz/mailman/listinfo/nznog > > > > _______________________________________________ > Nznog mailing list > Nznog(a)list.waikato.ac.nz > http://list.waikato.ac.nz/mailman/listinfo/nznog > _______________________________________________ Nznog mailing list Nznog(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog _______________________________________________ Nznog mailing list Nznog(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog

1 0

RE: [nznog] microsoft.com
by Nathan Mercer 16 Aug '03

16 Aug '03

Microsoft.com is run on IIS6 with Windows Server 2003 http://www.microsoft.com/backstage/inside.htm Akamai provide a content distribution network and dns to get download files closer to end users to improve the overall end user experience by speeding up file downloads. http://uptime.netcraft.com/up/graph?site=www.microsoft.com reports that MS is running IIS6 on Linux! How is that possible? http://uptime.netcraft.com/up/accuracy.html#impossible Why do you report impossible operating system/server combinations ? Webservers that operate behind a caching system, load balancer, reverse proxy server or a firewall may sometimes report the operating system of the intermediate machine. Hence reports of 'Microsoft/IIS on Linux' may indicate that either the web server is behind a Linux server that is acting as a reverse proxy, or has configured the Akamai caching system such that the first request to the site goes to one of Akamai's servers [which run Linux], or as in the case of www.walmart.com has been configured to send a misleading signature. -----Original Message----- From: Juha Saarinen [mailto:juha(a)saarinen.org] Sent: Saturday, 16 August 2003 9:12 a.m. To: Joe Abley Cc: nznog(a)list.waikato.ac.nz Subject: Re: [nznog] microsoft.com Joe Abley wrote: > That power outage knocked out bits of the North Eastern US and most of > South-Western Ontario (including my house -- still no power here, just > laptops and cellphones). To the best of my knowledge most > Microsoft-branded services are served out of Redmond, and Hotmail is in > the Bay Area somewhere (used to be in an MFN/AboveNet facility in San > Jose, but I seem to remember they moved a while ago). > > Most large exchange facilities in New York seem to have survived on > battery and diesel power, and I don't believe the outage stretched as > far as Virginia (where it might have stood a fighting chance of > impacting some high concentrations of network operators). > > So probably not related to the power outage. It's also interesting to note that a good chunk of Microsoft's Web content is served from Linux boxes. "Akamaighost" apparently runs on Linux. Here's an example: http://uptime.netcraft.com/up/graph?site=a100.ms.a.microsoft.com Looks like Windows Update arrives to you via Linux as well. -- Juha _______________________________________________ Nznog mailing list Nznog(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog

5 7

RE: [nznog] blaster worm
by Nathan Mercer 16 Aug '03

16 Aug '03

We're experiencing increased traffic levels, but its not DoSing us. You might be interested in reading some more about the Blaster worm here Recommendations to ISPs Regarding the Blaster Worm http://www.microsoft.com/serviceproviders/security/isp_blaster.asp There is a Word DOC there with some more info. You can read with the Word viewer downloadable here http://download.microsoft.com/download/word2000/wd97vwr/2000/WIN98/EN-US /wd97vwr32.exe Nathan -----Original Message----- From: Barry Murphy [mailto:barry(a)unix.co.nz] Sent: Saturday, 16 August 2003 9:45 a.m. To: Nathan Mercer Cc: NZ NOG Subject: Re: [nznog] blaster worm Nathan, Are you aware of microsoft being affected from the DDoS of this virus yet? Seeing as you people will probably hear first off.

6 5

spam farms
by Liz Q 16 Aug '03

16 Aug '03

Is there anything that can be done about these 'Spam Farms' ? ie Companies that take 30+ C classes have a domain for every c class and set up reverse and forward mx<num>@<domain> for each ip. They appear to be designed purely for spam and One company in particular ive been having issues with, appear to own a couple hundred C class. Is there any way they can be mass listed with spam servers? Liz Q

1 0

RE: [nznog] blaster worm
by Nathan Mercer 16 Aug '03

16 Aug '03

www.windowsupdate.com isn't used for anything. It used to redirect to windowsupdate.microsoft.com If customers need to download patches they should be going to Windows Update link in their start menus which goes to windowsupdate.microsoft.com or www.windows.com 30 mins to go... Regards Nathan Microsoft NZ -----Original Message----- From: Malcolm Lockyer [mailto:ipvariance(a)hotmail.com] Sent: Friday, 15 August 2003 11:23 p.m. To: lennon(a)orcon.net.nz; simon.lyall(a)ihug.co.nz Cc: nznog(a)list.waikato.ac.nz Subject: Re: [nznog] blaster worm --snippity-- >Subject: Re: [nznog] blaster worm >Date: 15 Aug 2003 21:56:15 +1200 > >--snippity-- > >Make www.windowsupdate.com point to 127.0.0.1 so it doesn't do anything >or what? Except that it makes it a more effective DOS. Because then NOBODY can reach windowsupdate regardless - instead of just painfully slowly - or decently for whatever Akamai based reason. Time to hold onto whatever body part you guys value - here comes the storm. Although on a side note I hope the blaster infections are lower than I think they are - because all of you have been blocking netbios / 139tcp / etc. since this thing broke out. Right? Should be a more interesting 24 hours then eh? :-| m > >Thanks >Craig Whitmore >Orcon Internet >http://www.orcon.net.nz > --snippity-- _________________________________________________________________ Download MSN Messenger @ http://messenger.xtramsn.co.nz - talk to family and friends overseas! _______________________________________________ Nznog mailing list Nznog(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog

6 6

blaster worm
by Simon Lyall 15 Aug '03

15 Aug '03

According to published docs on the worm it attacks "windowsupdate.com" which maps to ip's in 204.79.188.0/24 However checks to my cache logs show that nothing ever goes to plain old http://windowsupdate.com . Everything goes to download.windowsupdate.com , www.download.windowsupdate.com or something else. Even www.windowsupdate.com points elsewhere. In fact a glance though cache logs so nothing going anywhere near the 204.79.188.0/24 network. Even better the 204.79.188.0/24 is a /24 all by itself advertised as a /24. Does this mean: 1. It's safe to null route this network. 2. Microsoft will withdraw the advertisement for the network if the going gets tough. I notice that there is no route for the network on route-server.cw.net already. Thoughts? -- Simon Lyall. | Newsmaster | Work: simon.lyall(a)ihug.co.nz Senior Network/System Admin | Postmaster | Home: simon(a)darkmere.gen.nz Ihug Ltd, Auckland, NZ | Asst Doorman | Web: http://www.darkmere.gen.nz

11 11

RE: [nznog] blaster worm
by Nathan Mercer 15 Aug '03

15 Aug '03

If you are having problems with WU can I suggest you try this URL https://v4.windowsupdate.microsoft.com/en/default.asp Cheers Nathan -----Original Message----- From: Jithen Singh [mailto:jsingh(a)net4u.co.nz] Sent: Saturday, 16 August 2003 10:06 a.m. To: 'Simon Byrnand'; 'Barry Murphy' Cc: 'NZ NOG' Subject: RE: [nznog] blaster worm According to articles posted on the web, Microsoft installed Windows Update from scratch (fresh install), and since then, updates that needed downloading have failed to show. Some have suggested changing the language to EN-US and this will fix the problem, but I have yet to see proper solution as yet. Regards Jithen -----Original Message----- From: Simon Byrnand [mailto:simon(a)igrin.co.nz] Sent: Saturday, 16 August 2003 9:57 a.m. To: Barry Murphy Cc: NZ NOG Subject: Re: [nznog] blaster worm > Nathan, > > Are you aware of microsoft being affected from the DDoS of this virus yet? > Seeing as you people will probably hear first off. > > P.S. I dont want you to loose your job so you can mail me off list if > you > like:) > > Barry I don't know about direct effects of the worm, but both windows update and the microsoft sites in general seemed to be down for many hours yesterday afternoon.... maybe it was just a huge influx of people trying to get at the patches, or maybe some server upgrades went awry...(apparently MS were going to increase their web serving capacity...) Also I tried Windows Update from a Windows 2000 machine just now and although it appears to be working, all is not well because it reports "There are no updates available for your computer" when I know full well that it normally keeps insisting that I install the .NET stuff and Media player 9. (And a few other things under the windows section that I normally refuse to install) Perhaps MS have temporarily suspended downloading of "non critical" updates to reduce the server load from people who go to windows update primarily to get the security related updates.... Regards, Simon _______________________________________________ Nznog mailing list Nznog(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog _______________________________________________ Nznog mailing list Nznog(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog

1 0

RE: [nznog] blaster worm
by Nathan Mercer 15 Aug '03

15 Aug '03

You're correct. We never used windowsupdate.com for anything, none of our stuff points to it at all - it was only a redirect site. There was a redirect in place going from windowupdate.com to windowsupdate.microsoft.com up until about 9pm NZ time last night. Cheers Nathan -----Original Message----- From: Simon Byrnand [mailto:simon(a)igrin.co.nz] Sent: Saturday, 16 August 2003 9:33 a.m. To: Kerry Thompson Cc: NZ NOG Subject: RE: [nznog] blaster worm > windowsupdate.com has been pulled my MS. > See > > http://slashdot.org/article.pl?sid=03/08/15/1730200&mode=thread&tid=109& tid=126&tid=172&tid=187 > > I believe they've shifted to windowsupdate.microsoft.com I wouldn't say they've "shifted" to windowsupdate.microsoft.com. As far as I'm aware, thats always been the actual URL of windows update pretty much since day one. I've been using windowsupdate.microsoft.com as the URL for years now.... Maybe they had a redirection page at windowsupdate.com or just mirrored that URL as well. If the worm really targets windowsupdate.com and not windowsupdate.microsoft.com then the worm author isn't as smart as they'd like to think they are :) (big surprise there huh....) Regards, Simon _______________________________________________ Nznog mailing list Nznog(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog

6 5

Nauru
by Jon Leeman 15 Aug '03

15 Aug '03

>What is Nauru? and do you connect via telstra clear; they the only ISP i >know that connect via reach. That's the fourth, private query from members of this list I've had..............look north from NZ and it's just below the equator..........Nauru is known as the 'smallest' sovereign nation (if you discount the Vatican) on the planet...........google for Nauru + "phosphate" (or "John Howard's Pacific Solution", "Money Laundering", etc.. Internet access is via a 64/64 Kbps link with an F3 IDR ES using IntelSat and Telstra Reach. I'm an Oz 'expat' resident (14+ years). Rgds., Jon Jon Leeman .nr ccTLD Technicial Contact ISP Technician CenpacNet Inc. Republic of Nauru e: jleeman(a)cenpac.net.nr w: www.cenpac.net.nr

1 0

APE route servers
by Andy Linton 15 Aug '03

15 Aug '03

Those of you who use our route servers should use the Looking Glass at http://www.wix.net.nz/cgi-bin/mrlg-ape.cgi to check that you are peering with both route servers. Some of you have a session with rs1 but not with rs2. It would make sense for you to add the second server for redundancy. The configuration details are identical apart from the IP address of the BGP peer. 192.203.154.2 instead of 192.203.154.1.

3 2

Re: [nznog] blaster worm
by Malcolm Lockyer 15 Aug '03

15 Aug '03

--snippity-- >Subject: Re: [nznog] blaster worm >Date: 15 Aug 2003 21:56:15 +1200 > >--snippity-- > >Make www.windowsupdate.com point to 127.0.0.1 so it doesn't do anything >or what? Except that it makes it a more effective DOS. Because then NOBODY can reach windowsupdate regardless - instead of just painfully slowly - or decently for whatever Akamai based reason. Time to hold onto whatever body part you guys value - here comes the storm. Although on a side note I hope the blaster infections are lower than I think they are - because all of you have been blocking netbios / 139tcp / etc. since this thing broke out. Right? Should be a more interesting 24 hours then eh? :-| m > >Thanks >Craig Whitmore >Orcon Internet >http://www.orcon.net.nz > --snippity-- _________________________________________________________________ Download MSN Messenger @ http://messenger.xtramsn.co.nz - talk to family and friends overseas!

2 1

OT: MP3 Players
by Dan Clark 12 Aug '03

12 Aug '03

Hey did anyone else get one of these MP3 players My version of the manual has no page 9 and 2 page 10's incl 2 covers ?? Also, how do ya get it to be recognised in WinXP? Kind Regards, Dan Clark Network Manager Scarfies.Net Ltd

6 5

ISPs / Sites blocking IPs?
by Steve Withers 10 Aug '03

10 Aug '03

All I'm on a TelstraClear / paradsie cable modem. When I try to access the web site for the "Indepednent" in the UK, I get: Access Denied You don't have permission to access "http://news.independent.co.uk/uk/environment/story.jsp?" on this server. I'm thinking they have started blocking IPs they may consider possible sources of SPAM.... Has anyone else seen this? Can everyone else access this site from their networks? I'm on 203.96.144.119. -- Steve Withers <swithers(a)mmp.org.nz>

4 3

Full URL
by Steve Withers 10 Aug '03

10 Aug '03

Sorry...the full URL is: http://news.independent.co.uk/uk/environment/story.jsp?story=431319 -- Steve Withers <swithers(a)mmp.org.nz>

1 0

Error
by Sahil Gupta - NET4U LIMITED 10 Aug '03

10 Aug '03

Apologies, the network is 202.50.167.0/24 and not 202.50.267.0/24 Regards, Sahil Gupta Senior Account Manager NET4U LIMITED Phone: 0508-263-848 Fax: 07-8582659 Mobile: 029-366-6375

1 0

Prefix-List Update for Net4U Limited (AS23746)
by Sahil Gupta - NET4U LIMITED 10 Aug '03

10 Aug '03

Hi, Could ISP's currently peering with Net4U at APE kindly add the below listed network to the net4u's current prefix-list: 202.50.267.0/24 A full prefix-list is attached. Regards, Sahil Gupta Senior Account Manager NET4U LIMITED Phone: 0508-263-848 Fax: 07-8582659 Mobile: 029-366-6375

1 0

RE: [nznog] Re:Domain Name Scams
by Paul Adshead 10 Aug '03

10 Aug '03

It is to be fair, incredibly simple to find out most of the information regarding the allocation of a domain. Just go to the main DomaiNZ page: www.domainz.net.nz and enter your (NZ) domain name into the search box on the left. After selecting OK, then a warning about not being able to use this information for any other purpose appears - and this warning automatically disappears after a few seconds anyway. After this, then all of the details for the queried domain appear! As the warning message automatically disappears, then the content of the warning is probably not legally enforceable anyway - you could have been looking away from your screen at that point! They should have a "Yes I've read the above agreement" checkbox before you can proceed... Possible ways that the scam has found out the contact info: - if you knew enough about HTML, ASP and VB, it would be simple enough to write a program that once every five seconds sent a request to the DomaiNZ webserver starting at "a.co.nz" and finishing at "zzzzzzz999.net.nz", to find out the information for the various domains - it would take a while though; - you could use an 'electronic dictionary' of words in order to cut down on the unlikely examples; - there is also probably an online listing somewhere, of all of the currently active companies in New Zealand, you could then just try "<company name>.co.nz" and "<company name>.net.nz". There are far too many ways that people could have done it. I'm not condoning what has happened and have not done so myself, I'm just trying to explain how easy it is to do so. I was hit with three renewals too... Paul Adshead Network and Systems Manager OTL Software Ltd www.otl.co.nz -----Original Message----- From: Juha Saarinen [mailto:juha(a)saarinen.org] Sent: Friday, 8 August 2003 13:04 To: PhoneNet Cc: nznog(a)list.waikato.ac.nz Subject: Re: [nznog] Re:Domain Name Scams On Fri, 8 Aug 2003, PhoneNet wrote: > I have today received 5 letters from The Domain Registry of America, > Melbourne (posted in UK) asking me to re-register some of my domains as > they are due to expire - so they are at it also. Got one here as well, and what bothers me is that although the domain in question is registered under my own name, the letter was addressed to my company, which doesn't appear in whois data anywhere. Somebody's been trawling... -- Juha Saarinen _______________________________________________ Nznog mailing list Nznog(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog

5 5

FW: [nznog] Re:Domain Name Scams
by Tim John 09 Aug '03

09 Aug '03

> Just go to the main DomaiNZ page: www.domainz.net.nz and > enter your (NZ) > domain name into the search box on the left. After selecting > OK, then a > warning about not being able to use this information for any > other purpose > appears - and this warning automatically disappears after a > few seconds > anyway. After this, then all of the details for the queried > domain appear! > As the warning message automatically disappears, then the > content of the > warning is probably not legally enforceable anyway - you > could have been > looking away from your screen at that point! They should > have a "Yes I've > read the above agreement" checkbox before you can proceed... > Actually, the warning message appears on the Domainz homepage, the 'SRS is being queried' page and the results page. It only disappears when the page reloads with the results. It's only a GUI'd representation of a WhoIs query. On registration, there is a physical need to click a "I've read the terms of service" button, but at the end of the day, any information entered as part of a domain name registration is available in the public domain. Tim > Possible ways that the scam has found out the contact info: > - if you knew enough about HTML, ASP and VB, it would be > simple enough to > write a program that once every five seconds sent a request > to the DomaiNZ > webserver starting at "a.co.nz" and finishing at > "zzzzzzz999.net.nz", to > find out the information for the various domains - it would > take a while > though; > - you could use an 'electronic dictionary' of words in order > to cut down on > the unlikely examples; > - there is also probably an online listing somewhere, of all of the > currently active companies in New Zealand, you could then > just try "<company > name>.co.nz" and "<company name>.net.nz". > > There are far too many ways that people could have done it. > > I'm not condoning what has happened and have not done so > myself, I'm just > trying to explain how easy it is to do so. I was hit with > three renewals > too... > > Paul Adshead > Network and Systems Manager > OTL Software Ltd > www.otl.co.nz > > > -----Original Message----- > From: Juha Saarinen [mailto:juha(a)saarinen.org] > Sent: Friday, 8 August 2003 13:04 > To: PhoneNet > Cc: nznog(a)list.waikato.ac.nz > Subject: Re: [nznog] Re:Domain Name Scams > > > On Fri, 8 Aug 2003, PhoneNet wrote: > > > I have today received 5 letters from The Domain Registry > of America, > > Melbourne (posted in UK) asking me to re-register some of > my domains as > > they are due to expire - so they are at it also. > > Got one here as well, and what bothers me is that although > the domain in > question is registered under my own name, the letter was > addressed to my > company, which doesn't appear in whois data anywhere. > > Somebody's been trawling... > > -- > Juha Saarinen > _______________________________________________ > Nznog mailing list > Nznog(a)list.waikato.ac.nz > http://list.waikato.ac.nz/mailman/listinfo/nznog > _______________________________________________ > Nznog mailing list > Nznog(a)list.waikato.ac.nz > http://list.waikato.ac.nz/mailman/listinfo/nznog > DISCLAIMER: The content of this email is confidential and may contain legally privileged information intended only for the individual or entity named above. Access to this message by anyone else is unauthorised. If you are not the intended recipient, please be advised that the use, distribution and publication of the above information is prohibited. If you have received this email in error, please contact Domainz by returning the email and destroying the original. Thank you.

1 0

Info Session: Certificate In Web-based Instruction
by Abigail 08 Aug '03

08 Aug '03

On Thursday, August 14th at 1100 hrs Pacific Standard Time (GMT 08:00) there will be a Webcast featuring the instructors of the Certificate in Web-Based Instruction (CWI). Webcast participants can ask questions and interact with the instructors of this 24 week program that will be offered entirely online beginning September 15, 2003. The CWI program gives you the tools and knowledge necessary to design, develop and deliver Web-based courses or add online components to the face-to-face classroom. Please register to participate in the live Webcast by visiting http://www.sfu.ca/lidc/telestraining. If you are unable to make it to this live presentation at the above date then you can attend our next Webcast scheduled for Wednesday, September 3 at 1100 hrs PST (GMT 8:00). Abby Dy Communications Specialist Certificate in Web-Based Instruction Tel: 604-806-5156 ady(a)sfu.ca

1 0

DomainNamesNZ
by Felix Tsang 07 Aug '03

07 Aug '03

I recon their misleading letters should be taken up with the commerce commission. Felix Tsang

8 7

DomainNamesNZ
by Dominic O'Hare 07 Aug '03

07 Aug '03

The company "DomianNamesNZ" is actually "Domain Names Australia Pty Limited" a Australian based company incorporated in Victoria. They also go by "Internet Registry Pty Limited" and "NetRegister" (Not NetRegistry). The address they're using, the ASB tower in Auckland is an internet bought mail forwarding address. They have also done mail-outs and fax-outs in Australia - http://www.auda.org.au/about/news/2003061903.html One thing interesting is that they have sent letters to customers of Internet Name Group (ING) who did a similar mail-out in NZ in a while back, the letters were filled with B.S and obviously asked they register renew domains with them. Regards, Dominic

2 1

Re: [nznog] Re:Domain Name Scams
by Jamie Baddeley 07 Aug '03

07 Aug '03

got one here too. >>> Juha Saarinen <juha(a)saarinen.org> 8/8/2003 1:03:46 PM >>> On Fri, 8 Aug 2003, PhoneNet wrote: > I have today received 5 letters from The Domain Registry of America, > Melbourne (posted in UK) asking me to re-register some of my domains as > they are due to expire - so they are at it also. Got one here as well, and what bothers me is that although the domain in question is registered under my own name, the letter was addressed to my company, which doesn't appear in whois data anywhere. Somebody's been trawling... -- Juha Saarinen _______________________________________________ Nznog mailing list Nznog(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog

1 0

TelstraClear Routing?
by Steve Withers 07 Aug '03

07 Aug '03

I've been using a VPN to connect to work across the WIX for over a year - via a Paradise cable modem. I was seeing about 1mbps throughput, consistent with AT&T's Wellington Office (the actual people-at-desks office) United Networks connection to the WIX. A traceroute showed roughly 5-6 hops as I recall. Today....I can't get my VPN tunnel up at all and the traceroute shows 15 hops and my traffic is going to Auckland and off to Reach in HongKong...and then into AT&T's network there and then back again via Australia to NZ. Is anyone else seeing similar routing troubles? -- Steve Withers <swithers(a)mmp.org.nz>

2 1

OT: MP3 player
by Tim John 07 Aug '03

07 Aug '03

Hi, Sorry for the off topic posting, but during the Netforum conference last month, Domainz were selling 128Mb MP3 players for $120 (including GST) to it's participants; it was just for a bit of fun. I have a number of these little devices left - which double as pen drives - so if anyone would like one, please visit the following URL and I'll organise one to be sent out. Delivery is $7.50 (within New Zealand). https://www.domainz.net.nz/mp3/order.asp Again, sorry for taking this off topic, but wanted to wanted to offer these to all. Tim DISCLAIMER: The content of this email is confidential and may contain legally privileged information intended only for the individual or entity named above. Access to this message by anyone else is unauthorised. If you are not the intended recipient, please be advised that the use, distribution and publication of the above information is prohibited. If you have received this email in error, please contact Domainz by returning the email and destroying the original. Thank you.

1 0

Re: Nznog Digest, Vol 8, Issue 4
by Paul J 07 Aug '03

07 Aug '03

maybe try http://www.lucentdocs.com/ ? >>>>>MAX4000/6000 You'll first need to 'enable' yourself with what ever max enable password you have set on the max box. ctrl + d >P=Password >00-309 Full Access <password> ctrl + d >E=Termsrv show users kill <session ID> <<<<< >>>>>MAXTNT userstat (or users | grep <string>) users -k <session ID> <<<<< ----- Original Message ----- From: "Robert Mena" <rt_mena(a)yahoo.com> To: <nznog(a)list.waikato.ac.nz> Sent: Friday, August 08, 2003 2:22 AM Subject: [nznog] Re: Nznog Digest, Vol 8, Issue 4 > Hi Simon, > > I do live in Brazil and I was not aware that this was > a problem for the list. > > The IP you mantioned is probably the cable modem > company. > > I do not know how to get in this termserv mode. When > I need to to things I telnet to MAX, login as admin. > > I've tryed that kill with no luck. Sould I read > <something> first ? > > ------------ > Message: 2 > Date: Thu, 7 Aug 2003 13:42:20 +1200 (NZST) > From: Simon Lyall <simon.lyall(a)ihug.co.nz> > Subject: Re: [nznog] disconectin users in a MAX TNT > To: <nznog(a)list.waikato.ac.nz> > Message-ID: > > <Pine.LNX.4.30.0308071332230.19531-100000(a)boggle.ihug.co.nz> > Content-Type: TEXT/PLAIN; charset=US-ASCII > > On Wed, 6 Aug 2003, Robert Mena wrote: > > I was wondering how can I disconnect a user from a > MAX > > TNT ? > > 1. Why are you posting to nznog when you're in Brazil? > > 2. You apepar to have a slight spam problem: > > http://www.moensted.dk/spam/?addr=200.174.69.242 > > Maybe you'll be able to disconnect them now.. > > > 3. Are you useing a TNT or a MAX ? They are a little > different... > > 4. On a TNT run: > > > userstat ? > > On a Max go into Termsrv mode and run: > > % show users > % kill <session ID> > > __________________________________ > Do you Yahoo!? > Yahoo! SiteBuilder - Free, easy-to-use web site design software > http://sitebuilder.yahoo.com > _______________________________________________ > Nznog mailing list > Nznog(a)list.waikato.ac.nz > http://list.waikato.ac.nz/mailman/listinfo/nznog > Paul Joslin Systems Administrator Network Operations Center IHUG LTD, Auckland, New Zealand www.ihug.co.nz

1 0

Re: Nznog Digest, Vol 8, Issue 4
by Robert Mena 07 Aug '03

07 Aug '03

Hi Simon, I do live in Brazil and I was not aware that this was a problem for the list. The IP you mantioned is probably the cable modem company. I do not know how to get in this termserv mode. When I need to to things I telnet to MAX, login as admin. I've tryed that kill with no luck. Sould I read <something> first ? ------------ Message: 2 Date: Thu, 7 Aug 2003 13:42:20 +1200 (NZST) From: Simon Lyall <simon.lyall(a)ihug.co.nz> Subject: Re: [nznog] disconectin users in a MAX TNT To: <nznog(a)list.waikato.ac.nz> Message-ID: <Pine.LNX.4.30.0308071332230.19531-100000(a)boggle.ihug.co.nz> Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 6 Aug 2003, Robert Mena wrote: > I was wondering how can I disconnect a user from a MAX > TNT ? 1. Why are you posting to nznog when you're in Brazil? 2. You apepar to have a slight spam problem: http://www.moensted.dk/spam/?addr=200.174.69.242 Maybe you'll be able to disconnect them now.. 3. Are you useing a TNT or a MAX ? They are a little different... 4. On a TNT run: > userstat ? On a Max go into Termsrv mode and run: % show users % kill <session ID> __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com

1 0

RE: [nznog] DomainNamesNZ
by Steve Phillips 06 Aug '03

06 Aug '03

I received one of these as well requesting i register my name with a .net (not .net.nz) extension - this may produce even more issues as this would be outside the control of the DNC. the listed address is 20, 135 Albert St in Auckland - I considered wandering into town to go and LART them in person.. my domain was only registered February of this year so they have managed to get a list of .nz names after this point. -- Steve. At 14:14 7/08/2003, Tim John wrote: >This has been taken up by the DNC - check out her website for the latest >info. > >I'm not sure whether they are using an old version of the .nz zone file >(although these haven't been available for at least 18 months), or they have >some scripting engine pulling the information of the general WhoIs. This >breaches the DNC policy on use of private information for commercial gain, >yada, yada ... > >Tim

2 1

DomainNamesNZ
by Matthew G Brown 06 Aug '03

06 Aug '03

I've been getting a few good old snail mail letters from Domainnamesnz.com offering me to register domain names. Eg: I own learnbydestroying.co.nz and the "offer" is for learnbydestroying.net . How ever since these letters include; Reference #, MPID ? , Closing Date, Credit card details, and very little info to conclude that this is a Renewal many people have inadvertently paid the money ( $237 for two years ! ) thinking it's a Domainz or other registrar invoice. I'm not questioning the legality of this , as I am no expert, how ever im interested to know how so many of my clients and myself ended up with these letters? Anyone else experienced these letters or perhaps had clients pay for what they thought was a valid renewal? Best Regards Matthew G Brown Managing Director B & R Holdings LIMITED Nelson, New Zealand Ph: 027 4807731 Http://www.brh.co.nz

4 5

RE: [nznog] DomainNamesNZ
by mark.harris＠ssc.govt.nz 06 Aug '03

06 Aug '03

From: Tim John > I'm not sure whether they are using an old version of > the .nz zone file (although these haven't been available > for at least 18 months), or they have some scripting > engine pulling the information of the general WhoIs. It's not an old one and they didn't get it from Domainz. One of the domains I got a note about was only registered a few months ago via Freeparking. As an aside, this will work on some people. My wife (who is not unclueful) was opening the mail, handed me the nonvoices and said "Bills from Domainz. Do you want me to pay them online?" People will read what they think they see, no matter how much clue you throw at them. Cheers Mark Harris Senior Advisor, Portal Operations State Services Commission PO Box 329, Wellington, NZ Tel: 64 4 495 2844

1 0

RE: [nznog] DomainNamesNZ
by Paul Adshead 06 Aug '03

06 Aug '03

I have also received a .net.nz 'renewal' for each of the three .co.nz domains that I have! You have to read very carefully before you actually realise that it is a proposal rather than a renewal.. :-( Paul Adshead Network & Systems Manager OTL Software Ltd www.otl.co.nz -----Original Message----- From: Dan Clark [mailto:dan(a)scarfies.net] Sent: Thursday, 7 August 2003 14:14 To: Matthew G Brown; nznog(a)list.waikato.ac.nz Subject: Re: [nznog] DomainNamesNZ yes, we have received around 1/2 a dozen so far, some of my clients got them directly and were just going to pay it! hrmm, in reading the small print on the back it also says something about not being able to change registrar's for a whole 60 days after 'transferring to them' Regards Dan Clark Network Manager Scarfies.Net Ltd Wickliffe Ltd ----- Original Message ----- From: "Matthew G Brown" <Matt(a)Brh.Co.Nz> To: <nznog(a)list.waikato.ac.nz> Sent: Thursday, August 07, 2003 2:09 PM Subject: [nznog] DomainNamesNZ > I've been getting a few good old snail mail letters from > Domainnamesnz.com offering me to register domain names. Eg: I own > learnbydestroying.co.nz and the "offer" is for learnbydestroying.net . > How ever since these letters include; Reference #, MPID ? , Closing > Date, Credit card details, and very little info to conclude that this is > a Renewal many people have inadvertently paid the money ( $237 for two > years ! ) thinking it's a Domainz or other registrar invoice. > > I'm not questioning the legality of this , as I am no expert, how ever > im interested to know how so many of my clients and myself ended up with > these letters? Anyone else experienced these letters or perhaps had > clients pay for what they thought was a valid renewal? > > > > Best Regards > > Matthew G Brown > Managing Director > B & R Holdings LIMITED > Nelson, New Zealand > Ph: 027 4807731 > Http://www.brh.co.nz > > > _______________________________________________ > Nznog mailing list > Nznog(a)list.waikato.ac.nz > http://list.waikato.ac.nz/mailman/listinfo/nznog > _______________________________________________ Nznog mailing list Nznog(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog

1 0

disconectin users in a MAX TNT
by Robert Mena 06 Aug '03

06 Aug '03

Hi, I was wondering how can I disconnect a user from a MAX TNT ? With other RAS I could reset SXX where XX would be the session it is attached to. Unfortunately under MAX I could not find the proper command, reset, kill, drop, disconnect etc... __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com

2 1

Orcon Internet Prefix List Update (2003-08-07)
by Craig Whitmore 06 Aug '03

06 Aug '03

For all those peering with Orcon Internet (AS17746) please update your Prefix Lists/BGP to allow the Following Network (202.50.176.0/24) ip prefix-list orcon-national permit 202.50.176.0/24 Thanks Craig Whitmore Systems Administrator Orcon Internet http://www.orcon.net.nz

1 0

2500 PS
by Jon Leeman 05 Aug '03

05 Aug '03

Thanks to all that responded to Andy's plea, on my behalf, for a 2500 series power supply. I've managed to find a supplier in NZ - a list member - and it should be here in a couple of weeks. In the meantime we got the box running per the solution at http://www.hardstaff.com/Computer/Cisco/index.html and it's been working for about a week now with no apparent problems. Cheers, Jon

1 0

RE: IP to PSTN/Public network gateway.
by Gavin Legge [Invincible Technologies Limited NZ] 05 Aug '03

05 Aug '03

Thank you everyone for your comments. After a call to chch (thank's Matt) and a look at fx.net.nz i think i have all i need for now - at least a damn good start and all the right contacts. so thanks again to all. Now - how to get the normal PSTN voice calls routed back to the IP pbx/phone... hmm - time to jump into bed with a telco i think or at least connect to one .. IP/CCS7 POI/interface anyone?? lol cheers Gavin

1 0

IP to PSTN/Public network gateway.
by Gavin Legge [Invincible Technologies Limited NZ] 05 Aug '03

05 Aug '03

First question from a new list member (probably go straight to FAQ no?).... Does anyone know of a (preferably) New Zealand based provider that provides an 'IP' to 'public network' and back again gateway service (at a charge or otherwise)? Somewhere we can fire IP voice calls at, that will take the IP voice call and poke it out to the local number, local number being a normal everyday phone connected to the PSTN ? Thanks for any advice Regards Gavin Legge

1 0

Cisco 2500 power supply
by Andy Linton 04 Aug '03

04 Aug '03

Anybody got a spare 2500 power supply that Jon Leeman in Nauru can have for his 2509 dial in box? If there's a box that can be cannibalised that's fine. Include Jon on any replies if you can help. andy

1 0

Newbie with MAX : how to set up aditional pools
by Robert Mena 04 Aug '03

04 Aug '03

Hi, I am trying to configure an already running MAX TNT with TAOS 8.0.2. I need to change the current pool and add a new pool. Does anybody have a howto for that ? I've searched and downloaded the PDFs but no luck so far... Regards. __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com

2 1

RE: [nznog] 411 Scam
by Carl Black 04 Aug '03

04 Aug '03

Yes, actually - in the last month I've noticed about 4 to 5 times the amount of 411 spam I would normally expect hitting my organisation. > -----Original Message----- > From: Barry Murphy [mailto:barry(a)unix.co.nz] > Sent: Monday, August 04, 2003 10:54 PM > To: nznog(a)list.waikato.ac.nz > Subject: [nznog] 411 Scam > > > Hi, > > Just wondering if anyone else is being bombarded with 411 > scams of late. > Until a week ago I had only received maybe 6 over the year, > but over the > last 2 weeks I have received about 2-5 a day. > > Cheers > Barry > > > _______________________________________________ > Nznog mailing list > Nznog(a)list.waikato.ac.nz > http://list.waikato.ac.nz/mailman/listinfo/nznog >

1 0

411 Scam
by Barry Murphy 04 Aug '03

04 Aug '03

Hi, Just wondering if anyone else is being bombarded with 411 scams of late. Until a week ago I had only received maybe 6 over the year, but over the last 2 weeks I have received about 2-5 a day. Cheers Barry

2 1

Looking for Cisco VIP4
by Craig Whitmore 29 Jul '03

29 Jul '03

Hi folks.. I'm urgently looking for a few VIP2's or a VIP4 or above for a Cisco 7500. If anyone can help please let me know. Also if anyone has any type of IO Controller for a 7200 it would be great as well. Thanks Craig Whitmore Orcon Internet http://www.orcon.net.nz

1 1

RE: [nznog] Uniforum Meeting and Various Belated Thank-Yous
by Tim John 29 Jul '03

29 Jul '03

Hi Joe, It was a pleasure for Domainz to be able to bring you to the Conference and I'm sure your presence was appreciated by everyone. However, the least you could have done was bought an MP3 player off me ... :) Tim -----Original Message----- From: Joe Abley [mailto:jabley(a)isc.org] Sent: Tuesday, 29 July 2003 7:44 p.m. To: nznog(a)list.waikato.ac.nz Subject: [nznog] Uniforum Meeting and Various Belated Thank-Yous (warning! non-operational content. Press "d" now.) This is going to sound a little bit like a delayed reaction, but I've been travelling wildly since the meeting and hence have something of a mental meme backlog. It was very pleasant to be back putting names to faces and waving my hands in front of a whiteboard. Many thanks to Roger & Co for organising the meeting, and for inviting me to come down and speak. My travel to Auckland was paid for by Domainz -- without their funding I likely would not have been able to visit to talk at the meeting, nor turn up the F root server instance in Auckland in July (if your traceroute to f.root-servers.net currently leaves the country, feel free to contact peering(a)isc.org to set up a peering session with us in Auckland, or encourage your ISP to do the same). Direct assistance and ongoing donations of time, network, colo and equipment for the F root server were provided by Juniper, TelstraClear, Citylink, FX Networks and 2day.com, all of whom should hereby consider themselves heartily thanked. http://www.isc.org/ISC/news/pr-07232003.html Joe _______________________________________________ Nznog mailing list Nznog(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog DISCLAIMER: The content of this email is confidential and may contain legally privileged information intended only for the individual or entity named above. Access to this message by anyone else is unauthorised. If you are not the intended recipient, please be advised that the use, distribution and publication of the above information is prohibited. If you have received this email in error, please contact Domainz by returning the email and destroying the original. Thank you.

1 0

UseNet's Looking Glass...
by Dan Clark 29 Jul '03

29 Jul '03

Hi Guys, The UseNet Looking Glass http://www.usenet.net.nz/lg.cgi web server, appears to not be parsing cgi scripts? Does anyone have a traceroute looking glass, close to the APE, I could use for a minute or two please? Regards Dan Clark Network Manager Wickliffe Ltd Scarfies.Net Ltd

7 9

Uniforum Meeting and Various Belated Thank-Yous
by Joe Abley 28 Jul '03

28 Jul '03

(warning! non-operational content. Press "d" now.) This is going to sound a little bit like a delayed reaction, but I've been travelling wildly since the meeting and hence have something of a mental meme backlog. It was very pleasant to be back putting names to faces and waving my hands in front of a whiteboard. Many thanks to Roger & Co for organising the meeting, and for inviting me to come down and speak. My travel to Auckland was paid for by Domainz -- without their funding I likely would not have been able to visit to talk at the meeting, nor turn up the F root server instance in Auckland in July (if your traceroute to f.root-servers.net currently leaves the country, feel free to contact peering(a)isc.org to set up a peering session with us in Auckland, or encourage your ISP to do the same). Direct assistance and ongoing donations of time, network, colo and equipment for the F root server were provided by Juniper, TelstraClear, Citylink, FX Networks and 2day.com, all of whom should hereby consider themselves heartily thanked. http://www.isc.org/ISC/news/pr-07232003.html Joe

1 0

RE: [nznog] Staff remote access
by barry＠unix.co.nz 27 Jul '03

27 Jul '03

Sorry about that, should have been offlist. Barry ------------------------------------------------------------- This mail sent through UnixCo Webmail: http://www.unix.co.nz/

1 0

Staff remote access
by nward＠esphion.com 27 Jul '03

27 Jul '03

I currently have an IPExpress circuit from TelstraClear providing Internet access. I'd like to be able to have staff use some kind of fast IP service (ie ADSL), to connect in to the office to do thier work, I don't want Internet access over these links, just some form of nationally accessable 'VPN'. It only needs to be 1-2Mbit speed, but can't complain if its more. Is this kind of thing being done? I tried to contact Telecom about it only to have some customer support monkey tell me that ADSL is an Internet thing, and as much as I love dealing with support people... I assume many replies to this will be deemed commercial and OT, so please contact me off-list. Nathan Ward

2 1

Linux beginners training
by Jonathon Horsman 27 Jul '03

27 Jul '03

Hi all Sorry for this rather blatant advertisement, but I believe this may be of interest to some. I am running a one day Linux beginners training in Auckland this Saturday (2nd of August). Details can be found here: http://www.59uptime.com/training.html Please email me if you're interested in attending. Thanks very much Jonathon

1 0

Notification: Disable Seconday Public (Stratum 2) NTP Service
by Kim Shepherd 24 Jul '03

24 Jul '03

The University of Waikato will cease to provide public stratum 2 NTP service as of 31st July, 2003. A list of alternative stratum 2 servers is available at the URL below: http://www.eecis.udel.edu/~mills/ntp/clock2a.html Regards, Kim. -- Kim Shepherd Systems Operator/Administrator ITS Systems & Development The University of Waikato, Hamilton, New Zealand DDI: +64-7-838-4681 Mob: +64-25-240-8682 Mail: kims(a)waikato.ac.nz

1 0

Fwd: 100,000 Reasons ...
by barry＠unix.co.nz 23 Jul '03

23 Jul '03

Anyone else receiving spam which "is not part of a mass mailout" ? They even fail to refer to which domain I should keep with domainz, as far as I know I have moved my domains over to orcon almost a month ago. Barry ----- Forwarded message from Domainz(a)domainz.net.nz ----- Date: Mon, 21 Jul 2003 11:39:53 +1200 From: Domainz(a)domainz.net.nz Reply-To: Domainz(a)domainz.net.nz Subject: 100,000 Reasons ... To: blacklabel(a)orcon.net.nz This email has been sent directly to 'blacklabel(a)orcon.net.nz' and is not part of a mass mailout. ----- <http://www.domainz.net.nz> <http://www.domainz.net.nz> <http://www.domainz.net.nz/> <http://www.domainz.net.nz> You now have a choice of registrars to manage your domain name requirements. At Domainz, we've registered more than 100,000 .nz domain names over the past six years, making us the specialists. So while you now have a choice, we think it's best exercised by doing nothing! That way you can ensure Domainz remains your registrar. Why stay with Domainz? Because your domain name is a valuable asset that needs to be properly protected and managed. We're New Zealand's most experienced and expert domain name registrar - and that makes us the people you should rely on for top service and best value for money. Domain names are our speciality! What else do I get by doing nothing? We are now able to offer you other services alongside your domain name registration. Right now, you can have: * Domain name parking - domain name reservation *FREE* * Website redirection - redirection of your website traffic so you can have it managed wherever you want *FREE* * Email forwarding - we can redirect your email to wherever you want *FREE* * Email hosting - we'll manage your whole email system using our facilities * Web hosting - we'll do the same with your website Domainz offers all of our services in a range of packages designed to fit the differing requirements of our customers. What will I miss if I act now? Remember, there's no need to do anything - and we strongly advise that you don't! Very soon we'll be offering a range of new products and services, including: * More billing and payment options - including variable registration periods for domain names * Registration of international domain names - such as .com, .net and .ws But if I need to know more! If you would simply like to discuss your domain name needs or find out more information, then email us by clicking here <mailto:4service(a)domainz.net.nz?subject=Information Please> . You can also ring us on 0800 366 2469 or visit our website, www.domainz.net.nz <http://www.domainz.net.nz/> . We'd like to join you in doing nothing... but we're busy. Because we value your business, doing nothing isn't an option for us. We're busy working on new and better ways to make managing your domain name easier and more cost effective! Thanks for registering your domain name with us. We intend to keep making it worth your while - to do nothing at all. Derek Locke and the team at Domainz To unsubscribe from future emails of this nature from Domainz, click here <mailto:noemail(a)domainz.net.nz?subject=Email Unsubscribe - '61717200'> . ----- End forwarded message ----- ------------------------------------------------- This mail sent through IMP: http://horde.org/imp/

10 9

Re: [nznog] Mae-West Looking Glass
by Jamie Baddeley 21 Jul '03

21 Jul '03

MIA. Last seen in action september 2002. http://web.archive.org/web/*/http://nitrous.digex.net probably assimilated by the borg. jamie >>> "Mark Frater" <mfrater(a)quicksilver.co.nz> 07/21 12:37 PM >>> What ever happened to nitrous.digex.net? Mark _______________________________________________ Nznog mailing list Nznog(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog

3 2

Mae-West Looking Glass
by Mark Frater 20 Jul '03

20 Jul '03

What ever happened to nitrous.digex.net? Mark

2 1

Performance issues on Citylink yesterday (Saturday Jul 19)
by Simon Blake 19 Jul '03

19 Jul '03

Our apologies to the folks who suffered from performance problems on Citylink yesterday (Saturday). They were caused by an ISP under apparent SYN attack - not in itself a particularly unusual occurence, what was interesting was that in changes on Saturday morning (about 3am) said ISP managed to make the IP address under attack an unfiltered broadcast address on Citylink, so we all got to share the pain of a kind of combo SYN/smurf attack. The attacks manifested as 8-10Mb/s streams coming from the ISP onto Citylink for 1-4 minutes, about twice every two hours, which in turn caused some 10Mb customers on Citylink some disruption of service - 100Mb/1Gb customers seemed to be largely unaffected. The short duration and occasional nature of the problem did cause a few issues with tracking it and getting a resolution (about 9pm last night) - again, our apologies for not getting it sorted faster. Cheers Si

1 0

exploits logged in Auckland
by Joe Abley 18 Jul '03

18 Jul '03

I have seen attempts to exploit the recently-announced cisco vuln on a router of my acquaintance in Auckland, starting early this morning NZST. This confirms the notes on nanog (and in the updated cisco advisory) about functional exploits being published and used in the wild. The source addresses appear spoofed, and so far all of the hits have been received from outside NZ. The address "x.x.x.114" (see below) isn't in use on a router or anywhere else. Presumably the k1dd13z will realise at some point that there is more dead air on the Internet than ciscos, and will start harvesting victim addresses from traceroute instead of choosing them randomly. Is anybody contemplating customer-facing filters which block protocols 53, 54, 77 and 103? Jul 19 01:26:52 router 3587: Jul 19 01:22:37 NZST: %SEC-6-IPACCESSLOGNP: list 127 denied 54 216.191.222.139 (FastEthernet0/1.500 0002.xxxx.xxxx) -> x.x.x.164, 1 packet Jul 19 01:38:27 router 5320: Jul 19 01:34:12 NZST: %SEC-6-IPACCESSLOGNP: list 127 denied 53 245.128.83.9 (Serial2/2.1 DLCI xxx) -> x.x.x.114, 1 packet Jul 19 01:38:27 router 5321: Jul 19 01:34:13 NZST: %SEC-6-IPACCESSLOGRP: list 127 denied pim 216.225.202.10 (Serial2/2.1 DLCI xxx) -> x.x.x.114, 1 packet Jul 19 01:41:38 router 5327: .Jul 19 01:37:23 NZST: %SEC-6-IPACCESSLOGNP: list 127 denied 77 157.160.104.37 (Serial2/2.1 DLCI xxx) -> x.x.x.114, 1 packet Jul 19 01:42:02 router 5331: .Jul 19 01:37:47 NZST: %SEC-6-IPACCESSLOGNP: list 127 denied 55 222.21.158.112 (Serial2/2.1 DLCI xxx) -> x.x.x.114, 1 packet Jul 19 01:46:06 router 5343: .Jul 19 01:41:51 NZST: %SEC-6-IPACCESSLOGNP: list 127 denied 55 221.44.200.77 (Serial2/2.1 DLCI xxx) -> x.x.x.114, 1 packet Jul 19 01:46:06 router 5344: .Jul 19 01:41:51 NZST: %SEC-6-IPACCESSLOGRP: list 127 denied pim 148.246.222.60 (Serial2/2.1 DLCI xxx) -> x.x.x.114, 1 packet Jul 19 01:48:25 router 5347: .Jul 19 01:44:10 NZST: %SEC-6-IPACCESSLOGNP: list 127 denied 55 159.136.236.96 (Serial2/2.1 DLCI xxx) -> x.x.x.114, 1 packet Jul 19 01:48:25 router 5348: .Jul 19 01:44:10 NZST: %SEC-6-IPACCESSLOGRP: list 127 denied pim 151.142.170.98 (Serial2/2.1 DLCI xxx) -> x.x.x.114, 1 packet Jul 19 01:51:02 router 5353: Jul 19 01:46:48 NZST: %SEC-6-IPACCESSLOGNP: list 127 denied 53 172.75.88.52 (Serial2/2.1 DLCI xxx) -> x.x.x.114, 1 packet Jul 19 01:51:02 router 5354: Jul 19 01:46:48 NZST: %SEC-6-IPACCESSLOGRP: list 127 denied pim 146.95.71.5 (Serial2/2.1 DLCI xxx) -> x.x.x.114, 1 packet Jul 19 01:52:17 router 5359: Jul 19 01:48:02 NZST: %SEC-6-IPACCESSLOGNP: list 127 denied 53 252.40.243.114 (Serial2/2.1 DLCI xxx) -> x.x.x.114, 1 packet Jul 19 01:52:17 router 5360: Jul 19 01:48:02 NZST: %SEC-6-IPACCESSLOGRP: list 127 denied pim 151.94.44.88 (Serial2/2.1 DLCI xxx) -> x.x.x.114, 1 packet Jul 19 01:52:35 router 5362: Jul 19 01:48:20 NZST: %SEC-6-IPACCESSLOGNP: list 127 denied 53 24.17.251.39 (Serial2/2.1 DLCI xxx) -> x.x.x.114, 1 packet

1 0

Cisco Security Advisory: Cisco IOS Interface Blocked by IPv4 Packet
by Rob Thomas 17 Jul '03

17 Jul '03

FYI. -- Rob Thomas http://www.cymru.com ASSERT(coffee != empty); -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Cisco Security Advisory: Cisco IOS Interface Blocked by IPv4 Packet Revision 1.3 ============ Last Updated 2003 July 17 at 23:00 UTC (GMT) For Public Release 2003 July 17 at 6:10 UTC (GMT) ================= - ---------------------------------------------------------------------- Please provide your feedback on this document. - ---------------------------------------------------------------------- Contents ======== Summary Affected Products Details Impact Software Versions and Fixes Obtaining Fixed Software Workarounds Exploitation and Public Announcements Status of This Notice: INTERIM Distribution Revision History Cisco Security Procedures - ---------------------------------------------------------------------- Summary ======= Cisco routers and switches running Cisco IOS� software and configured to process Internet Protocol version 4 (IPv4) packets are vulnerable to a Denial of Service (DoS) attack. A rare sequence of crafted IPv4 packets with specific protocol fields sent directly to the device may cause the input interface to stop processing traffic once the input queue is full. No authentication is required to process the inbound packet. Processing of IPv4 packets is enabled by default. Devices running only IP version 6 (IPv6) are not affected. A workaround is available. Cisco has made software available, free of charge, to correct the problem. This advisory is available at http://www.cisco.com/warp/public/707/cisco-sa-20030717-blocked.shtml. Affected Products ================= This issue affects all Cisco devices running Cisco IOS software and configured to process Internet Protocol version 4 (IPv4) packets. Cisco devices which do not run Cisco IOS software are not affected. Devices which run only Internet Protocol version 6 (IPv6) are not affected. Details ======= Cisco routers are configured to process and accept Internet Protocol version 4 (IPv4) packets by default. A rare, specially crafted sequence of IPv4 packets with protocol type 53 (SWIPE), 55 (IP Mobility), 77 (Sun ND), or 103 (Protocol Independent Multicast - PIM) which is handled by the processor on a Cisco IOS device may force the device to incorrectly flag the input queue on an interface as full, which will cause the router to stop processing inbound traffic on that interface. This can cause routing protocols to drop due to dead timers. Interfaces which are explicitly configured to run PIM will not be affected by traffic with protocol type 103. An interface with PIM enabled will have one of the following three commands in the interface configuration: ip pim dense-mode, ip pim sparse-mode, or ip pim sparse-dense-mode. On Ethernet interfaces, Address Resolution Protocol (ARP) times out after a default time of four hours, and no traffic can be processed. The device must be rebooted to clear the input queue on the interface, and will not reload without user intervention. The attack may be repeated on all interfaces causing the router to be remotely inaccessible. A workaround is available, and is documented in the Workarounds section. The following two Cisco vulnerabilities are documented in DDTS: CSCea02355 ( registered customers only) affects all Cisco routers running Cisco IOS software. This documents the flaw with protocols 53, 55, and 77. CSCdz71127 ( registered customers only) was introduced by an earlier code revision, and documents an input queue vulnerability to protocol 103 with a device which is not configured for PIM. Any version of software which has the fix for CSCdx02283 ( registered customers only) is vulnerable. Registered customers can find more details using the Bug Toolkit at http://www.cisco.com/cgi-bin/Support/Bugtool/launch_bugtool.pl ( registered customers only) . To identify a blocked input interface, use the show interfaces command and look for the Input Queue line. If the current size (in this case, 76) is larger than the maximum size (75), the input queue is blocked. Use the show buffers command and look for the prot field. Below are two examples: Router#show interface ethernet 0/0 Ethernet0/0 is up, line protocol is up Hardware is AmdP2, address is 0050.500e.f1e0 (bia 0050.500e.f1e0) Internet address is 172.16.1.9/24 MTU 1500 bytes, BW 10000 Kbit, DLY 1000 usec, rely 255/255, load 1/255 Encapsulation ARPA, loopback not set, keepalive set (10 sec) ARP type: ARPA, ARP Timeout 04:00:00 Last input 00:00:41, output 00:00:07, output hang never Last clearing of "show interface" counters 00:07:18 Input queue: 76/75/1091/0 (size/max/drops/flushes); Total output drops: 0 !--- The 76/75 shows that this is blocked Router#show buffers input-interface serial 0/0 Buffer information for Small buffer at 0x612EAF3C data_area 0x7896E84, refcount 1, next 0x0, flags 0x0 linktype 7 (IP), enctype 0 (None), encsize 46, rxtype 0 if_input 0x6159D340 (FastEthernet3/2), if_output 0x0 (None) inputtime 0x0, outputtime 0x0, oqnumber 65535 datagramstart 0x7896ED8, datagramsize 728, maximum size 65436 mac_start 0x7896ED8, addr_start 0x7896ED8, info_start 0x0 network_start 0x7896ED8, transport_start 0x0 source: 212.176.72.138, destination: 212.111.64.174, id: 0xAAB8, ttl: 41, prot: 103 !--- prot: 103 is proof that this is one of the attack packets Impact ====== A device receiving these specifically crafted IPv4 packets will force the inbound interface to stop processing traffic. The device may stop processing packets destined to the router, including routing protocol packets and ARP packets. No alarms will be triggered, nor will the router reload to correct itself. This issue can affect all Cisco devices running Cisco IOS software. This vulnerability may be exercised repeatedly resulting in loss of availability until a workaround has been applied or the device has been upgraded to a fixed version of code. Software Versions and Fixes =========================== Each row of the table describes a release train and the platforms or products for which it is intended. If a given release train is vulnerable, then the earliest possible releases that contain the fix and the anticipated date of availability for each are listed in the Rebuild, Interim, and Maintenance columns. In some cases, no rebuild of a particular release is planned; this is marked with the label "Not scheduled." A device running any release in the given train that is earlier than the release in a specific column (less than the earliest fixed release) is known to be vulnerable, and it should be upgraded at least to the indicated release or a later version (greater than the earliest fixed release label). When selecting a release, keep in mind the following definitions: * Maintenance Most heavily tested and highly recommended release of any label in a given row of the table. * Rebuild Constructed from the previous maintenance or major release in the same train, it contains the fix for a specific vulnerability. Although it receives less testing, it contains only the minimal changes necessary to effect the repair. Cisco has made available several rebuilds of mainline trains to address this vulnerability, but strongly recommends running only the latest maintenance release on mainline trains. * Interim Built at regular intervals between maintenance releases and receives less testing. Interims should be selected only if there is no other suitable release that addresses the vulnerability, and interim images should be upgraded to the next available maintenance release as soon as possible. Interim releases are not available through manufacturing, and usually they are not available for customer download from CCO without prior arrangement with the Cisco Technical Assistance Center (TAC). 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 TAC for assistance, as shown in the section following this table. +--------------------------------------------------------------------+ |Train |Description of |Availability of Fixed Releases | | |Image or Platform | | |--------------------------+-----------------------------------------+ | 11.x based releases | Rebuild |Interim| Maintenance | |--------------------------+-----------+-------+---------------------+ |11.1CA| |11.1(36)CA4| | | | | |** | | | |------+-------------------+-----------+-------+---------------------+ |11.2 | |11.2(26e)**| | | |------+-------------------+-----------+-------+---------------------+ |11.2P | |11.2(26)P5*| | | | | |* | | | |------+-------------------+-----------------------------------------+ |11.3 | |Not scheduled | |------+-------------------+-----------------------------------------+ |11.3T | |Not scheduled | |--------------------------+-----------------------------------------+ |12.0 based releases |Rebuild |Interim|Maintenance | |--------------------------+-----------+-------+---------------------+ | |General Deployment | | | | |12.0 |release for all | | |12.0(26) | | |platforms | | | | |------+-------------------+-----------------------------------------+ |12.0DA|xDSL support: 6100,|Migrate to 12.2DA; 12.2(10)DA2 - | | |6200 |Aug-15-2003, 12.2(12)DA3 - Aug-22-2003: | | | |Engineering Specials available on | | | |request. | |------+-------------------+-----------------------------------------+ |12.0DB|Early Deployment |Migrate to 12.3(1a) | | |6400 UAC for NSP | | |------+-------------------+-----------------------------------------+ |12.0DC|Early Deployment |Migrate to 12.3(1a) | | |6400 UAC for NRP | | |------+-------------------+-----------------------------------------+ | | |12.0(24)S2 | | | | | |12.0(23)S3 | | | | | |12.0(22)S5 | | | | | |12.0(21)S7 | | | | | |12.0(19)S4 | | | | |Core/ISP support: |12.0(18)S7 | | | |12.0S |GSR, RSP, c7200, |12.0(17)S7 | |12.0(25)S | | |c10k |12.0(16)S10| | | | | |12.0(15)S7 | | | | | |12.0(14)S8 | | | | | |12.0(13)S8 | | | | | |12.0(12)S4 | | | | | |12.0(10)S8 | | | |------+-------------------+-----------------------------------------+ |12.0SC|Cable/broadband |Migrate to 12.1(19)EC | | |ISP: ubr7200 | | |------+-------------------+-----------------------------------------+ |12.0SL|100000 ESR:c10k |Migrate to 12.0(23)S3, **12.0(17)SL9 - | | | |Jul-15-2003 | |------+-------------------+-----------------------------------------+ |12.0SP|Early Deployment |Migrate to 12.0(22)S5 | |------+-------------------+-----------------------------------------+ | |Early Deployment |12.0(21)ST7| | | |12.0ST|release for Core/ |12.0(20)ST6| | | | |ISP support: GSR, |12.0(19)ST6| | | | |RSP, c7200 |12.0(17)ST8| | | |------+-------------------+-----------------------------------------+ |12.0SX|Early Deployment |Migrate to 12.0(22)S5 | |------+-------------------+-----------------------------------------+ |12.0SY|Early Deployment |Migrate to 12.0(23)S3 | |------+-------------------+-----------------------------------------+ |12.0SZ|Early Deployment |Migrate to 12.0(23)S3 | |------+-------------------+-----------------------------------------+ |12.0T |Early Deployment |12.0(7)T3**| | | |------+-------------------+-----------+-------+---------------------+ | |8510c, ls1010, | | |12.0(26)W5(28) | | |cat8540c,cat8540m, | | | | | |ls1010 | | | | | |-------------------+-----------+-------+---------------------+ | |c5atm |12.0(26)W5 | | | | | |(28a) | | | | |-------------------+-----------+-------+---------------------+ | |Cat4232 and |12.0(25)W5 | | | |12.0W5|Cat2948G-L3 |(27) | | | | |-------------------+-----------+-------+---------------------+ | |C6MSM |Engineering| | | | | |Special | | | | | |available | | | | | |on request | | | | |-------------------+-----------+-------+---------------------+ | |c5rsfc,c5rsm,C3620,| | |12.1(20) | | |C3640, C4500, | | | | | |C7200, RSP | | | | |------+-------------------+-----------+-------+---------------------+ |12.0WC|Early deployment |12.0(05)WC8| | | | |2900XL-LRE,2900XL/ | | | | | |3500XL; 2950 | | | | | |release | | | | |------+-------------------+-----------+-------+---------------------+ |12.0WT|Early deployment |Engineering| | | | |Catalyst switches: |Special | | | | |cat4840g, |Available | | | | | |upon | | | | | |request | | | |------+-------------------+-----------------------------------------+ |12.0X |Shortlived Early |All 12.0X(any letter) releases have | |(l) |Deployment Releases|migrated to either 12.0T or 12.1 unless | | | |otherwise documented in the X release | | | |technical notes pertaining to the | | | |specific release. Please check migration | | | |paths for all 12.0X releases. | |--------------------------+-----------------------------------------+ |12.1 based releases |Rebuild |Interim|Maintenance | |--------------------------+-----------+-------+---------------------+ | |General Deployment | |12.1 | | |12.1 |release for all | |(18.4) |12.1(19) | | |platforms | | | | |------+-------------------+-----------------------------------------+ |12.1AA| |Migrate to 12.2 | |------+-------------------+-----------------------------------------+ |12.1AX|Catalyst 3750 |12.1(14)EA1| | | | | |- | | | | | |Engineering| | | | | |special | | | | | |available | | | | | |upon | | | | | |request | | | |------+-------------------+-----------+-------+---------------------+ |12.1AY|Catalyst 2940 | | |12.1(13)AY | |------+-------------------+-----------------------------------------+ |12.1DA|6160 platform |Migrate to 12.2DA | |------+-------------------+-----------------------------------------+ |12.1DB|6400 UAC |Migrate to 12.3(1a) | |------+-------------------+-----------------------------------------+ |12.1DC|6400 UAC |Migrate to 12.3(1a) | |------+-------------------+-----------------------------------------+ |12.1E |Core Enterprise |12.1(8b)E14| |12.1(19)E | | |support - c7200, |12.1(13)E7 | | | | |Catalyst 6000, RSP |12.1(14)E4 | | | | | |**12.1(12c)| | | | | |E7 | | | | | |12.1(11b) | | | | | |E12- | | | | | |Aug-4-2003 | | | | | |12.1(6)E12 | | | |------+-------------------+-----------------------------------------+ |12.1EA|12.1(4)EA |Migrate to 12.1(13)EA1c | | |12.1(6)EA | | | |12.1(8)EA | | | |12.1(9)EA | | | |12.1(11)EA | | | |-------------------+-----------------------------------------+ | |12.1(12c)EA |12.1(13) | | | | |12.1(13)EA |EA1c | | | |------+-------------------+-----------+-------+---------------------+ |12.1EB|LS1010 | | |12.1(14)EB | |------+-------------------+-----------+-------+---------------------+ |12.1EC|Early Deployment | | |12.1(19)EC (scheduled| | | | | |last week of July) | |------+-------------------+-----------+-------+---------------------+ |12.1EV|Early Deployment | | |12.1(12c)EV | |------+-------------------+-----------+-------+---------------------+ |12.1EW|Early Deployment | | |12.1(13)EW,12.1(19)EW| | |Cat4000 L3 | | | | |------+-------------------+-----------+-------+---------------------+ |12.1EX|Early deployment |12.1(13)EX2| | | |------+-------------------+-----------+-------+---------------------+ |12.1EY| | |12.1(14)E4 | | | |------+---------+---------+-----------+-------+---------------------+ | | | |12.1(14)EA1| | | |12.1YJ| | |- | | | | | | |Jul-28-2003| | | |------+-------------------+-----------+-------+---------------------+ |12.1T |Early deployment |12.1(5)T15*| | | | | |* | | | |------+-------------------------------------------------------------+ |12.1X |12.1X releases generally migrate to 12.1T, 12.2 or 12.2T as | |(l) |specified below. Please refer to specific train Technical | | |notes for documented migration path. | |------+-------------------------------------------------------------+ |12.1XA|Short lived Early |Migrate to 12.1(5)T15 | | |Deployment Release | | |------+-------------------+-----------------------------------------+ |12.1XC|Short lived Early |Migrate to12.2(17) | |12.1XD|Deployment Releases| | |12.1XH| | | |12.1XI| | | |------+-------------------+-----------------------------------------+ |12.1XB|Short lived Early |Migrate to 12.2(15)T5 | |12.1XF|Deployment Releases| | |12.1XG| | | |12.1XJ| | | |12.1XL| | | |12.1XP| | | |12.1XR| | | |12.1XT| | | |12.1YB| | | |12.1YC| | | |12.1YD| | | |12.1YH| | | |------+-------------------+-----------------------------------------+ |12.1XM|Short lived Early |Migrate to 12.2(2)XB11 | |12.1XQ|Deployment Releases| | |12.1XV| | | |------+-------------------+-----------------------------------------+ |12.1XU|Short lived Early |Migrate to 12.2(4)T6 | | |Deployment Release | | |------+-------------------+-----------------------------------------+ |12.1YE|Short lived Early |Migrate to 12.2(2)YC | |12.1YF|Deployment Release | | |12.1YI| | | |--------------------------+-----------------------------------------+ |12.2 based releases |Rebuild |Interim|Maintenance | |--------------------------+-----------+-------+---------------------+ | |General Deployment |12.2(16a) | | | |12.2 |(GD) candidate for |12.2(12e) | |12.2(17) | | |all platforms |12.2(10d) | | | |------+-------------------+-----------+-------+---------------------+ |12.2B |12.2(2)B-12.2(4)B7 |12.3(1a) | | | | |-------------------+-----------+-------+---------------------+ | |12.2(4)B8-12.2(16)B|12.2(16)B1 | | | |------+-------------------+-----------+-------+---------------------+ |12.2BC|Early Deployment |12.2(15)BC1| | | | |Release |(Scheduled | | | | | |end of | | | | | |July) | | | |------+-------------------+-----------+-------+---------------------+ |12.2BW|Early Deployment |Migrate to | | | | |for use with 7200, |12.3(1a) | | | | |7400, and 7411 | | | | | |platforms | | | | |------+-------------------+-----------+-------+---------------------+ |12.2BX|Broadband/Leased | | |12.2(16)BX | | |line | | | | |------+-------------------+-----------+-------+---------------------+ |12.2BZ|Early Deployment |12.2(15)BZ1| | | | |Release | | | | |------+-------------------+-----------------------------------------+ |12.2CX|Early Deployment |Migrate to 12.1(15)BC1 | | |Release | | |------+-------------------+-----------------------------------------+ |12.2CY|Early Deployment |Migrate to 12.1(15)BC1 | | |Release | | |------+-------------------+-----------------------------------------+ |12.2DA|Early Deployment |12.2(10)DA2| | | | |Release |- | | | | | |Jul-15-2003| | | | | |12.2(12)DA3| | | | | |- | | | | | |Aug-22-2003| | | | | |Enginering | | | | | |Special | | | | | |available | | | | | |on request | | | |------+-------------------+-----------------------------------------+ |12.2DD|Early Deployment |Migrate to 12.3(1a) | | |Release | | |------+-------------------+-----------------------------------------+ |12.2DX|Early Deployment |Migrate to 12.3(1a) | | |Release | | |------+-------------------+-----------------------------------------+ |12.2JA|Cisco Aironet | | |12.2(11)JA | | |hardware platforms:| | | | | |Introduction of | | | | | |Access Point | | | | | |feature in IOS, | | | | | |Cisco 1100 Series | | | | | |Access Point | | | | | |(802.11b) | | | | |------+-------------------+-----------+-------+---------------------+ |12.2MB|Specific Technology|12.2(4)MB12| | | | |ED for 2600 7500 | | | | | |(GPRS/PDSN/GGSN | | | | | |2600/7200/7500) | | | | |------+-------------------+-----------+-------+---------------------+ |12.2MC|Early Deployment: |12.2(13)MC1| | | | |IP RAN |CCO: 7/24/ | | | | | |03 | | | |------+-------------------+-----------+-------+---------------------+ |12.2MX| |12.2(8)YD | | | | | | | | | |------+-------------------+-----------+-------+---------------------+ |12.2S |Core/ISP support: |12.2(14)S1 |12.2 | | | |GSR, RSP, c7200 | |(16.5)S| | |------+-------------------+-----------+-------+---------------------+ |12.2SX|IOS Support for |12.2(14)SX1| | | | |C6500 Supervisor 3 | | | | |------+-------------------+-----------+-------+---------------------+ |12.2SY|VPN feature release|12.2(14) | | | | |for c6k/76xx VPN |SY1, 12.2 | | | | |service module. |(8)YD | | | |------+-------------------+-----------+-------+---------------------+ |12.2SZ|7304 Platform |12.2(14)SZ2| | | |------+-------------------+-----------+-------+---------------------+ | | |12.2(15)T4/| |No more maintenance | | |New Technology |5,12.2(13) | |trains for 12.2T are | | |Early Deployment |T5, |12.2 |planned, please | |12.2T |(ED) release for |12.2(11) |(16.5)T|migrate to latest | | |all platforms |T9,12.2(8) | |12.3 Mainline | | | |T10, | |release. | | | |12.2(4)T6 | | | |------+-------------------+-----------------------------------------+ |12.2X |Short lived Early |Many short lived releases migrate to the | |(l) |Deployment Releases|same train; the trains below this point | |12.2Y |- |until the following section are not | |(l) | |grouped by strict alphabetical order, but| | | |are grouped by migration path. Please | | | |review documented migration paths for | | | |your trains. | |------+-------------------+-----------------------------------------+ |12.2XA|Short lived Early |Migrate to 12.2(11)T9 | | |Deployment Releases| | |------+-------------------+-----------------------------------------+ |12.2XS| |12.2(2)XB11 | |------+-------------------+-----------------------------------------+ |12.2XD|Short lived Early |Migrate to 12.2(15)T5 | |12.2XE|Deployment Releases| | |12.2XH| | | |12.2XI| | | |12.2XJ| | | |12.2XK| | | |12.2XL| | | |12.2XM| | | |12.2XQ| | | |12.2XU| | | |12.2XW| | | |12.2YA| | | |12.2YB| | | |12.2YC| | | |12.2YF| | | |12.2YG| | | |12.2YH| | | |12.2YJ| | | |12.2YT| | | |------+-------------------+-----------------------------------------+ |12.2YN|Short lived Early |Migrate to 12.2(13)ZH | | |Deployment Releases| | |------+-------------------+-----------------------------------------+ | |Short lived Early |Migrate to 12.2(14)SY1 available | |12.2YO|Deployment Releases|Aug-4-2003: Engineering Special | | | |available on request | |------+-------------------+-----------------------------------------+ | |Early Deployment | | | | |12.2XB|Release with |12.2(2)XB11| | | | |continuing support | | | | |------+-------------------+-----------------------------------------+ |12.2XC|Short lived Early |Migrate to 12.2(16)B1 | | |Deployment Releases| | |------+-------------------+-----------------------------------------+ |12.2XF|Short lived Early |Migrate to 12.2(15)BC1 | | |Deployment Release | | | |UBR10000 | | |------+-------------------+-----------------------------------------+ |12.2XG|Short lived Early |Migrate to 12.2(8)T10 | | |Deployment Release | | |------+-------------------+-----------------------------------------+ |12.2XN|Short lived Early |Migrate to 12.2(11)T9 | |12.2XT|Deployment Releases| | |------+-------------------+-----------------------------------------+ |12.2YD|Short lived Early |Migrate to 12.2(8)YY | | |Deployment Release | | |------+-------------------+-----------------------------------------+ |12.2YP|Short lived Early |**12.2(11) | | | | |Deployment Release |YP1 | | | |------+-------------------+-----------------------------------------+ |12.2YK| |Migrate to 12.2(13)ZC | |------+-------------------+-----------------------------------------+ |12.2YL|Short lived Early |Migrate to 12.2(13)ZH | |12.2YM|Deployment Releases| | |12.2YU| | | |12.2YV| | | |------+-------------------+-----------------------------------------+ |12.2YQ|Short lived Early |Migrate to 12.2(15)ZL | |12.2YR|Deployment Releases| | |------+-------------------+-----------------------------------------+ |12.2YS|Short lived Early |12.2(15)YS/| | | | |Deployment Release |1.2(1) | | | |------+-------------------+-----------+-------+---------------------+ |12.2YW|Short lived Early |12.2(8)YW2 | | | | |Deployment Releases| | | | |------+-------------------+-----------+-------+---------------------+ |12.2YX|Short lived Early |12.2(11)YX1| | | | |Deployment Release | | | | | |Crypto for 7100/ | | | | | |7200 | | | | |------+-------------------+-----------+-------+---------------------+ |12.2YY|Short lived Early |12.2(8)YY3 | | | | |Deployment Releases| | | | | |IOS support for | | | | | |General Packet | | | | | |Radio Service | | | | |------+-------------------+-----------+-------+---------------------+ |12.2YZ|Short lived Early |12.2(11)YZ2| | | | |Deployment Release | | | | |------+-------------------+-----------+-------+---------------------+ |12.2ZA|Short lived Early | | |12.2(14)ZA2 | | |Deployment Release | | | | |------+-------------------+-----------+-------+---------------------+ |12.2ZB|Short lived Early |12.2(8)ZB7 | | | | |Deployment Release | | | | |------+-------------------+-----------+-------+---------------------+ |12.2ZC|Short lived Early | | |12.2(13)ZC | | |Deployment Release | | | | |------+-------------------+-----------+-------+---------------------+ |12.2ZD|Short lived Early |Not | | | | |Deployment Release |Scheduled | | | |------+-------------------+-----------+-------+---------------------+ |12.2ZE|Short lived Early |12.3(1a) | | | | |Deployment Release | | | | |------+-------------------+-----------+-------+---------------------+ |12.2ZF|Short lived Early |Not | | | | |Deployment Release |Vulnerable | | | |------+-------------------+-----------+-------+---------------------+ |12.2ZG|Short lived Early |Not | | | | |Deployment Release |Vulnerable | | | |------+-------------------+-----------+-------+---------------------+ |12.2ZH|Short lived Early |Not | | | | |Deployment Release |Vulnerable | | | |------+-------------------+-----------+-------+---------------------+ |12.2ZJ|Short lived Early |12.2(15)ZJ1| | | | |Deployment Release | | | | |------+-------------------+-----------+-------+---------------------+ |12.2ZL|Short lived Early |Not | | | | |Deployment Release |Vulnerable | | | |--------------------------+-----------------------------------------+ |12.3 based releases |NOT VULNERABLE | |--------------------------------------------------------------------+ |Notes: **Marked versions of code are not available on CCO. Please | |contact TAC and request the specific images you need posted. | +--------------------------------------------------------------------+ Notes: ** Marked versions of code are not available on CCO. Please contact the Cisco TAC and request the specific images you need posted. Obtaining Fixed Software ======================== Customers with contracts should obtain upgraded software free of charge through their regular update channels. For most customers, this means that upgrades should be obtained through the Software Center on the Cisco worldwide website at http://www.cisco.com/tacpage/sw-center/sw-ios.shtml. Customers whose Cisco products are provided or maintained through prior or existing agreement with third-party support organizations such as Cisco Partners, authorized resellers, or service providers should contact that support organization for assistance with obtaining the free software upgrade(s). Customers who purchase direct from Cisco but who do not hold a Cisco service contract and customers who purchase through third-party vendors but are unsuccessful at obtaining fixed software through their point of sale should get their 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(a)cisco.com Please have your product serial number available and give the URL of this notice as evidence of your entitlement to a free upgrade. Free upgrades for non-contract customers must be requested through the TAC. Please do not contact either "psirt(a)cisco.com" or "security-alert(a)cisco.com" for software upgrades. See http://www.cisco.com/warp/public/687/Directory/DirTAC.shtml for additional TAC contact information, including special localized telephone numbers, instructions, and e-mail addresses for use in various languages. Workarounds =========== AFTER APPLYING THE WORKAROUND the input queue depth may be raised with the hold-queue <new value> in interface command -- the default size is 75. This will allow traffic flow on the interface until the device can be reloaded. Cisco recommends that all IOS devices which process IPv4 packets be configured to block traffic directed to the router from any unauthorized source with the use of Access Control Lists (ACLs). This can be done at multiple locations, and it is recommended that you review all methods and use the combination which fits your network best. Legitimate traffic is defined as management protocols such as telnet, snmp or ssh, and configured routing protocols from explicitly allowed peers. All other traffic destined to the device should be blocked at the input interface. Traffic entering the network should also be carefully evaluated and filtered at the network edge if destined to an infrastructure device. Although network service providers must often allow unknown traffic to transit their network, it is not necessary to allow that same traffic destined to their network infrastructure. Several white papers have been written to assist in deploying these recommended security best practices. ACLs can have performance impact on certain platforms, so care should be taken when applying the recommended workarounds. Transit ACLs The following access list is specifically designed to block attack traffic. Note that the attack traffic can include spoofed source addresses. This access list should be applied to all interfaces of the device, and should include topology-specific filters. This could include filtering routing protocol traffic, management protocols, and traffic destined for the internal network. Protocol 103 is Protocol Independent Multicast (PIM), which is a commonly deployed application in multicast networks. Interfaces with PIM enabled have not been found to be vulnerable to exploit traffic with protocol 103; PIM traffic may be permitted to those select devices. access-list 101 deny 53 any any access-list 101 deny 55 any any access-list 101 deny 77 any any access-list 101 deny 103 any any !--- insert any other previously applied ACL entries here !--- you must permit other protocols through to allow normal !--- traffic -- previously defined permit lists will work !--- or you may use the permit ip any any shown here access-list 101 permit ip any any Prior to deploying ACLs that filter transit traffic, a classification ACL can be used to help identify required permit statements. A classification ACL is an ACL that permits a series of protocols. Displaying access-list entry hit counters helps determine required protocols: entries with zero packets counted are likely not required. Classification access-lists are detailed in the link below for infrastructure access-lists. Receive ACLs For distributed platforms, receive path access lists may be an option starting in Cisco IOS Software Versions 12.0(21)S2 for the c12000 and 12.0(24)S for the c7500. The receive access lists protect the device from harmful traffic before the traffic can impact the route processor. The CPU load is distributed to the line card processors and helps mitigate load on the main route processor. The white paper entitled "GSR: Receive Access Control Lists" will help you identify and allow legitimate traffic to your device and deny all unwanted packets: http://www.cisco.com/warp/customer/707/racl.html Infrastructure ACLs Although it is often difficult to block traffic transiting your network, it is possible to identify traffic which should never be allowed to target your infrastructure devices and block that traffic at the border of your network. The white paper entitled "Protecting Your Core: Infrastructure Protection Access Control Lists" presents guidelines and recommended deployment techniques for infrastructure protection ACLs: http://www.cisco.com/warp/customer/707/iacl.html Exploitation and Public Announcements ===================================== Since the initial posting of this document, the Cisco PSIRT has been made aware of public announcements of the vulnerabilities described in this advisory. PSIRT has chosen to resend to our standard distribution list immediately with further details to assist network administrators in mitigation. Status of This Notice: INTERIM ============================== This is an INTERIM notice. Although Cisco cannot guarantee the accuracy of all statements in this notice, all of the facts have been checked to the best of our ability. Cisco does not anticipate issuing updated versions of this advisory unless there is some material change in the facts. Should there be a significant change in the facts, Cisco will update this advisory. Distribution ============ This notice is posted on the Cisco worldwide website at http://www.cisco.com/warp/public/707/cisco-sa-20030717-blocked.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 at the public release date and time: * cust-security-announce(a)cisco.com * bugtraq(a)securityfocus.com * full-disclosure(a)lists.netsys.com * first-teams(a)first.org (includes CERT/CC) * cisco(a)spot.colorado.edu * cisco-nsp(a)puck.nether.net * nanog(a)merit.edu * sanog(a)sanog.org * comp.dcom.sys.cisco * Various internal Cisco mailing lists Future updates of this advisory, if any, will be placed on the Cisco worldwide web server. Users concerned about this problem are encouraged to check the URL given above for any updates. Revision History ================ +-------------------------------------------+ | Revision | 17-July-2003 | Initial public | | 1.0 | 0:00 GMT | release | |----------+--------------+-----------------| | | | Updated | | | | Workaround | | Revision | 17-July-2003 | section (access | | 1.1 | 6:10 GMT | lists), Updated | | | | table with | | | | information on | | | | 12.0W5 | |----------+--------------+-----------------| | | | Corrected "Last | | | | Updated" time; | | | | corrected | | Revision | 17-July-2003 | document title | | 1.2 | 10:30 GMT | of | | | | Infrastructure | | | | ACL link under | | | | Workaround | | | | section | |----------+--------------+-----------------| | | | Added "with | | | | specific | | | | protocol | | | | fields" in | | | | Summary | | | | section; | | | | updated Details | | | | section to | | | | include | | | | protocol types; | | | | added details | | Revision | 17-July-2003 | to the Cisco | | 1.3 | 23:00 GMT | vulnerabilities | | | | paragraph; | | | | added an output | | | | example to | | | | identify an | | | | attack packet; | | | | rewrote Transit | | | | ACLs section; | | | | updated | | | | Exploitation | | | | and Public | | | | Announcements | | | | paragraph | +-------------------------------------------+ 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 the Cisco worldwide website at http://www.cisco.com/warp/public/707/sec_incident_response.shtml. This includes instructions for press inquiries regarding Cisco security notices. All Cisco Security Advisories are available at http://www.cisco.com/go/psirt. - ---------------------------------------------------------------------- This notice is Copyright 2003 by Cisco Systems, Inc. This notice may be redistributed freely after the release date given at the top of the text, provided that redistributed copies are complete and unmodified, and include all date and version information. - ---------------------------------------------------------------------- Toolbar ======= All contents are Copyright � 1992-2003 Cisco Systems, Inc. All rights reserved. -----BEGIN PGP SIGNATURE----- Version: PGP 6.5.2 iQA/AwUBPxchOXsxqM8ytrWQEQLgzwCeMBqiamX2K/VvMhIgooz9d11K1VoAoLcF nmN6hA5ZuyDFBhW3o+FydDop =pSyP -----END PGP SIGNATURE-----

2 1

IPv6
by Antonio Broughton 17 Jul '03

17 Jul '03

Hey, I was just looking through the archives of the list, and found a post that was about IPv6 peering in New Zealand. I am currently trying to setup a website (http://www.ipv6.co.nz) but as such, I am the only one involved :P. If anyone wants to help me setup content for the site etc, or if you would like to use the domain for such things as the domain for a New Zealand IPv6 Peer... then by allmeans... you can use it, just email me... Antonio Broughton

14 32

Fwd: Critical Vulnerability discovered in Windows Servers
by barry＠unix.co.nz 17 Jul '03

17 Jul '03

Don't know how many windows admins out there, but incase you havn't yet heard about the new windows RPC sploit, read below. ----- Forwarded message from Haroon Meer <haroon(a)sensepost.com> ----- Date: Fri, 18 Jul 2003 02:48:06 +0200 (SAST) From: Haroon Meer <haroon(a)sensepost.com> Reply-To: Haroon Meer <haroon(a)sensepost.com> Subject: Critical Vulnerability discovered in Windows Servers To: icepick(a)cybernett.co.za Dear Barry Murphy, Vulnerability in Microsoft Windows Servers. Versions Affected : Windows XP, Windows NT4, Windows2000, Windows2003 Severity of Bug : CRITICAL Port / Service : Port 135 - Microsoft RPC A Polish security research group have found a remotely exploitable bug in Windows based operating systems. The bug affects almost the entire Microsoft Product range from Windows NT4, to Windows2000 and even Windows2003. The exploit uses port 135 as its attack vector with the exploitable component being Microsoft RPC. This vulnerability should be considred "Critical" since it yields "SYSTEM" privileges on the victim machine. Microsoft have issued an advisory and a patch is available from them at the following location : http://www.microsoft.com/security/security_bulletins/ms03-026.asp The possible workarounds for the problem untill the patch is applied are to : [a] Firewall off access to port 135 [b] Disable DCOM on the server (Using Dcomcnfg.exe) While no exploit code for this vulnerability is currently reported in the wild, the problem aknowledged by Microsoft to be exploitable, meaning that Proof of Concept exploits (and possibly worms) will not be a long time coming. Full details on the exploit can be found at http://lsd-pl.net/special.html. Sincerely. ======================================================= SensePost Research research(a)sensepost.com http://www.sensepost.com (tel) +27 12 667 4737 ======================================================= ----- End forwarded message ----- ------------------------------------------------- This mail sent through IMP: http://horde.org/imp/

1 0

Peering at the APE and WIX
by Andy Linton 16 Jul '03

16 Jul '03

At the nznog meeting in Auckland last week I said I'd give details of how to apply for a connection once the new web pages were available and so here they are: http://www.citylink.co.nz/cgi-bin/wixape.pl?tmpl=ape.tmpl http://www.citylink.co.nz/cgi-bin/wixape.pl?tmpl=wix.tmpl You may also find the two Looking Glass pages, that give a view of what is happening on the APE and WIX route servers, useful: http://www.wix.net.nz/cgi-bin/mrlg-ape.cgi http://www.wix.net.nz/cgi-bin/mrlg-wix.cgi

1 0

IOS Vulnerability
by Arron Scott 16 Jul '03

16 Jul '03

As mentioned by Joe, Cisco has just announced a vulnerability that affects all versions of IOS, on any device, switches and routers. In the first instance, it is important to note that there are currently NO known exploitations of this vulnerability, and we are announcing it after building and preparing the appropriate fixes for all current platforms. Fixes have been made available regardless of whether your routers are under a maintentance support contract or not. The following URL also defines how to build Access-lists that can protect you from this vulnerability. http://www.cisco.com/warp/public/707/cisco-sa-20030717-blocked.shtml Do not panic, if you need more detail, feel free to give me a ring. If you can find an opportunity we would recommend an upgrade, but this is out of caution rather than need. Hope this helps to clarify the situation Arron Scott Cisco NZ *********************************************************************** Arron Scott (CCIE #4099) Phone: +64-9-3551951 Systems Engineer Mobile: +64-21-883163 Cisco New Zealand mailto:ascott(a)cisco.com http://www.cisco.com ***********************************************************************

1 0

upgrade your routers
by Joe Abley 16 Jul '03

16 Jul '03

forwarded from cisco, not from any other source Begin forwarded message: > From: Scott McGrath <mcgrath(a)fas.harvard.edu> > Date: Wed Jul 16, 2003 23:02:37 Canada/Eastern > To: nanog(a)merit.edu > Subject: IOS Vulnerability > > > > For full details about the vulnerability see > > http://www.cisco.com/en/US/products/hw/routers/ps341/ > products_security_advisory09186a00801a34c2.shtml > > Scott C. McGrath >

1 1

Cisco Security Advisory: Cisco IOS Interface Blocked by IPv4 Packet
by Cisco Systems Product Security Incident Response Team 16 Jul '03

16 Jul '03

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Cisco Security Advisory: Cisco IOS Interface Blocked by IPv4 Packet Revision 1.0 ============ For Public Release 2003 July 17 at 0:00 UTC (GMT) - -------------------------------------------------------------------------- Please provide your feedback on this document. - -------------------------------------------------------------------------- Contents ======== Summary Affected Products Details Impact Software Versions and Fixes Obtaining Fixed Software Workarounds Exploitation and Public Announcements Status of This Notice: INTERIM Distribution Revision History Cisco Security Procedures - -------------------------------------------------------------------------- Summary ======= Cisco routers and switches running Cisco IOS® software and configured to process Internet Protocol version 4 (IPv4) packets are vulnerable to a Denial of Service (DoS) attack. A rare sequence of crafted IPv4 packets sent directly to the device may cause the input interface to stop processing traffic once the input queue is full. No authentication is required to process the inbound packet. Processing of IPv4 packets is enabled by default. Devices running only IP version 6 (IPv6) are not affected. A workaround is available. Cisco has made software available, free of charge, to correct the problem. This advisory is available at http://www.cisco.com/warp/public/707/cisco-sa-20030717-blocked.shtml. Affected Products ================= This issue affects all Cisco devices running Cisco IOS software and configured to process Internet Protocol version 4 (IPv4) packets. Cisco devices which do not run Cisco IOS software are not affected. Devices which run only Internet Protocol version 6 (IPv6) are not affected. Details ======= Cisco routers are configured to process and accept Internet Protocol version 4 (IPv4) packets by default. A rare, specially crafted sequence of IPv4 packets which is handled by the processor on a Cisco IOS device may force the device to incorrectly flag the input queue on an interface as full, which will cause the router to stop processing inbound traffic on that interface. This can cause routing protocols to drop due to dead timers. On Ethernet interfaces, Address Resolution Protocol (ARP) times out after a default time of four hours, and no traffic can be processed. The device must be rebooted to clear the input queue on the interface, and will not reload without user intervention. The attack may be repeated on all interfaces causing the router to be remotely inaccessible. A workaround is available, and is documented in the Workarounds section. The following two Cisco vulnerabilities are documented in DDTS. CSCea02355 ( registered customers only) affects all Cisco routers running Cisco IOS software. CSCdz71127 ( registered customers only) was introduced by an earlier code revision. Any version of software which has the fix for CSCdx02283 ( registered customers only) is vulnerable. Registered customers can find more details using the Bug Toolkit at http://www.cisco.com/cgi-bin/Support/Bugtool/launch_bugtool.pl ( registered customers only) . To identify a blocked input interface, use the show interfaces command and look for the Input Queue line. If the current size (in this case, 76) is larger than the maximum size (75), the input queue is blocked. Router#show interface ethernet 0/0 Ethernet0/0 is up, line protocol is up Hardware is AmdP2, address is 0050.500e.f1e0 (bia 0050.500e.f1e0) Internet address is 172.16.1.9/24 MTU 1500 bytes, BW 10000 Kbit, DLY 1000 usec, rely 255/255, load 1/255 Encapsulation ARPA, loopback not set, keepalive set (10 sec) ARP type: ARPA, ARP Timeout 04:00:00 Last input 00:00:41, output 00:00:07, output hang never Last clearing of "show interface" counters 00:07:18 Input queue: 76/75/1091/0 (size/max/drops/flushes); Total output drops: 0 ^^^^^^^^^^^^^^ ---> blocked Impact ====== A device receiving these specifically crafted IPv4 packets will force the inbound interface to stop processing traffic. The device may stop processing packets destined to the router, including routing protocol packets and ARP packets. No alarms will be triggered, nor will the router reload to correct itself. This issue can affect all Cisco devices running Cisco IOS software. This vulnerability may be exercised repeatedly resulting in loss of availability until a workaround has been applied or the device has been upgraded to a fixed version of code. Software Versions and Fixes =========================== Each row of the table describes a release train and the platforms or products for which it is intended. If a given release train is vulnerable, then the earliest possible releases that contain the fix and the anticipated date of availability for each are listed in the Rebuild, Interim, and Maintenance columns. In some cases, no rebuild of a particular release is planned; this is marked with the label "Not scheduled." A device running any release in the given train that is earlier than the release in a specific column (less than the earliest fixed release) is known to be vulnerable, and it should be upgraded at least to the indicated release or a later version (greater than the earliest fixed release label). When selecting a release, keep in mind the following definitions: * Maintenance Most heavily tested and highly recommended release of any label in a given row of the table. * Rebuild Constructed from the previous maintenance or major release in the same train, it contains the fix for a specific vulnerability. Although it receives less testing, it contains only the minimal changes necessary to effect the repair. Cisco has made available several rebuilds of mainline trains to address this vulnerability, but strongly recommends running only the latest maintenance release on mainline trains. * Interim Built at regular intervals between maintenance releases and receives less testing. Interims should be selected only if there is no other suitable release that addresses the vulnerability, and interim images should be upgraded to the next available maintenance release as soon as possible. Interim releases are not available through manufacturing, and usually they are not available for customer download from CCO without prior arrangement with the Cisco Technical Assistance Center (TAC). 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 TAC for assistance, as shown in the section following this table. +------------------------------------------------------------------------+ |Train |Description of |Availability of Fixed Releases | | |Image or Platform| | |------------------------+-----------------------------------------------+ | 11.x based releases | Rebuild |Interim| Maintenance | |------------------------+-------------+-------+-------------------------+ |11.1CA| |11.1(36)CA4**| | | |------+-----------------+-------------+-------+-------------------------+ |11.2 | |11.2(26e)** | | | |------+-----------------+-------------+-------+-------------------------+ |11.2P | |11.2(26)P5** | | | |------+-----------------+-----------------------------------------------+ |11.3 | |Not scheduled | |------+-----------------+-----------------------------------------------+ |11.3T | |Not scheduled | |------------------------+-----------------------------------------------+ |12.0 based releases |Rebuild |Interim|Maintenance | |------------------------+-------------+-------+-------------------------+ | |General | | | | |12.0 |Deployment | | |12.0(26) | | |release for all | | | | | |platforms | | | | |------+-----------------+-----------------------------------------------+ |12.0DA|xDSL support: |Migrate to 12.2DA; 12.2(10)DA2 - Aug-15-2003, | | |6100, 6200 |12.2(12)DA3 - Aug-22-2003: Engineering | | | |Specials available on request. | |------+-----------------+-----------------------------------------------+ |12.0DB|Early Deployment |Migrate to 12.3(1a) | | |6400 UAC for NSP | | |------+-----------------+-----------------------------------------------+ |12.0DC|Early Deployment |Migrate to 12.3(1a) | | |6400 UAC for NRP | | |------+-----------------+-----------------------------------------------+ | | |12.0(24)S2 | | | | | |12.0(23)S3 | | | | | |12.0(22)S5 | | | | | |12.0(21)S7 | | | | | |12.0(19)S4 | | | | |Core/ISP support:|12.0(18)S7 | | | |12.0S |GSR, RSP, c7200, |12.0(17)S7 | |12.0(25)S | | |c10k |12.0(16)S10 | | | | | |12.0(15)S7 | | | | | |12.0(14)S8 | | | | | |12.0(13)S8 | | | | | |12.0(12)S4 | | | | | |12.0(10)S8 | | | |------+-----------------+-----------------------------------------------+ |12.0SC|Cable/broadband |Migrate to 12.1(19)EC | | |ISP: ubr7200 | | |------+-----------------+-----------------------------------------------+ |12.0SL|100000 ESR:c10k |Migrate to 12.0(23)S3, **12.0(17)SL9 - | | | |Jul-15-2003 | |------+-----------------+-----------------------------------------------+ |12.0SP|Early Deployment |Migrate to 12.0(22)S5 | |------+-----------------+-----------------------------------------------+ | |Early Deployment |12.0(21)ST7 | | | |12.0ST|release for Core/|12.0(20)ST6 | | | | |ISP support: GSR,|12.0(19)ST6 | | | | |RSP, c7200 |12.0(17)ST8 | | | |------+-----------------+-----------------------------------------------+ |12.0SX|Early Deployment |Migrate to 12.0(22)S5 | |------+-----------------+-----------------------------------------------+ |12.0SY|Early Deployment |Migrate to 12.0(23)S3 | |------+-----------------+-----------------------------------------------+ |12.0SZ|Early Deployment |Migrate to 12.0(23)S3 | |------+-----------------+-----------------------------------------------+ |12.0T |Early Deployment |12.0(7)T3** | | | |------+-----------------+-------------+-------+-------------------------+ | |85xx ls1010 | | |12.0(26)W5(28) | | |-----------------+-------------+-------+-------------------------+ | |c5atm |12.0(24)W5 | | | | | |(26a) | | | | |-----------------+-------------+-------+-------------------------+ | |Cat4232 and |12.0(25)W5 | | | | |Cat2948G-L3 |(27) | | | |12.0W5|-----------------+-------------+-------+-------------------------+ | |C6MSM,C5rsfc, |Engineering | | | | |C5rsm, |Special | | | | | |available on | | | | | |request | | | | |-----------------+-------------+-------+-------------------------+ | |C3620, C3640, | | | | | |C4500, C7200, RSP| | | | |------+-----------------+-------------+-------+-------------------------+ |12.0WC|Early deployment |12.0(05)WC8 | | | | |2900XL-LRE,2900XL| | | | | |/3500XL; 2950 | | | | | |release | | | | |------+-----------------+-------------+-------+-------------------------+ |12.0WT|Early deployment |Engineering | | | | |Catalyst |Special | | | | |switches: |Available | | | | |cat4840g, |upon request | | | |------+-----------------+-----------------------------------------------+ |12.0X |Shortlived Early |All 12.0X(any letter) releases have migrated to| |(l) |Deployment |either 12.0T or 12.1 unless otherwise | | |Releases |documented in the X release technical notes | | | |pertaining to the specific release. Please | | | |check migration paths for all 12.0X releases. | |------------------------+-----------------------------------------------+ |12.1 based releases |Rebuild |Interim|Maintenance | |------------------------+-------------+-------+-------------------------+ | |General | | | | |12.1 |Deployment | |12.1 |12.1(19) | | |release for all | |(18.4) | | | |platforms | | | | |------+-----------------+-----------------------------------------------+ |12.1AA| |Migrate to 12.2 | |------+-----------------+-----------------------------------------------+ |12.1AX|Catalyst 3750 |12.1(14)EA1 -| | | | | |Engineering | | | | | |special | | | | | |available | | | | | |upon request | | | |------+-----------------+-------------+-------+-------------------------+ |12.1AY|Catalyst 2940 | | |12.1(13)AY | |------+-----------------+-----------------------------------------------+ |12.1DA|6160 platform |Migrate to 12.2DA | |------+-----------------+-----------------------------------------------+ |12.1DB|6400 UAC |Migrate to 12.3(1a) | |------+-----------------+-----------------------------------------------+ |12.1DC|6400 UAC |Migrate to 12.3(1a) | |------+-----------------+-----------------------------------------------+ |12.1E |Core Enterprise |12.1(8b)E14 | |12.1(19)E | | |support - c7200, |12.1(13)E7 | | | | |Catalyst 6000, |12.1(14)E4 | | | | |RSP |**12.1(12c)E7| | | | | |12.1(11b)E12-| | | | | |Aug-4-2003 | | | | | |12.1(6)E12 | | | |------+-----------------+-----------------------------------------------+ |12.1EA|12.1(4)EA |Migrate to 12.1(13)EA1c | | |12.1(6)EA | | | |12.1(8)EA | | | |12.1(9)EA | | | |12.1(11)EA | | | |-----------------+-----------------------------------------------+ | |12.1(12c)EA |12.1(13)EA1c | | | | |12.1(13)EA | | | | |------+-----------------+-------------+-------+-------------------------+ |12.1EB|LS1010 | | |12.1(14)EB | |------+-----------------+-------------+-------+-------------------------+ |12.1EC|Early Deployment | | |12.1(19)EC (scheduled | | | | | |last week of July) | |------+-----------------+-------------+-------+-------------------------+ |12.1EV|Early Deployment | | |12.1(12c)EV | |------+-----------------+-------------+-------+-------------------------+ |12.1EW|Early Deployment | | |12.1(13)EW,12.1(19)EW | | |Cat4000 L3 | | | | |------+-----------------+-------------+-------+-------------------------+ |12.1EX|Early deployment |12.1(13)EX2 | | | |------+-----------------+-------------+-------+-------------------------+ |12.1EY| | |12.1(14)E4 | | | |------+--+--------------+-------------+-------+-------------------------+ |12.1YJ| | |12.1(14)EA1 -| | | | | | |Jul-28-2003 | | | |------+-----------------+-------------+-------+-------------------------+ |12.1T |Early deployment |12.1(5)T15** | | | |------+-----------------------------------------------------------------+ |12.1X |12.1X releases generally migrate to 12.1T, 12.2 or 12.2T as | |(l) |specified below. Please refer to specific train Technical notes | | |for documented migration path. | |------+-----------------------------------------------------------------+ |12.1XA|Short lived Early|Migrate to 12.1(5)T15 | | |Deployment | | | |Release | | |------+-----------------+-----------------------------------------------+ |12.1XC|Short lived Early|Migrate to12.2(17) | |12.1XD|Deployment | | |12.1XH|Releases | | |12.1XI| | | |------+-----------------+-----------------------------------------------+ |12.1XB|Short lived Early|Migrate to 12.2(15)T5 | |12.1XF|Deployment | | |12.1XG|Releases | | |12.1XJ| | | |12.1XL| | | |12.1XP| | | |12.1XR| | | |12.1XT| | | |12.1YB| | | |12.1YC| | | |12.1YD| | | |12.1YH| | | |------+-----------------+-----------------------------------------------+ |12.1XM|Short lived Early|Migrate to 12.2(2)XB11 | |12.1XQ|Deployment | | |12.1XV|Releases | | |------+-----------------+-----------------------------------------------+ |12.1XU|Short lived Early|Migrate to 12.2(4)T6 | | |Deployment | | | |Release | | |------+-----------------+-----------------------------------------------+ |12.1YE|Short lived Early|Migrate to 12.2(2)YC | |12.1YF|Deployment | | |12.1YI|Release | | |------------------------+-----------------------------------------------+ |12.2 based releases |Rebuild |Interim|Maintenance | |------------------------+-------------+-------+-------------------------+ | |General |12.2(16a) | | | |12.2 |Deployment (GD) |12.2(12e) | |12.2(17) | | |candidate for all|12.2(10d) | | | | |platforms | | | | |------+-----------------+-------------+-------+-------------------------+ |12.2B |12.2(2)B-12.2(4) |12.3(1a) | | | | |B7 | | | | | |-----------------+-------------+-------+-------------------------+ | |12.2(4)B8-12.2 |12.2(16)B1 | | | | |(16)B | | | | |------+-----------------+-------------+-------+-------------------------+ |12.2BC|Early Deployment |12.2(15)BC1 | | | | |Release |(Scheduled | | | | | |end of July) | | | |------+-----------------+-------------+-------+-------------------------+ |12.2BW|Early Deployment |Migrate to | | | | |for use with |12.3(1a) | | | | |7200, 7400, and | | | | | |7411 platforms | | | | |------+-----------------+-------------+-------+-------------------------+ |12.2BX|Broadband/Leased | | |12.2(16)BX | | |line | | | | |------+-----------------+-------------+-------+-------------------------+ |12.2BZ|Early Deployment |12.2(15)BZ1 | | | | |Release | | | | |------+-----------------+-----------------------------------------------+ |12.2CX|Early Deployment |Migrate to 12.1(15)BC1 | | |Release | | |------+-----------------+-----------------------------------------------+ |12.2CY|Early Deployment |Migrate to 12.1(15)BC1 | | |Release | | |------+-----------------+-----------------------------------------------+ |12.2DA|Early Deployment |12.2(10)DA2 -| | | | |Release |Jul-15-2003 | | | | | |12.2(12)DA3 -| | | | | |Aug-22-2003 | | | | | |Enginering | | | | | |Special | | | | | |available on | | | | | |request | | | |------+-----------------+-----------------------------------------------+ |12.2DD|Early Deployment |Migrate to 12.3(1a) | | |Release | | |------+-----------------+-----------------------------------------------+ |12.2DX|Early Deployment |Migrate to 12.3(1a) | | |Release | | |------+-----------------+-----------------------------------------------+ |12.2JA|Cisco Aironet | | |12.2(11)JA | | |hardware | | | | | |platforms: | | | | | |Introduction of | | | | | |Access Point | | | | | |feature in IOS, | | | | | |Cisco 1100 Series| | | | | |Access Point | | | | | |(802.11b) | | | | |------+-----------------+-------------+-------+-------------------------+ |12.2MB|Specific |12.2(4)MB12 | | | | |Technology ED for| | | | | |2600 7500 (GPRS/ | | | | | |PDSN/GGSN | | | | | |2600/7200/7500) | | | | |------+-----------------+-------------+-------+-------------------------+ |12.2MC|Early Deployment:|12.2(13)MC1 | | | | |IP RAN |CCO: 7/24/03 | | | |------+-----------------+-------------+-------+-------------------------+ |12.2MX| |12.2(8)YD | | | | | | | | | |------+-----------------+-------------+-------+-------------------------+ |12.2S |Core/ISP support:|12.2(14)S1 |12.2 | | | |GSR, RSP, c7200 | |(16.5)S| | |------+-----------------+-------------+-------+-------------------------+ |12.2SX|IOS Support for |12.2(14)SX1 | | | | |C6500 Supervisor | | | | | |3 | | | | |------+-----------------+-------------+-------+-------------------------+ |12.2SY|VPN feature |12.2(14)SY1, | | | | |release for c6k/ |12.2(8)YD | | | | |76xx VPN service | | | | | |module. | | | | |------+-----------------+-------------+-------+-------------------------+ |12.2SZ|7304 Platform |12.2(14)SZ2 | | | |------+-----------------+-------------+-------+-------------------------+ | | |12.2(15)T4/ | |No more maintenance | | |New Technology |5,12.2(13)T5,| |trains for 12.2T are | |12.2T |Early Deployment |12.2(11) |12.2 |planned, please migrate | | |(ED) release for |T9,12.2(8) |(16.5)T|to latest 12.3 Mainline | | |all platforms |T10, | |release. | | | |12.2(4)T6 | | | |------+-----------------+-----------------------------------------------+ |12.2X |Short lived Early|Many short lived releases migrate to the same | |(l) |Deployment |train; the trains below this point until the | |12.2Y |Releases - |following section are not grouped by strict | |(l) | |alphabetical order, but are grouped by | | | |migration path. Please review documented | | | |migration paths for your trains. | |------+-----------------+-----------------------------------------------+ |12.2XA|Short lived Early|Migrate to 12.2(11)T9 | | |Deployment | | | |Releases | | |------+-----------------+-----------------------------------------------+ |12.2XS| |12.2(2)XB11 | |------+-----------------+-----------------------------------------------+ |12.2XD|Short lived Early|Migrate to 12.2(15)T5 | |12.2XE|Deployment | | |12.2XH|Releases | | |12.2XI| | | |12.2XJ| | | |12.2XK| | | |12.2XL| | | |12.2XM| | | |12.2XQ| | | |12.2XU| | | |12.2XW| | | |12.2YA| | | |12.2YB| | | |12.2YC| | | |12.2YF| | | |12.2YG| | | |12.2YH| | | |12.2YJ| | | |12.2YT| | | |------+-----------------+-----------------------------------------------+ | |Short lived Early| | |12.2YN|Deployment |Migrate to 12.2(13)ZH | | |Releases | | |------+-----------------+-----------------------------------------------+ | |Short lived Early|Migrate to 12.2(14)SY1 available Aug-4-2003: | |12.2YO|Deployment |Engineering Special available on request | | |Releases | | |------+-----------------+-----------------------------------------------+ | |Early Deployment | | | | |12.2XB|Release with |12.2(2)XB11 | | | | |continuing | | | | | |support | | | | |------+-----------------+-----------------------------------------------+ |12.2XC|Short lived Early|Migrate to 12.2(16)B1 | | |Deployment | | | |Releases | | |------+-----------------+-----------------------------------------------+ |12.2XF|Short lived Early|Migrate to 12.2(15)BC1 | | |Deployment | | | |Release UBR10000 | | |------+-----------------+-----------------------------------------------+ |12.2XG|Short lived Early|Migrate to 12.2(8)T10 | | |Deployment | | | |Release | | |------+-----------------+-----------------------------------------------+ |12.2XN|Short lived Early|Migrate to 12.2(11)T9 | |12.2XT|Deployment | | | |Releases | | |------+-----------------+-----------------------------------------------+ |12.2YD|Short lived Early|Migrate to 12.2(8)YY | | |Deployment | | | |Release | | |------+-----------------+-----------------------------------------------+ | |Short lived Early| | | | |12.2YP|Deployment |**12.2(11)YP1| | | | |Release | | | | |------+-----------------+-----------------------------------------------+ |12.2YK| |Migrate to 12.2(13)ZC | |------+-----------------+-----------------------------------------------+ |12.2YL|Short lived Early|Migrate to 12.2(13)ZH | |12.2YM|Deployment | | |12.2YU|Releases | | |12.2YV| | | |------+-----------------+-----------------------------------------------+ |12.2YQ|Short lived Early|Migrate to 12.2(15)ZL | |12.2YR|Deployment | | | |Releases | | |------+-----------------+-----------------------------------------------+ |12.2YS|Short lived Early|12.2(15)YS/ | | | | |Deployment |1.2(1) | | | | |Release | | | | |------+-----------------+-------------+-------+-------------------------+ |12.2YW|Short lived Early|12.2(8)YW2 | | | | |Deployment | | | | | |Releases | | | | |------+-----------------+-------------+-------+-------------------------+ |12.2YX|Short lived Early|12.2(11)YX1 | | | | |Deployment | | | | | |Release | | | | | |Crypto for 7100/ | | | | | |7200 | | | | |------+-----------------+-------------+-------+-------------------------+ |12.2YY|Short lived Early|12.2(8)YY3 | | | | |Deployment | | | | | |Releases | | | | | |IOS support for | | | | | |General Packet | | | | | |Radio Service | | | | |------+-----------------+-------------+-------+-------------------------+ |12.2YZ|Short lived Early|12.2(11)YZ2 | | | | |Deployment | | | | | |Release | | | | |------+-----------------+-------------+-------+-------------------------+ |12.2ZA|Short lived Early| | |12.2(14)ZA2 | | |Deployment | | | | | |Release | | | | |------+-----------------+-------------+-------+-------------------------+ |12.2ZB|Short lived Early|12.2(8)ZB7 | | | | |Deployment | | | | | |Release | | | | |------+-----------------+-------------+-------+-------------------------+ |12.2ZC|Short lived Early| | |12.2(13)ZC | | |Deployment | | | | | |Release | | | | |------+-----------------+-------------+-------+-------------------------+ |12.2ZD|Short lived Early|Not Scheduled| | | | |Deployment | | | | | |Release | | | | |------+-----------------+-------------+-------+-------------------------+ |12.2ZE|Short lived Early|12.3(1a) | | | | |Deployment | | | | | |Release | | | | |------+-----------------+-------------+-------+-------------------------+ |12.2ZF|Short lived Early|Not | | | | |Deployment |Vulnerable | | | | |Release | | | | |------+-----------------+-------------+-------+-------------------------+ |12.2ZG|Short lived Early|Not | | | | |Deployment |Vulnerable | | | | |Release | | | | |------+-----------------+-------------+-------+-------------------------+ |12.2ZH|Short lived Early|Not | | | | |Deployment |Vulnerable | | | | |Release | | | | |------+-----------------+-------------+-------+-------------------------+ |12.2ZJ|Short lived Early|12.2(15)ZJ1 | | | | |Deployment | | | | | |Release | | | | |------+-----------------+-------------+-------+-------------------------+ |12.2ZL|Short lived Early|Not | | | | |Deployment |Vulnerable | | | | |Release | | | | |------------------------+-----------------------------------------------+ |12.3 based releases |NOT VULNERABLE | |------------------------------------------------------------------------+ |Notes: **Marked versions of code are not available on CCO. Please | |contact TAC and request the specific images you need posted. | +------------------------------------------------------------------------+ Notes: ** Marked versions of code are not available on CCO. Please contact the Cisco TAC and request the specific images you need posted. Obtaining Fixed Software ======================== Customers with contracts should obtain upgraded software free of charge through their regular update channels. For most customers, this means that upgrades should be obtained through the Software Center on the Cisco worldwide website at http://www.cisco.com/tacpage/sw-center/sw-ios.html. Customers whose Cisco products are provided or maintained through prior or existing agreement with third-party support organizations such as Cisco Partners, authorized resellers, or service providers should contact that support organization for assistance with obtaining the free software upgrade(s). Customers who purchase direct from Cisco but who do not hold a Cisco service contract and customers who purchase through third-party vendors but are unsuccessful at obtaining fixed software through their point of sale should get their 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(a)cisco.com Please have your product serial number available and give the URL of this notice as evidence of your entitlement to a free upgrade. Free upgrades for non-contract customers must be requested through the TAC. Please do not contact either "psirt(a)cisco.com" or "security-alert(a)cisco.com" for software upgrades. See http://www.cisco.com/warp/public/687/Directory/DirTAC.shtml for additional TAC contact information, including special localized telephone numbers, instructions, and e-mail addresses for use in various languages. Workarounds =========== AFTER APPLYING THE WORKAROUND the input queue depth may be raised with the hold-queue <new value> in interface command -- the default size is 75. This will allow traffic flow on the interface until the device can be reloaded. Cisco recommends that all IOS devices which process IPv4 packets be configured to block traffic directed to the router from any unauthorized source with the use of Access Control Lists (ACLs). This can be done at multiple locations, and it is recommended that you review all methods and use the combination which fits your network best. Legitimate traffic is defined as management protocols such as telnet, snmp or ssh, and configured routing protocols from explicitly allowed peers. All other traffic destined to the device should be blocked at the input interface. Traffic entering the network should also be carefully evaluated and filtered at the network edge if destined to an infrastructure device. Although network service providers must often allow unknown traffic to transit their network, it is not necessary to allow that same traffic destined to their network infrastructure. Several white papers have been written to assist in deploying these recommended security best practices. ACLs can have performance impact on certain platforms, so care should be taken when applying the recommended workarounds. Receive ACLs For distributed platforms, receive path access lists may be an option starting in Cisco IOS software versions 12.0(21)S2 for the c12000 and 12.0 (24)S for the c7500. The receive access lists protect the device from harmful traffic before the traffic can impact the route processor. The CPU load is distributed to the line card processors and helps mitigate load on the main route processor. The white paper entitled "GSR: Receive Access Control Lists" will help you identify and allow legitimate traffic to your device and deny all unwanted packets: http://www.cisco.com/warp/customer/707/racl.html Infrastructure ACLs Although it is often difficult to block traffic transiting your network, it is possible to identify traffic which should never be allowed to target your infrastructure devices and block that traffic at the border of your network. The white paper entitled "GSR: Receive Access Control Lists" presents guidelines and recommended deployment techniques for infrastructure protection ACLs: http://www.cisco.com/warp/customer/707/iacl.html Transit ACLs The two techniques described above protect infrastructure devices. This IP protocol ACL can also be used to filter transit traffic passing through a network. The ACL will need to permit all protocols used by end users, not just those destined to routers. Since end users can run a wide array of protocols, often unexpected or uncommon protocols, these protocol requirements must be well understood prior to deploying this ACL. The provided list is not a complete list of permissible protocols. This access-list is applied inbound on edge facing interfaces. For complete protection this access-list needs to be implemented on the edge router. For basic TCP,UDP and ICMP, the following ACL will provide protection: access-list 101 permit tcp any any access-list 101 permit udp any any !! GRE tunnel if required access-list 101 permit gre any any !! IPSec ESP if required access-list 101 permit esp any any !! IPSec AH if required access-list 101 permit ah any any access-list 101 permit icmp any any access-list 101 deny ip any any The last statement of the Transit ACL should be a deny any any for IP traffic. Prior to deploying ACLs that filter transit traffic, a classification ACL can be used to help identify required permit statements. A classification ACL is an ACL that permits a series of protocols. Displaying access-list entry hit counters helps determine required protocols: entries with zero packets counted are likely not required. Classification access-lists are detailed in the above link for infrastructure access-lists. Exploitation and Public Announcements ===================================== The Cisco PSIRT is not aware of any public announcements or malicious use of the vulnerabilities described in this advisory. If PSIRT becomes aware of any sign of public announcement of the crafted packet, or there is any sign of exploitation of this vulnerability, a follow-up announcement will be sent to our standard distribution list immediately with further details to assist network administrators in mitigation. Status of This Notice: INTERIM ====================== This is an INTERIM notice. Although Cisco cannot guarantee the accuracy of all statements in this notice, all of the facts have been checked to the best of our ability. Cisco does not anticipate issuing updated versions of this advisory unless there is some material change in the facts. Should there be a significant change in the facts, Cisco will update this advisory. Distribution ============ This notice will be posted on the Cisco worldwide website at http://www.cisco.com/warp/public/707/cisco-sa-20030717-blocked.shtml at 21:00 GMT on July 17th, 2003. In addition to worldwide web posting, a text version of this notice is clear-signed with the Cisco PSIRT PGP key and will be posted to the following e-mail and Usenet news recipients at the public release date and time: * cust-security-announce(a)cisco.com * bugtraq(a)securityfocus.com * full-disclosure(a)lists.netsys.com * first-teams(a)first.org (includes CERT/CC) * cisco(a)spot.colorado.edu * cisco-nsp(a)puck.nether.net * nanog(a)merit.edu * sanog(a)sanog.org * comp.dcom.sys.cisco * Various internal Cisco mailing lists Future updates of this advisory, if any, will be placed on the Cisco worldwide web server. Users concerned about this problem are encouraged to check the URL given above for any updates. Revision History ================ +-------------------------------------------+ | Revision | 17-July-2003 | Initial public | | 1.0 | 0:00 GMT | 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 the Cisco worldwide website at http://www.cisco.com/warp/public/707/sec_incident_response.shtml. This includes instructions for press inquiries regarding Cisco security notices. All Cisco Security Advisories are available at http://www.cisco.com/go/psirt. - -------------------------------------------------------------------------- This notice is Copyright 2003 by Cisco Systems, Inc. This notice may be redistributed freely after the release date given at the top of the text, provided that redistributed copies are complete and unmodified, and include all date and version information. - -------------------------------------------------------------------------- All contents are Copyright © 1992-2003 Cisco Systems, Inc. All rights reserved. Important Notices and Privacy Statement. -----BEGIN PGP SIGNATURE----- Version: PGP 6.5.2 iQA/AwUBPxYP5XsxqM8ytrWQEQJOfwCg04JnuUYEIYQZyfHAeClX5p2SpngAoNMn t2zHq5JVCmsChl0DrSN9jMFq =6bis -----END PGP SIGNATURE-----

1 0

NetForum 2003
by Geoff Cant 16 Jul '03

16 Jul '03

Hi there, I'd like to thank the organisers and all the nznog people who attended NetForum2003 for being really interesting and friendly - I had a great time. Despite being one of the few students there (I was from Massey PN) everyone was amiable and great to talk to. I'd especially like to thank Joe Abbley for his immensely interesting and funny BGP presentations, and Barry Greene and Evi Nemeth for their informative (and scary - 98% rubbish at root-servers) sessions. Thanks very much guys, much looking forward to NetForum 2004 -- Geoff Cant <geoffrey.cant.1(a)uni.massey.ac.nz> (I hope the above didn't sound too gushy, but I really did have a great time :)

5 4

Apologies for 'Test' email
by Tim John 16 Jul '03

16 Jul '03

Hi people, I sent a test message to a customers account yesterday (which had nothing to do with NZNOG), but unfortunately it ended up here. Not sure what the problem was, but putting it down to chubby fingers .... For those who didn't ignore it, please do :) Tim DISCLAIMER: The content of this email is confidential and may contain legally privileged information intended only for the individual or entity named above. Access to this message by anyone else is unauthorised. If you are not the intended recipient, please be advised that the use, distribution and publication of the above information is prohibited. If you have received this email in error, please contact Domainz by returning the email and destroying the original. Thank you.

1 0

RE: [nznog] IPv6
by Chris Hellberg 15 Jul '03

15 Jul '03

when I was running the v6ix in Wellington I was running EBGP sessions with most people who had connections; seemed to work well when I had a bunch of open-souce software mirrors which were v6-accessible and people had routes that went straight to the IX. There was also tunnel to the 6bone at Merit, for those who wanted to have a nosey at the 6bone routing table, although there were some 2000::/24 prefixes on the 6bone. I've talked to Si at Citylink about getting a PI peering block for WIX and APE, but it wasn't a huge priority. I used addresses from a freenet allocation and carved up a /64 in to a bunch of /126s and used them as point-to-point links. Not the best solution in the world, but worked for the purpose. -----Original Message----- From: perry(a)deeper.co.nz [mailto:perry(a)deeper.co.nz] Sent: Wednesday, 16 July 2003 21:43 To: Joe Abley Cc: nznog(a)list.waikato.ac.nz Subject: Re: [nznog] IPv6 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > You can't plumb tunnels right now, today? Or is the problem that > there's just no local place to plumb a tunnel to? > > (see http://ipv6tb.he.net/ for a tunnel broker run by clueful people in > the US). ahh, but tunnels to the US mean that you have the irritating problem that pinging someone on the same ISP as you can give you up to 3,000ms of latency as it transits from here to the US and back again. You have issues when they are overloaded, or down. You have issues if the internet between here and there decides that packets should be routed via darkest peru. IPv6 was designed to work in the situation where you have to bridge large IPv4 clouds. A much better solution for people in New Zealand is to use 6to4 addressing, especially if you're on the end of ADSL or similar and don't have native transport. 6to4 addressing means that whatever device(s) have non-RFC1918 IPv4 addresses can have a /48 assigned to them. 2003:<high two octets of IPv4 address>:<low two octets of IPv4 address>::/48. To route to another 2002::/16 address over IPv4 you just take the packet, encapsulate it in IPv4, and send it to the embedded IPv4 address. Linux and FreeBSD both support this. Latency to other 6to4 addresses is about the same as IPv4, avoiding the entire US round trip. To talk from a 6to4 address to a non-6to4 IPv6 address you route via ::192.88.99.1 which is an AnyCast address. Unfortunately, last time I looked the nearest 192.88.99.1 AnyCast announcement appeared to be in Germany. Is there any chance of someone putting forward 6to4 anycast gateway in the APE and/or the WIX? Of course the problem here is that probably 50% of it's traffic will be international. In an unrelated note, the MetaNet has been used by several people in NZ who are interested in playing around with more interesting networks without breaking things that people pay to use. We use it for peering IPv6 without having to go via the US and we'd be interested in organising IPv6 tunnels with like minded people (either using wand, gre, or 6in4 tunnels) Unfortunately the MetaNet wouldn't handle multicast very well (or we'd be having a good tinker with it) Resources: * http://www.wlug.org.nz/DancingPenguin (A IPv6 enabled website in New Zealand which is useful for testing with) * http://www.wlug.org.nz/IPv6LessonsLearnt (For some random things we've discovered about IPv6 the hard way, so you don't have to) * http://www.wlug.org.nz/6to4 (Information about 6to4 under Linux) * http://www.wlug.org.nz/IPv6 (Information about IPv6 on the wiki) * http://www.nevada.net.nz/~pmurray/6to4.html (6to4 under FreeBSD) If you want to chat about it, we're usually hanging around in #wlug on Undernet. irc://undernet/%23wlug - -- <f00Dave> Look, rejects, this is #OpenGL, not #GEEKSEX. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Only when you are sure they have you, can you stop being paranoid iD8DBQE/FQ0TcAgRpy8z8UQRAhadAJ4gAGn+YRABqt6A7X58K73hBQPNugCgy3ie 05qO9xRxAXyaG1K5EElVfAY= =+lkH -----END PGP SIGNATURE----- _______________________________________________ Nznog mailing list Nznog(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog ------------------------------------------------------------------------------ "This communication, including any attachments, is confidential. If you are not the intended recipient, you should not read it - please contact me immediately, destroy it, and do not copy or use any part of this communication or disclose anything about it. Thank you." ------------------------------------------------------------------------------

1 0

dns and routing slides
by Joe Abley 15 Jul '03

15 Jul '03

The DNS slides I used to talk about DNS, TSIG, DNSSEC and reverse DNS can be found here: http://www.isc.org/misc/nznog/01-Introduction.ppt http://www.isc.org/misc/nznog/06-Reverse.ppt http://www.isc.org/misc/nznog/07-dnssec.ppt The cisco slides I occasionally referred to whilst waving my hands about BGP can be found here: ftp://ftp-eng.cisco.com/pfs/isp-workshops/studentcd-2003a/ Workshop_Materials The whiteboard scribblings and frequent rambling tangents were fortunately not recorded for posterity, but an air ticket and a nominal amount of beer can easily secure a repeat performance :) Joe

1 0

Test
by Tim John 15 Jul '03

15 Jul '03

This is a test. Please ignore .... Tim DISCLAIMER: The content of this email is confidential and may contain legally privileged information intended only for the individual or entity named above. Access to this message by anyone else is unauthorised. If you are not the intended recipient, please be advised that the use, distribution and publication of the above information is prohibited. If you have received this email in error, please contact Domainz by returning the email and destroying the original. Thank you.

1 0

Live Webcast - Meet instructors of Certificate In Web-based Instruction offered by Simon Fraser University
by Abigail 15 Jul '03

15 Jul '03

On July 30th at 1100 hrs Pacific Time (GMT 08:00) there will be a Webcast featuring the instructors of the Certificate in Web-Based Instruction (CWI). Participants of the Webcast can interact with the instructors and ask questions about this program. The CWI program gives you the tools and knowledge necessary to design, develop and deliver web-based courses or add online components to classroom teachings. If you are unable to make it to this live presentation at the above date then you can attend one of the following alternative dates: Wednesday, August 20 at 1100 hrs Pacific Time (GMT 8:00) or Wednesday, September 3 at 1100 hrs Pacific Time (GMT 8:00). Please register to participate in the live Webcast by visiting http://www.sfu.ca/lidc/telestraining. Abby Dy Communications Specialist Certificate in Web-Based Instruction Tel: 604-806-5156 ady(a)sfu.ca

1 0

RE: [nznog] Anyone thinking about WiMAX?
by Matthew G Brown 12 Jul '03

12 Jul '03

New Zealand regulatory bodies are trying to put us more in line with the US FCC standards. So I should not see to much of a problem,. 5.8 & 5.3ghz are virtually self managed by users as it is. I have several cases at the moment of other people using the Uncertified and darn right HORRIBLE! 2.4/5.8 Up.Down converters in areas turning the spectrum in to "Flip the coin for a channel" . But it's a matter if people been sensible and maybe we can take some more control over our own spectrum. Some where I have papers outlinig this, Off list of anyone wants Helen Clarkes peoples dribble on the matter. Best Regards Matthew G Brown Managing Director B & R Holdings LIMITED Nelson, New Zealand Ph: 027 4807731 Http://www.brh.co.nz -----Original Message----- From: Juha Saarinen [mailto:juha(a)saarinen.org] Sent: Friday, 11 July 2003 9:38 a.m. To: Matthew G Brown Subject: RE: [nznog] Anyone thinking about WiMAX? On Thu, 10 Jul 2003, Matthew G Brown wrote: > We had a meeting on this at CeBit Sydney. I was not aware that the > IEEE had ratified the standard at the time. There is plenty of talk > about it in isp-wireless news groups over the last few months. Proxim > and Alvarion are defiantly working on 802.16 at the moment. > > The issue lies with me that if your not after the QOS and control > features then why not just go buy Redline off the shelf, $20,000 for > 55mb over 40 miles is cheap buying. > > Im going to keep following this standard for the fact it can be > developed over a combination of frequencies. Ideally 3.5ghz .... FYI > people considering 3.5ghz should keep in Mind that Alvarion ( Formally > Breezecom ) have been producing 3.5ghz equipment for there local > market for 10 years. Infact the BAII & BreezeAcess series are all > avail at 3.5ghz. Good news for Rural Broadband people > > </rant, less coffee> More coffee... it's morning. Although the 802.16a stuff is pricey at the moment (they're talking US$1,000 for customer "modems") it could be very interesting for providers looking to bypass the local loop stranglehold. Not just for the rurals, in other words. Here's hoping someone else than Walkers will try to deploy in Auckland. I wonder if there are any radio frequency spectrum issues here though? Redline's AN-50 looks like it delivers the same performance -- 72Mbps, up to 80km range... only 49Mbps "at the Ethernet level" though. -- Juha Saarinen

1 0

NetForum 2003
by Tim John 12 Jul '03

12 Jul '03

Hi Roger, Just a quick word of thanks for a most enjoyable couple of days in Auckland during the NetForum conference. Please pass on my thanks to Sue and all the others who worked hard to make it happen this year. I would also like to thank all those who contributed their time by giving presentations during the Thursday and Friday I was there. I didn't catch all the presentations, but the ones I did see were great. BTW, on the flight back to Wellington, I attempted to get into the cockpit and show the pilot what I had learned from the Flight Sim. presentation, but was promptly refused :) Thanks again, Tim DISCLAIMER: The content of this email is confidential and may contain legally privileged information intended only for the individual or entity named above. Access to this message by anyone else is unauthorised. If you are not the intended recipient, please be advised that the use, distribution and publication of the above information is prohibited. If you have received this email in error, please contact Domainz by returning the email and destroying the original. Thank you.

1 0

ISC F root nameserver node live at APE
by Joe Abley 11 Jul '03

11 Jul '03

APE Peering People, Internet Software Consortium has a node of the F root nameserver at the APE in Auckland. Networks connected to the APE can gain access to this node by peering with it across the exchange, as follows: APE addresses: 192.203.154.98, 192.203.154.99 AS number: 23710 NOC phone: +1 650 423 1310 INOC DBA: 3557 NOC e-mail: noc(a)isc.org The APE path to F will also be available through the APE route servers. Networks peering locally with F gain lower transport latency and increased path diversity to the F root nameserver, which helps make the DNS as a whole more reliable. ISC operates an open peering policy. To set up a session please send e-mail to peering(a)isc.org. The F root nameserver node in Auckland advertises the single prefix 192.5.5.0/24 to peers which covers the address of f.root-servers.net. For further details of the general routing policy for F, together with a summary of remote F-root nodes deployed at other exchange points, see: http://www.isc.org/peering/ A representation of the policy for the F-Root node in Auckland is present in the IRR. The Auckland F root nameserver node was made possible by Juniper Networks, TelstraClear, FX Networks and 2day.com. Joe

2 1

usenet.net.nz offline.
by Simon Lyall 11 Jul '03

11 Jul '03

Just a quick FYI but usenet.net.nz is currently offline due to dodgy hardware, this means that the noc contact list, ape website and my looking glass (onlong with random other stuff) is offline. I'll kick the box tomorrow and I have a replacement machine ready, hopefully I'll have a chance to config it up in the next couple of days. -- Simon Lyall. | Newsmaster | Work: simon.lyall(a)ihug.co.nz Senior Network/System Admin | Postmaster | Home: simon(a)darkmere.gen.nz Ihug Ltd, Auckland, NZ | Asst Doorman | Web: http://www.darkmere.gen.nz

1 0

Anyone thinking about WiMAX?
by Juha Saarinen 09 Jul '03

09 Jul '03

www.wimaxforum.org Roundabout 50km reach, with 70Mbps max rate. -- Juha Saarinen

2 1

legal threats from DE Technologies re web commerce
by Robert Hunt 09 Jul '03

09 Jul '03

James & Wells NZ Barristers and Solicitors (http://www.jaws.co.nz) are acting for DE Technologies ( http://www.detechnologies.com ) DE Technologies are described at http://www.globetechnology.com/servlet/GAMArticleHTMLTemplate?tf=globetechn… as "a tiny company in Montreal" and the patent as "a computer implemented process for carrying out an international commercial transaction." I hope this is not seen as off topic. I am at a loss to say whether this is an absurdity or a significant worry, but my firm has recently received a legal fax from James & Wells claiming we are infringing DE Technologies recently acquired NZ Patent. In what looks like a mass produced demand they appear to require that we "discuss" obtaining a license for three years for US $25,000 plus 1.15% of our and our customers' transactions, if we wish to continue hosting web sites that take international orders. The NZ version of the patent was obtained earlier this year. Curiously the target of their attention happens to be a website of ours that does not do actual orders itself but is just a portal, hence my guess that this is part of an broad initial salvo in an attempt to create the "pay up and avoid litigation" response. I want to make contact with other operations who have received a license and royalty demand under NZ Patent 505284 for large sums of money if they wish to continue using basic international web shopping practices. We can probably deflect the particular letter we have received, however if the barristers involved are keen to search out sites that do have some chance of coming under the patent then they should find a virtual cornucopia, as they traverse the sites of your customers and ours. Supposing they succeed in upholding their patent then their requirements would claim a significant percentage of overheads of net traders looking to continue having international ordering/transaction capabilities. Obviously I am sorely disappointed that the NZ Patent Office is granting patents of this kind, and am reviewing both political and legal options for raising this issue in the public eye. Alongside Microsoft's moves to patent .Net APIs we are of course, seeing some serious challenges to developer freedoms, and end user's integration choices, if the arena of intellectual patents is not balanced with concern for open standards in at least some of the world. Well that is off topic now I am sure... I am happy to set up a list for discussing this issue if anyone else is interested, let me know or point me to a pre-existing nz list on this matter. Oh and I'll let you know when I have a patent on the process of running an online charity auction to save ISPs sued by patent attorney's.. :) regards Robert -- Robert Hunt phone +64-3-3645888 Managing Director fax +64-3-3645828 Plain Communications roberth(a)plain.co.nz

7 9

Effective RBL's
by Matthew G Brown 09 Jul '03

09 Jul '03

Does anyone have experience with good RBL's . A client is running Mdaemon and looking to increase the level of SPAM protection. By Default its running relays.osirussoft.com, relays.ordb.com & bl.spamcop.net Anyone have any others that function well ? Best Regards Matthew G Brown Managing Director B & R Holdings LIMITED Nelson, New Zealand Ph: 027 4807731 Http://www.brh.co.nz

5 5

Re: [nznog] Xtra supporting Address harvesting and prompting customers to embed HTML in their e-mail ?
by Malcolm Lockyer 08 Jul '03

08 Jul '03

>From: Steve Phillips <steve(a)focb.co.nz> >To: nznog(a)list.waikato.ac.nz >Subject: [nznog] Xtra supporting Address harvesting and prompting customers >to embed HTML in their e-mail ? >Date: Wed, 09 Jul 2003 14:33:39 +1200 >MIME-Version: 1.0 > >*sigh* <quote> To turn on HTML in your Outlook/Outlook Express On the Tools menu, click Options, and then click the Mail Format tab if on Outlook or the Send tab if on Outlook Express. </quote> (read: turn on the vulnerabilities) Its disturbing to see big companies trying to undo all our customer educating (read: using a cluestick) - it doesn't even meantion why us big government/IT Department/whatever types (read: those of us with a cluestick) don't like HTML mail..! I'd like to see anybody that can figure out how to apply the new crimes bill to spammers - to also use it against companies with pages like this to sort it out - <quote>Start getting everyone's email address now - in every way you can. </quote> *sigh* back to reality. // gets out the flameproof jacket ;) m > >http://xtramsn.co.nz/business/0,,10271-2468719,00.html > >No wonder we have such problems with spam and e-mail worms... > >-- >Steve. > >_______________________________________________ >Nznog mailing list >Nznog(a)list.waikato.ac.nz >http://list.waikato.ac.nz/mailman/listinfo/nznog _________________________________________________________________ Check out the Xtra gaming servers at http://xtramsn.co.nz/gaming !

1 0

Re: [nznog] Multicast status in New Zealand
by Ewen McNeill 08 Jul '03

08 Jul '03

In message <5.2.0.9.0.20030709102145.00b81700(a)pele.citylink.co.nz>, Richard Nayl or writes: >Don't get me wrong, I'm not anti-multicast. I agree its the most efficient >way of distributing a synchronous event. Its just I don't see a lot of >synchronous events...... Which brings me back to where I started -- with a bit of relaxation of the "I must see it NOW" requirement (in the order of a few seconds/minutes) and good client software/hardware, you can turn a bunch of not-quite-synchronous viewings into synchronous events. And thus snatch a multicast win, out of the jaws of a watch-now unicast defeat. This is both with "live" things -- which I agree aren't that common -- and also "near release time" viewings of things which aren't live (where you can expect that something which is recently released, and popular, is most likely to be wanted nearer the release time than later, in some sort of half-bell-curve type model). >Its just as the size of "live" viewer base gets smaller, and bandwidth >higher, multicasting doesn't seem worth the effort. Well I've seen approximately three orders of magnitude (powers of 10) drop in the cost of bandwidth/traffic over the last 10 years or so, and it's still at least two to three orders of magnitude away from the point where I'd be willing to say the "cost" of getting multicasting going isn't worth the value of the saved bandwidth. Generally like RAM space, harddrive space, etc, the uses will expand to fill all the available bandwidth, so using it inefficiently isn't exactly desireable. >If I stream an event for say 10 viewers, why should the rest of the >NZ net get it sent to them without asking for it. Umm, that's not how multicasting works (indeed it's the key difference between multicasting and broadcasting). But I think you know that already. Ewen

4 3

Xtra supporting Address harvesting and prompting customers to embed HTML in their e-mail ?
by Steve Phillips 08 Jul '03

08 Jul '03

*sigh* http://xtramsn.co.nz/business/0,,10271-2468719,00.html No wonder we have such problems with spam and e-mail worms... -- Steve.

1 0

Re: [nznog] legal threats from DE Technologies re web commerce
by David Farrar 08 Jul '03

08 Jul '03

Robert Hunt wrote: > Obviously I am sorely disappointed that the NZ Patent > Office is granting patents of this kind, and am reviewing > both political and legal options for raising this issue in > the public eye. Alongside Microsoft's moves to patent > .Net APIs we are of course, seeing some serious challenges > to developer freedoms, and end user's integration choices, > if the arena of intellectual patents is not balanced with > concern for open standards in at least some of the world. > > Well that is off topic now I am sure... I am happy to > set up a list for discussing this issue if anyone else is > interested, let me know or point me to a pre-existing nz > list on this matter. The issue came up yesterday on InternetNZ's public-discuss list. Archives at http://listserver.internetnz.net.nz/pipermail/public-discuss/2003-July/thre… and list at http://listserver.internetnz.net.nz/mailman/listinfo/public-discuss InternetNZ is considering engaging a QC who is an expert in the intellectual property arena to provide some initial advice on the situation which has arisen. No decision has been taken yet, but InternetNZ would be interested in hearing from anyone else who may be affected by this. At a minimum I am sure we will be happy to help co-ordinate information sharing. DPF (VP and Chair of Legal & Regulatory, InternetNZ)

1 0

Re: [nznog] Netsites Domain Name Changes page offline?
by Ewen McNeill 08 Jul '03

08 Jul '03

In message <Pine.LNX.4.44.0307081250150.6688-100000(a)blue.darkmere.gen.nz>, Lin N ah writes: >On Mon, 7 Jul 2003, Mark Davies wrote: >> [Mark's netsite changes list] >> I got asked on 1 July by Nick Griffin to not publish the changes list until >> some review I wasn't aware of that is apparently currently happening was >> completed. >> >Perhaps the DNC should explain to us why there is a problem with >Mark's excellent netsites page. The explanation I was given was that apparently some spammers had been trawling through the list of new domains to figure out what to look up to pick up a new collection of registrar/registrant/admin/technical contact addresses to spam. Apparently at least one spammer actually claimed to have used Mark's changes list as a source, which is presumably why the interium action was to ask for it to be taken down. As Steven Heath noted, there is a mention in the June Registrar newsletter; and it will be in the minutes from the June NZOC meeting which should be up RSN I'm told (apparently they were overlooked for a while in amongst everything else going on and now just need to be reviewed by NZOC for accuracy). And there should be some sort of call-for-comments coming out relatively soon (sometime in July?). >Is it doing any harm or is it because it isn't published by DNC and so >not sanctioned? Actually as I remember it Mark's site was one of the few that made it onto the original blessed list of those who could still do zone transfers when restrictions were put in place (a couple of years back). AFAICT it's merely the "source of addresses for spam" problem which makes it an issue, rather than "not run by the DNC". Ewen

2 1

RE: [nznog] Effective RBL's
by Michael Bordignon 08 Jul '03

08 Jul '03

> Does anyone have experience with good RBL's . A client is > running Mdaemon and looking to increase the level of SPAM > protection. By Default its running relays.osirussoft.com, > relays.ordb.com & bl.spamcop.net Anyone have any others that > function well ? I use these with exim: rbl_domains = relays.ordb.org/reject:list.dsbl.org/reject:relays.osirusoft.com/warn:blackh oles.easynet.nl\ /reject:bl.spamcop.net/reject:blackholes.five-ten-sg.com/warn Michael

1 0

RE: [nznog] Crimes Amendment Bill No 6 Now Law
by Donald Neal 08 Jul '03

08 Jul '03

> From: Gordon Smith [mailto:gordon(a)morenet.net.nz] > Sent: Wednesday, 9 July 2003 07:47 > To: Donald Neal; nznog(a)list.waikato.ac.nz > Subject: RE: [nznog] Crimes Amendment Bill No 6 Now Law > > > Even when its particularly relevant to network operations? > Like it or not, this is something that does affect our operations. Discussion of operational effects of a new law, based on knowledge of contents of that law - in. Discussion of what might be in that law - generally out. Sysadmins and network engineers seeking to give their opinions of interpretation of an Act - especially bad idea. - Donald Neal List Administrator > > -----Original Message----- > > From: Donald Neal [mailto:Donald.Neal(a)telecom.co.nz] > > Sent: Tuesday, 8 July 2003 3:42 PM > > To: nznog(a)list.waikato.ac.nz > > Subject: RE: [nznog] Crimes Amendment Bill No 6 Now Law > > > > > > Let's just bear in mind that postings of a legal nature are > > discouraged on this list. > > > > - Donald Neal > > List Administrator > ------------------------------------------------------------------------------ "This communication, including any attachments, is confidential. If you are not the intended recipient, you should not read it - please contact me immediately, destroy it, and do not copy or use any part of this communication or disclose anything about it. Thank you." ------------------------------------------------------------------------------

1 0

RE: [nznog] Multicast status in New Zealand
by Michael Sutton 08 Jul '03

08 Jul '03

Point of Technical peturbance Multicast is much more efficient. The data does not flood to every router in New Zealand. Actual data, just like unicast, only routes to those branches of the network where there is actual demand at that instance in time. If there is no downstream client application (player) requesting the data feed, no data will be sent to that location. The only data held by routers is information about the identity of the upstream multicast source, if there is client request. If the demand was only in Wellington the multicast data would not leave Wellington. When someone joins in Auckland then the data would flow to Auckland and no-where-else... When the Auckland users ceases the session data transfer would be pruned back to Wellington while the multicast session continues. Regards Michael Sutton http://www.internetnz.co.nz/members/by-elections/030619byelection.html http://www.internetnz.co.nz/biographies/bio03-msutton.html -----Original Message----- From: Richard Naylor [mailto:richard.naylor(a)citylink.co.nz] Sent: Wednesday, July 09, 2003 10:40 To: Ewen McNeill; Hamish MacEwan Cc: nznog(a)list.waikato.ac.nz Subject: Re: [nznog] Multicast status in New Zealand Its just as the size of "live" viewer base gets smaller, and bandwidth higher, multicasting doesn't seem worth the effort. If I stream an event for say 10 viewers, why should the rest of the NZ net get it sent to them without asking for it. rich _______________________________________________ Nznog mailing list Nznog(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog

1 0

RE: [nznog] Multicast status in New Zealand
by Michael Sutton 08 Jul '03

08 Jul '03

I agree with your take on the issue, Ewen... Further, it is surely in the "National Interest" that multicast be in active operational capability today for the "Public Internet" so that in the event of a future national crisis such as a SARS, Foot and Mouth, Small Pox or when a similar situation occurs the facility can be used to its best technical advantage. It is then important to: communicate, instruct & train, professionals and the public - while reducing close personnel contact. Multicast can be used to provide "low cost" high quality content injection which of itself does not cause degradation of New Zealand network performance at any location during a strategic performance window. Alternatives such as Consumer Digital Satellite TV would cost, at list prices, significant dollars to open up spot channels for a period of days || weeks || months, and in such circumstances the Ministries available discretionary funds would be under severe pressure, and therefore may be excluded as a viable option. However, multicast would help, as the cost of 48hours digital satellite television broadcast might equate to the cost of one years multicast distribution @ 300kbs. During the SARs containment emergency, Beijing and other locations in China closed schools and other education institutions and made children stay home. Their schools used telephones and the Public Internet to conduct distance learning. What would happen in New Zealand if all schools in Auckland and other city locations closed. Multicast was also used to connect SARS support hubs in Asia. Therefore prior to such an emergency, operational multicast services today would enable strategic content provider organisations to distribute current operational materials for capture and/or real-time display and be prepared and confident that such a system can be relied on as a front-line communication capability. So... reliable operation today ensures access when Noah needs an Ark... Nobody will try to implement it the day a Balloon goes UP... Hope you are all having a great conference... Is Joe warbling now... Best Regards Michael Sutton InternetNZ By-election Candidate - Councillor Vote now :) (disgraceful lobby) http://www.internetnz.co.nz/members/by-elections/030619byelection.html http://www.internetnz.co.nz/biographies/bio03-msutton.html -----Original Message----- From: Ewen McNeill [mailto:ewen(a)naos.co.nz] Sent: Tuesday, July 08, 2003 10:06 To: Hamish MacEwan Cc: nznog(a)list.waikato.ac.nz Subject: Re: [nznog] Multicast status in New Zealand <snip> It does, however, seem to me rather counter productive to insist that they must use unicast, must use the bandwidth inefficiently, in order to some how deter this. At best all that's likely to achieve is that there's even less bandwidth available for other things. (Witness allocations of the frequency spectrum to radio, TV, etc, and what's left for ham radio operators.) And to make it even harder for "small operators" to join in -- so bang goes your online equivilent of public access TV (it's just too expensive to get a pipe big enough to unicast it to a reasoanble audience). <snip>.... Indeed. And that survives partly because many people "need" to be at work at the same time, which is largely true because of network effects (eg, you'd like the cafe to be open when you want to get morning tea, and people need to be in the same place at the same time for meetings, etc). And in the same way when something "interesting" happens lots of people are going to "need" to see it at once, if only to keep up with the Jones and be able to talk about it at morning tea the next day. To use your earlier analogy providing more buses/trains/etc can help to reduce this congestion. And in the same way multicasting can help reduce the congestion. But apparently buses/trains/etc are good, and multicasting is bad, for reasons I don't follow.

1 0

Re: [nznog] Multicast status in New Zealand
by Ewen McNeill 08 Jul '03

08 Jul '03

In message <20030708092651.GM4808(a)stuckist.macewan.gen.nz>, Hamish MacEwan writes: >On Sat, Jun 28, 2003 at 13:05 +1200, Ewen McNeill wrote: >> In message <5.2.0.9.0.20030627160856.02023200(a)pele.citylink.co.nz>, Richard Naylor writes: >> >ah - its that word "channel" that I don't see in the future. Such a >> >dated concept. >> >> Ah. Channels are double-plus-ungood. Call it a stream if it makes >> you feel happier. Or VDC or whatever. > >I think Rich's point is broader than "channels," it goes to the notion >of "broadcast," which, while like most things is not going to go away >anytime soon, but the option of obtaining material from P2P or other >sources (Tivo as so aptly observed by Joe) and assembling your own >experience is becoming more feasible, Except that a Tivo listens to (a bunch of) broadcast channels (there, two horrible words in a row!) and caches the "interesting" stuff that it sees for later viewing. The problem, IMHO, is not the broadcasting, or the channels, themselves. It's how people make use of them. Broadcasting is a fairly efficient technique to get information to a whole bunch of people in one go (for them to use now or later). Channels are an efficient way to know which broadcast to listen to for what things. I simply don't buy the argument that says that because the "must watch it when it screens, must watch what they want to show" model of broadcast channels is bad (which I definitely agree with -- I haven't even had a TV for 5+ years), that means that all the components of it (broadcasting, channels, etc) are totally without merit. To get, vaguely, back on topic -- multicasting is just "broadcasting with focus" -- if you like it's a more efficient form of broadcasting for a medium which can handle sending only to interested parties (eg, a packet switched network like the Internet, as opposed to a frequency division "network" like radio waves). >[Spoonfeeding, etc] >This is what makes me leery of attempts to make the Internet a better >broadcast medium than it already isn't. It may make non-broadcast use >more difficult. Unintended consequences, increased core complexity, et al. I'm not especially convinced by this argument either. There's a whole lot of money behind turning the Internet into a "content provision" network -- and I suspect they'll succeed in doing what they want to do irrespective of whether we try to make it more difficult. It does, however, seem to me rather counter productive to insist that they must use unicast, must use the bandwidth inefficiently, in order to some how deter this. At best all that's likely to achieve is that there's even less bandwidth available for other things. (Witness allocations of the frequency spectrum to radio, TV, etc, and what's left for ham radio operators.) And to make it even harder for "small operators" to join in -- so bang goes your online equivilent of public access TV (it's just too expensive to get a pipe big enough to unicast it to a reasoanble audience). [Choose to watch something, join VDC starting it soon] >Yes, like video rental already provides, without the drive there and >back, and PPV on Sky Digital. Yes, like a video rental. Without having to leave the house in the cold of winter. And without having to deal with the fact that some other bastard has taken out the thing you wanted to watch. And, if done properly, without having to watch it all at once so you can return it in time. (I've never seen how PPV on Sky Digital works, so I couldn't say how it compares.) >PS. Road congestion, like unicast broadcast congestion, seems to arise >from the continued belief that we all have to use the road at the same >times (morning and night, Monday-Friday) Indeed. And that survives partly because many people "need" to be at work at the same time, which is largely true because of network effects (eg, you'd like the cafe to be open when you want to get morning tea, and people need to be in the same place at the same time for meetings, etc). And in the same way when something "interesting" happens lots of people are going to "need" to see it at once, if only to keep up with the Jones and be able to talk about it at morning tea the next day. To use your earlier analogy providing more buses/trains/etc can help to reduce this congestion. And in the same way multicasting can help reduce the congestion. But apparently buses/trains/etc are good, and multicasting is bad, for reasons I don't follow. Ewen

2 1

RE: [nznog] Crimes Amendment Bill No 6 Now Law
by Donald Neal 08 Jul '03

08 Jul '03

Let's just bear in mind that postings of a legal nature are discouraged on this list. - Donald Neal List Administrator Donald Neal | Doctor: Did you see what I didn't see? Technical Specialist | Romana: No. Operations Engineering| Doctor: Nor did I. Alcatel NZ Ltd | - Douglas Adams, Shada ------------------------------------------------------------------------------ "This communication, including any attachments, is confidential. If you are not the intended recipient, you should not read it - please contact me immediately, destroy it, and do not copy or use any part of this communication or disclose anything about it. Thank you." ------------------------------------------------------------------------------

5 5

Re: [nznog] Multicast status in New Zealand
by Ewen McNeill 07 Jul '03

07 Jul '03

In message <5.2.0.9.0.20030627160856.02023200(a)pele.citylink.co.nz>, Richard Nayl or writes: >At 03:54 p.m. 27/06/2003 +1200, Ewen McNeill wrote: >>In message <5.2.0.9.0.20030627141054.038683c0(a)pele.citylink.co.nz>, >>Richard Naylor writes: >> >>[Multicast] >> >Well the biggest part of the business is video on demand and that can >> >really only be unicast as getting viewers to agree on what they watch is >> >like agreeing on a TV Channel in a huge flat - hopeless. >> >>[... "on demand" doesn't necessarily mean "instantly" ...] >>Which means that for popular stuff that is "on demand" it might not be >>enough to have one channel with it, where the wait time is, say, 15 >>minutes for it to cycle around -- but it might be fine to have 10-20 >>channels, suitably staggered, where the wait time was 1-2 minutes. > >ah - its that word "channel" that I don't see in the future. Such a dated >concept. Ah. Channels are double-plus-ungood. Call it a stream if it makes you feel happier. Or VDC or whatever. >Instead, you're interested in Alastair Cook. Why should you wait til Monday >at 8:45 every week and then miss it because you were on the phone. I don't recall suggesting that you should. >Hey you have 10 minutes now and would like to catch up with what he said last >Monday (when you were on the phone, remember). So why can't you click in >now and view it ? Your argument seems to be "viewers must be able to view it __NOW__(tm)" and hence we must use unicast for everything in order that everyone can have their whim satisifed at an instants notice (and provide all the bandwidth from source to (multiple) sink(s) to make this possible). My argument is that there's a fair chunk of evidence that says that people would be willing to wait 1, 2, 5, 10, 30, or even 60 seconds for something to start (maybe even longer if it's a sizeable time investment to watch it all and the waiting time can be used productively -- eg, getting that beer out of the fridge before settling down to watch the game), especially given a proper cost/benefit tradeoff ("would you pay 5 times as much to be able to have it start within half a second instead of within 5 seconds"?). And that by adding that relaxing condition it's both quite feasible, and quite benefical, to use multicast at least for the more popular things, especially where the multicast VDCs is set up "on demand" with just a short "setup time" to pull in other potential viewers. Think of it as the difference between everyone just crossing the road when they feel like it, and traffic lights (or at very least waiting for the same gap in the traffic). The big reason that it's beneficial in the popular-to-(re)view situation is that there're more people wanting to view something than there are 5-second, 10-second, 30-second, 60-second, whatever start periods. So you can achieve an N:M reduction in the number of VDC you need originating from the source, for only the price of a bit of management infrastructure (request-a-start-soon), and a slightly slip from the "I wanna watch it now! Now! Now! Mommy, make it go!" instant satisfaction. >Multicast is great for synchronous events like TRADITIONAL tv. I just don't >see that continuing. It's good for things other than traditional TV too. Especially where there's (significantly) more than one person wanting to watch something at the "same" time. Which is a surprisingly common case for "current" events. (Speech replays, sports replays, recent movie releases, etc.) Oh, and I quite agree with Joe's comment that caching at the edge can achieve quite remarkable things in turning "watch now or miss it" into "watch when you feel like it". (And even better, if those with suitable broadcast channels would actually get a clue and use the "down" time to spool out things people might want to watch during the week (eg, "this week's hot new movies"). But "video recorders are bad, we must do everything to defeat the use of video recorders". Furrfu.) Ewen

8 7

RE: [nznog] Crimes Amendment Bill No 6 Now Law
by Stephen Andrew 07 Jul '03

07 Jul '03

----Original Message---- From: Tony McGregor [mailto:tonym(a)cs.waikato.ac.nz] Sent: Tuesday, 8 July 2003 2:46 PM To: Stephen Andrew Subject: RE: [nznog] Crimes Amendment Bill No 6 Now Law > Since access means "make use of any of the resources of the computer > system" and "access without authorisation" includes "directly or > indirectly" didn't the internet just become illegal? > > I have no authorisation to access most of the routers and SNMP > gateways my packets went through to get to you. You can probably get around it using the argument that subsection (2) makes any access at all legal as long as you were given permission to do something first; "(1) Every one is liable to imprisonment for a term not exceeding 2 years who intentionally accesses, directly or indirectly, any computer system without authorisation, knowing that he or she is not authorised to access that computer system, or being reckless as to whether or not he or she is authorised to access that computer system. "(2) To avoid doubt, subsection (1) does not apply if a person who is authorised to access a computer system accesses that computer system for a purpose other than the one for which that person was given access. Presumably this means privelege escalation is legal. By putting up a public web/mail/router service you are implying authorised access for some purpose (viewing a web page, sending an email, making packets go from A to B) thus /any/ use is now legal (as long as it it not dishonest by the terms of the act). -- Andrew This email with any attachments is confidential and may be subject to legal privilege. If it is not intended for you please reply immediately, destroy it and do not copy, disclose or use it in any way.

10 16

Crimes Amendment Bill No 6 Now Law
by David Farrar 07 Jul '03

07 Jul '03

For those interested. INZ will also put a copy of the Act on its website once this is available. DPF "The Crimes Amendment Bill No 6 has now come into force as The Crimes Amendment Act 2003. This Act, amending the 1961 Crimes Act, may potentially affect many internet users and providers. It has been commonly known as the anti-hacking bill. InternetNZ has done a brief paper on aspects of the Act which may affect internet users and providers. The paper is at http://www.internetnz.net.nz/public/committee-reports/ctte-legal-and-regula… or http://tinyurl.com/g9vj ISPs may wish to get professional legal advice on their obligations under the Act. If enough ISPs thought it would be useful, InternetNZ could consider getting generic advice for the industry generally."

4 3

Re: [nznog] Netsites Domain Name Changes page offline?
by Ewen McNeill 07 Jul '03

07 Jul '03

In message <3F095736.9020504(a)paradise.net.nz>, Steven Heath writes: >http://www.netlink.co.nz/~mark/netsites-growth.html [still updated] > >DNC has said since last year 'we are planning to offer .nz stats soon'. >I even offered to do them for free. There are stats in, eg, the DNC Newsletters which are linked from: http://www.dnc.org.nz/index.php?clsid=1&catid=34 ("Newsletters" on the DNC site -- I'm not sure how stable the URL above is.) According to the summaries the stats seem to go back to the start of the year. Alas, they're buried in tables in PDF files and so harder to extract. And in a two-for-one-special: In message <200307071157.XAA0000429877(a)bats.mcs.vuw.ac.nz>, Mark Davies writes: >> [netsite changes suspended pending zone tranfer policy review] > >I got asked on 1 July by Nick Griffin to not publish the changes list until >some review I wasn't aware of that is apparently currently happening was >completed. Interesting. Neither Keith Davidson nor I was able to find an online reference to this review on either the DNC site or the InternetNZ site. Keith Davidson thinks it must have been mentioned only in hard copy form. I've already suggested it'd be nice if such reviews were notified a bit more publically so affected people could comment on them. >Well the growth stats are the primary reason I'm still doing it. The >other pages merely fall out from doing that. Sure. The other pages are the more useful though at least to any non-maths analysis. Especially the search page since the current whois doesn't support any wildcarding. Ewen

2 1

Re: [nznog] Netsites Domain Name Changes page offline?
by David Farrar 07 Jul '03

07 Jul '03

Ewen wrote: > There are stats in, eg, the DNC Newsletters which are > linked from: > > http://www.dnc.org.nz/index.php?clsid=1&catid=34 > According to the summaries the stats seem to go back to > the start of the year. Alas, they're buried in tables in > PDF files and so harder to extract. I have in Excel the stats from 1993 onwards. Mark's stats I have used up until the launch of the SRS. From then on I have gone off the (public) NZRS stats. As under the SRS one can now register a name but not have it in the zone file, the NZRS stats are a couple of hundred higher. They exclude those in the "pending release" category though. If anyone wants a copy, I'm happy to pass over my spreadsheet - even the nice blue graphs for each 2LD :-) > Sure. The other pages are the more useful though at least > to any non-maths analysis. Especially the search page > since the current whois doesn't support any wildcarding. The problem with the changes page is that spammers had started to use them as a source of domain names and e-mail addresses. There were several complaints about a spammer, who said he had got the info off Mark's pages. Hopefully there are ways to minimise or prevent the pages from being of use to spammers, but allow their continued legitimate use. I refer to Mark's pages often and find them a good resource, but as always spammers stuff things up! DPF

1 0

RE: [nznog] Multicast and InternetNZ By-Election - I stand forpro moting mult icast on the Public Network
by Michael Sutton 07 Jul '03

07 Jul '03

Chris The setup of the Multicast Network Border Peering is not hard. The content provider who injects the multicast is protected from unicast server cost overruns, while client customers pay for all their bandwidth and data received. If the tariff is based on bytes then multicast would generate ISP revenue for the network that delivers it to the client. In so far as content providers using multicast: As someone who has concurrently delivered live Radio New Zealand BBC World, XtraMsn Music Channels as well as Compaq || Hewlett Packard and Ministry of Health Live events, all of these content streams, where possible, used dial-in multicast for the Xtra network and would have used multicast via adsl for all events if possible. Michael Auspices & pretence - we will find out :) -----Original Message----- From: Chris Hellberg [mailto:Chris.Hellberg(a)telecom.co.nz] Sent: Monday, July 07, 2003 07:55 To: Joe Abley; Michael Sutton Cc: nznog(a)list.waikato.ac.nz Subject: RE: [nznog] Multicast and InternetNZ By-Election - I stand forpromoting mult icast on the Public Network And with what pretence or auspices would multicast peering be set up between peers? I'm a bit dubious that that apart from the tinker factor, there's nothing to really justify the effort that goes in to setting up MSDP, MOSPF, PIM, etc, so unless someone comes up with a content goldmine and charging regime, most customers of multicast-enabled networks aren't going to care that their traffic has a wierd 224.12.3.4 DA and their ISP gets bandwidth savings from such traffic. All very much my own opinions. Chris -----Original Message----- From: Joe Abley [mailto:jabley(a)automagic.org] Sent: Mon 7/7/2003 4:51 PM To: Michael Sutton Cc: nznog(a)list.waikato.ac.nz Subject: Re: [nznog] Multicast and InternetNZ By-Election - I stand forpromoting mult icast on the Public Network On Monday, Jul 7, 2003, at 00:08 Canada/Eastern, Michael Sutton wrote: > I am standing as a Candidate for Councillor on a platform to encourage > IP4 multicast peering and service to users of the public Internet in > New Zealand. There is significant effort within InternetNZ to > encourage NGI and IP6, however, this can not provide immediate public > access to multicast services. I'm interested to know what influence you think the InternetNZ council has over network operators, and how they might dictate what protocols operators decide to deploy in their networks. Joe _______________________________________________ Nznog mailing list Nznog(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog ---------------------------------------------------------------------------- -- "This communication, including any attachments, is confidential. If you are not the intended recipient, you should not read it - please contact me immediately, destroy it, and do not copy or use any part of this communication or disclose anything about it. Thank you." ---------------------------------------------------------------------------- --

2 1

Abuse desk responses
by Steve Phillips 07 Jul '03

07 Jul '03

Has anyone else here had problems with NZ ISP abuse complaint responses ? mainly in response to SPAM reports where they refuse to do anything until they get blacklisted but also covering network abuse (DOS type scenario's and the like) ? It appears that abuse complains are more and more regularly falling on deaf ears where the person/team handling the abuse desk seems more concerned with pointing out how it is not their problem than actually trying to educate their end users as to correct practices. This does not appear to be restricted to smaller ISP's either as the main offender (though not limited to) in this case appears to be paradise. -- Steve.

18 22

Multicast and InternetNZ By-Election - I stand for promoting mult icast on the Public Network
by Michael Sutton 07 Jul '03

07 Jul '03

Remembering our postings on multicast over the several past weeks... I have been motivated to act.. Please excuse my partly OT posting with a multicast bias... Many of you are extremely busy this week with the Conference and it may pass attention of those who are also members of InternetNZ that a By-election is occurring for Secretary and Councillor. Voting closes on the 14th July. I am standing as a Candidate for Councillor on a platform to encourage IP4 multicast peering and service to users of the public Internet in New Zealand. There is significant effort within InternetNZ to encourage NGI and IP6, however, this can not provide immediate public access to multicast services. If elected I will make every effort to encourage implementation of multicast services via public networks. I encourage those of you who are InternetNZ members to review the candidates and cast your vote. Please e-mail off-line or call directly if you want to speak with me on this matter. I enclose links to my bio etc... Best Regards... Michael Sutton http://www.awacs.co.nz http://www.internetnz.co.nz/biographies/bio03-msutton.html http://www.internetnz.co.nz/members/by-elections/030619byelection.html

3 2

Netsites Domain Name Changes page offline?
by Bruce Fitzsimons 06 Jul '03

06 Jul '03

Hi everyone, Can anyone shed any light on why the useful, but not-that-well-known page at: http://webpages.netlink.co.nz/~mark/netsites-changes.html is off line? Who is the NZOC? I guess lots of people doing the same thing would be bad, but this page has been around for yonks. Its very interesting to review from time to time, even if its just for a giggle about the weird domain names people choose (and later release back to the world, my my we're lucky). Thanks /Bruce

3 2

Re: [nznog] Netsites Domain Name Changes page offline?
by Ewen McNeill 06 Jul '03

06 Jul '03

In message <05a801c3446e$cb07c040$0a21970a(a)norris>, "Bruce Fitzsimons" writes: >Can anyone shed any light on why the useful, but not-that-well-known page at: > >http://webpages.netlink.co.nz/~mark/netsites-changes.html > >is off line? Who is the NZOC? NZOC == New Zealand (DNS) Oversight Committee, which is the committee in InternetNZ which "oversees" the Domain Name Commissioner's office. I wasn't aware that they were (still) conducting a review (again), and Mark's "changes" list seems (at first glance) to be consistent with the existing zone transfer policies. I know that Mark updated those scripts recently ('cause I prompted him to do so, since some links were out of date including the ones for whois) -- maybe it just picked up a copy of a "in progress" version of the script generating the changes file? >I guess lots of people doing the same thing would be bad, but this page has >been around for yonks. As I understand it, that was the main reason (in an earlier interation of setting zone transfer restrictions) for allowing Mark's scripts to keep going -- it was one point where people could look for changes, rather than everyone doing their own zone transfers. Ewen

1 0

Conference Attendance
by Simon Lyall 06 Jul '03

06 Jul '03

A quick question but are the sessions being recorded and available for later download? I've noticed a couple of sessions I'm interested in opposite each other and also had queries from people at ihug not attending (who said they like watching nanog recorded sessions). I got feedback from a couple of people (one attending, one not) after my requested on Thursday. Both said that the conference is "mainly being a chance to sit in a room with other engineers and sort out new fun stuff." The one who wasn't going said there wern't enough sessions they were interested in (or more directly related to their work) to convince their boss to let them have time off and/or pay for them. "So what would work consider worthwhile? More bleeding edge technology stuff, new product things, more seriously detailed technology discussions (eg a panel about QoS and the various algorithms used and why, might be something that'd attract the Telco types). " -- Simon Lyall. | Newsmaster | Work: simon.lyall(a)ihug.co.nz Senior Network/System Admin | Postmaster | Home: simon(a)darkmere.gen.nz Ihug Ltd, Auckland, NZ | Asst Doorman | Web: http://www.darkmere.gen.nz

1 0

Re: Hackers Challenge started at 1500 NZ time
by Dominic O'Hare 06 Jul '03

06 Jul '03

The owner of the site is in Ft Lauderdale, Florida. ----- Original Message ----- From: <nznog-request(a)list.waikato.ac.nz> To: <nznog(a)list.waikato.ac.nz> Sent: Monday, July 07, 2003 7:13 AM Subject: Nznog Digest, Vol 7, Issue 13 > Send Nznog mailing list submissions to > nznog(a)list.waikato.ac.nz > > To subscribe or unsubscribe via the World Wide Web, visit > http://list.waikato.ac.nz/mailman/listinfo/nznog > or, via email, send a message with subject or body 'help' to > nznog-request(a)list.waikato.ac.nz > > You can reach the person managing the list at > nznog-owner(a)list.waikato.ac.nz > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Nznog digest..." > > > Today's Topics: > > 1. Re: Conference Attendance (Andy Gardner) > 2. Hackers Challenge started at 1500 NZ time (Peter Macaulay) > 3. RE: Abuse desk responses (Neil Gardner) > 4. Re: Abuse desk responses (Michael Hallager) > 5. Re: Abuse desk responses (Edward Yardley) > 6. Re: Hackers Challenge started at 1500 NZ time (Dan Clark) > 7. Re: Hackers Challenge started at 1500 NZ time (Keith Davidson) > 8. Re: Hackers Challenge started at 1500 NZ time (Peter Macaulay) > 9. Re: Hackers Challenge started at 1500 NZ time (Mark Thompson) > 10. Re: Abuse desk responses (Russell Fulton) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 6 Jul 2003 00:28:38 -0500 > From: Andy Gardner <andy(a)navigator.co.nz> > Subject: Re: [nznog] Conference Attendance > To: <nznog(a)list.waikato.ac.nz> > Message-ID: <B273F2FC-AF72-11D7-93B2-000393ABF064(a)navigator.co.nz> > Content-Type: text/plain; charset=US-ASCII; format=flowed > > > On Friday, July 4, 2003, at 05:07 AM, Keith Davidson wrote: > > > I'll also be at Unforum for a couple of days, just to rub noses with > > the > > penguin huggers :-) Look forward to putting some names to faces, > > and to > > heckling Joe Abley at every opportunity ... > > > Gee, and here I was thinking you were doing a talk on how to destroy > nz.general through incessant punning. > > > > ------------------------------ > > Message: 2 > Date: Sun, 06 Jul 2003 17:59:02 +1200 > From: Peter Macaulay <exe.dir(a)internetnz.net.nz> > Subject: [nznog] Hackers Challenge started at 1500 NZ time > To: "members-discuss >> InternetNZ Members Discussion List" > <members-discuss(a)internetnz.net.nz>, nznog <nznog(a)list.waikato.ac.nz> > Message-ID: <3F07BAA6.2030505(a)internetnz.net.nz> > Content-Type: text/plain; charset=us-ascii; format=flowed > > > -- > Peter Macaulay > Executive Director > InternetNZ > Direct +64 4 495 2113 > > > ------------------------------ > > Message: 3 > Date: Fri, 4 Jul 2003 16:08:46 +1200 > From: "Neil Gardner" <neil(a)neilnz.com> > Subject: RE: [nznog] Abuse desk responses > To: <nznog(a)list.waikato.ac.nz> > Message-ID: <000001c341e1$f7806620$6b63a8c0(a)delta> > Content-Type: text/plain; charset="us-ascii" > > >-----Original Message----- > >From: Steve Phillips [mailto:steve(a)focb.co.nz] > >Has anyone else here had problems with NZ ISP abuse complaint responses > ? > >mainly in response to SPAM reports where they refuse to do anything > until > >they get blacklisted but also covering network abuse (DOS type > scenario's > >and the like) ? > > Yep, although in most cases it appears to be from a lack of organisation > in getting the complaints to the right person rather than a systemic > neglect of the issue. Recently I tried for 2 weeks through proper > channels to get an obviously infected ADSL customer disabled and > informed of their problem, to no avail, and culminating in the Helpdesk > telling me that the Abuse people only worked form midnight to 8am a > couple of days a week!!!! > > Obviously what he meant was that the person that dealt with it in the > NOC was next rostered on for a midnight to 8am shift, but it's NOT what > he said. > > Anyway, I posted the details on this list and someone from the > appropriate ISP saw it and had the issue resolved in 30 minutes. > > But there should be some sort of internally monitored helpdesk with > escalation for complaints like that - I know of a number of (admittedly > corporate and not cheap - HEAT and Magic spring to mind) that do this > sort of thing very well). > > Out of interest, are any ISP reps here prepared to admit how they track > issues, specifically something like complaints to abuse(a)isp.co.nz where > there could be a lot of incoming jobs? > > Cheers - Neil G > > > > ------------------------------ > > Message: 4 > Date: Sun, 6 Jul 2003 21:18:51 +1200 > From: Michael Hallager <michael(a)networkstuff.co.nz> > Subject: Re: [nznog] Abuse desk responses > To: "Neil Gardner" <neil(a)neilnz.com> > Cc: nznog(a)list.waikato.ac.nz > Message-ID: <200307062118.51406.michael(a)networkstuff.co.nz> > Content-Type: text/plain; charset="iso-8859-1" > > Hello, > > At Vivid Computers / Vivid Net, all abuse(a)vivid.net.nz email comes to myself > - as the Systems Administrator - for prompt action. > > Michael Hallager > Networkstuff Limited > http://www.networkstuff.co.nz > > > >-----Original Message----- > > > > From: Steve Phillips [mailto:steve(a)focb.co.nz] > > > > >Has anyone else here had problems with NZ ISP abuse complaint responses > > > > ? > > > > >mainly in response to SPAM reports where they refuse to do anything > > > > until > > > > >they get blacklisted but also covering network abuse (DOS type > > > > scenario's > > > > >and the like) ? > > > > Yep, although in most cases it appears to be from a lack of organisation > > in getting the complaints to the right person rather than a systemic > > neglect of the issue. Recently I tried for 2 weeks through proper > > channels to get an obviously infected ADSL customer disabled and > > informed of their problem, to no avail, and culminating in the Helpdesk > > telling me that the Abuse people only worked form midnight to 8am a > > couple of days a week!!!! > > > > Obviously what he meant was that the person that dealt with it in the > > NOC was next rostered on for a midnight to 8am shift, but it's NOT what > > he said. > > > > Anyway, I posted the details on this list and someone from the > > appropriate ISP saw it and had the issue resolved in 30 minutes. > > > > But there should be some sort of internally monitored helpdesk with > > escalation for complaints like that - I know of a number of (admittedly > > corporate and not cheap - HEAT and Magic spring to mind) that do this > > sort of thing very well). > > > > Out of interest, are any ISP reps here prepared to admit how they track > > issues, specifically something like complaints to abuse(a)isp.co.nz where > > there could be a lot of incoming jobs? > > > > Cheers - Neil G > > > > > > _______________________________________________ > > Nznog mailing list > > Nznog(a)list.waikato.ac.nz > > http://list.waikato.ac.nz/mailman/listinfo/nznog > > -- > Michael Hallager > Managing Director > Networkstuff Limited > > http://www.networkstuff.co.nz > michael @ networkstuff.co.nz > > > ------------------------------ > > Message: 5 > Date: Sun, 6 Jul 2003 21:58:57 +1200 > From: "Edward Yardley" <edward(a)edan.co.nz> > Subject: Re: [nznog] Abuse desk responses > To: <nznog(a)list.waikato.ac.nz> > Message-ID: <011501c343a5$37e58780$3d00000a(a)sebastian> > Content-Type: text/plain; charset="iso-8859-1" > > I've found the same thing with Paradise/Telstra Clear's responses. > > Edward. > ----- Original Message ----- > From: <nznog(a)neilnz.com> > To: <nznog(a)list.waikato.ac.nz> > Sent: Friday, July 04, 2003 4:15 PM > Subject: RE: [nznog] Abuse desk responses > > > > >-----Original Message----- > > >From: Steve Phillips [mailto:steve(a)focb.co.nz] > > >Has anyone else here had problems with NZ ISP abuse complaint responses > > ? > > >mainly in response to SPAM reports where they refuse to do anything > > until > > >they get blacklisted but also covering network abuse (DOS type > > scenario's > > >and the like) ? > > > > Yep, although in most cases it appears to be from a lack of organisation > > in getting the complaints to the right person rather than a systemic > > neglect of the issue. Recently I tried for 2 weeks through proper > > channels to get an obviously infected ADSL customer disabled and > > informed of their problem, to no avail, and culminating in the Helpdesk > > telling me that the Abuse people only worked form midnight to 8am a > > couple of days a week!!!! > > > > Obviously what he meant was that the person that dealt with it in the > > NOC was next rostered on for a midnight to 8am shift, but it's NOT what > > he said. > > > > Anyway, I posted the details on this list and someone from the > > appropriate ISP saw it and had the issue resolved in 30 minutes. > > > > But there should be some sort of internally monitored helpdesk with > > escalation for complaints like that - I know of a number of (admittedly > > corporate and not cheap - HEAT and Magic spring to mind) that do this > > sort of thing very well). > > > > Out of interest, are any ISP reps here prepared to admit how they track > > issues, specifically something like complaints to abuse(a)isp.co.nz where > > there could be a lot of incoming jobs? > > > > Cheers - Neil G > > > > > > _______________________________________________ > > Nznog mailing list > > Nznog(a)list.waikato.ac.nz > > http://list.waikato.ac.nz/mailman/listinfo/nznog > > > > > ------------------------------ > > Message: 6 > Date: Sun, 6 Jul 2003 22:17:22 +1200 > From: "Dan Clark" <dan(a)scarfies.net> > Subject: Re: [nznog] Hackers Challenge started at 1500 NZ time > To: "Peter Macaulay" <exe.dir(a)internetnz.net.nz>, "members-discuss >> > InternetNZ Members Discussion List" > <members-discuss(a)internetnz.net.nz>, "nznog" > <nznog(a)list.waikato.ac.nz> > Message-ID: <00be01c343a7$d49611b0$150210ac(a)morpheus> > Content-Type: text/plain; charset="iso-8859-1" > > Hi all, > Any examples of defaced sites??? > > Regards > Dan > > > ----- Original Message ----- > From: "Peter Macaulay" <exe.dir(a)internetnz.net.nz> > To: "members-discuss >> InternetNZ Members Discussion List" > <members-discuss(a)internetnz.net.nz>; "nznog" <nznog(a)list.waikato.ac.nz> > Sent: Sunday, July 06, 2003 5:59 PM > Subject: [nznog] Hackers Challenge started at 1500 NZ time > > > > > > -- > > Peter Macaulay > > Executive Director > > InternetNZ > > Direct +64 4 495 2113 > > > > _______________________________________________ > > Nznog mailing list > > Nznog(a)list.waikato.ac.nz > > http://list.waikato.ac.nz/mailman/listinfo/nznog > > > > > ------------------------------ > > Message: 7 > Date: Sun, 6 Jul 2003 22:39:28 +1200 > From: "Keith Davidson" <keith(a)wise.net.nz> > Subject: Re: [nznog] Hackers Challenge started at 1500 NZ time > To: "nznog" <nznog(a)list.waikato.ac.nz> > Message-ID: <00d901c343aa$e0970200$4db724ca(a)wise.net.nz> > Content-Type: text/plain; charset="iso-8859-1" > > > Hi all, > > Any examples of defaced sites??? > > www.scarfies.net :-) > > I still can't get through to www.defacers-challenge.com, which was supposed > to be listing the hacked sites... > > Keith Davidson > > > > ------------------------------ > > Message: 8 > Date: Sun, 06 Jul 2003 23:00:10 +1200 > From: Peter Macaulay <exe.dir(a)internetnz.net.nz> > Subject: Re: [nznog] Hackers Challenge started at 1500 NZ time > Cc: nznog <nznog(a)list.waikato.ac.nz> > Message-ID: <3F08013A.8070405(a)internetnz.net.nz> > Content-Type: text/plain; charset="us-ascii" > > Haven't seen any yet and zone-h showed only a slight increase before the > DNOS attack clogged their 100mb totally. The originator runs a > 'brazilian' site based out of the US, and his/her email is from > somewhere in France. The Estonian link is for the time of the challenge > and the time is according to zone-h which is estonian (Tallin) > ;-) Just showing I have done my homework before putting on the makeup > and getting demolished by Hoskin and Hawkesbury. > > Keith Davidson wrote: > > >>Hi all, > >> Any examples of defaced sites??? > >> > >> > > > >www.scarfies.net :-) > > > >I still can't get through to www.defacers-challenge.com, which was supposed > >to be listing the hacked sites... > > > >Keith Davidson > > > > > >_______________________________________________ > >Nznog mailing list > >Nznog(a)list.waikato.ac.nz > >http://list.waikato.ac.nz/mailman/listinfo/nznog > > > > > > -- > Peter Macaulay > Executive Director > InternetNZ > Direct +64 4 495 2113 > >

1 0

Hackers Challenge started at 1500 NZ time
by Peter Macaulay 06 Jul '03

06 Jul '03

-- Peter Macaulay Executive Director InternetNZ Direct +64 4 495 2113

5 5

Conference Attendance
by Tony McGregor 05 Jul '03

05 Jul '03

There will be a bunch of people there from the WAND group. The speaker discounts made it possible for us. Can someone confirm that there will be connectivity (inc wireless) at the conference? Tony ---------------------------------------------------------------------------- Tony McGregor Mail: T.McGregor(a)cs.waikato.ac.nz Department of Computer Science Phone: +64 7 838 4651 Waikato University Fax: +64 7 858 5095(w) +64 7 825 5047(h) Private Bag 3105 Home: +64 7 825 5040 mobile: (021)313004 Hamilton, New Zealand www: http://www.cs.waikato.ac.nz/~tonym ----------------------------------------------------------------------------

6 6

Net4U Thread
by Donald Neal 03 Jul '03

03 Jul '03

The current (or immediately past?) thread dealing with Net4U contains some postings which are clearly within this list's acceptable use policy, and some which are not. In brief, postings which discuss operational or technical issues - and an ISP using spam to advertise does look to me like one of those - are in. Postings containing "character assassination or lack of respect for other participants" are out. Whether they cause deformation or not. For myself, I'd like to see no further additions to the thread unless they come from people who have something new and relevant to say. - Donald Neal ex cathedra, or something Donald Neal | Doctor: Did you see what I didn't see? Technical Specialist | Romana: No. Operations Engineering| Doctor: Nor did I. Alcatel NZ Ltd | - Douglas Adams, Shada ------------------------------------------------------------------------------ "This communication, including any attachments, is confidential. If you are not the intended recipient, you should not read it - please contact me immediately, destroy it, and do not copy or use any part of this communication or disclose anything about it. Thank you." ------------------------------------------------------------------------------

2 1

WTB: APE bandwidth
by Michael Hallager 03 Jul '03

03 Jul '03

Hello all, Could ISP's that have connections to the APE please contact me with their prices for bandwidth to equipment located at APE. Kind regards, Michael Hallager Managing Director Networkstuff Limited http://www.networkstuff.co.nz michael @ networkstuff.co.nz

1 0

Re: [nznog] APE Peering
by - 03 Jul '03

03 Jul '03

Sahil said to me, as well as publically on the site that the "auditor's" report would be made available publically on the website. After a number of months I saw him again, and casually asked, whats up with that auditor's report, and he shrugged it off, as if to say "that was a joke". Secondly Sahil obviously did know about it, so shrugging it off as his staff's fault is amusing in the least

9 11

RE: [nznog] APE Peering
by Chris O'Donoghue 03 Jul '03

03 Jul '03

Well perhaps you should work on your management a bit more. It took all of about 5 seconds to convince me that this was worthwhile for my sysadmins to attend. But then again maybe I'm biased, cos I went last year. Chris Chris O'Donoghue Technology Manager Online & Digital TVNZ -----Original Message----- From: Jeremy Brooking [mailto:jeremy(a)morenet.net.nz] Sent: Friday, 4 July 2003 1:01 p.m. To: Simon Lyall Cc: nznog(a)list.waikato.ac.nz Subject: Re: [nznog] APE Peering Simon Lyall wrote: ><grump> >By which I assume you make less than $20,000 per year and live in central >Auckland. Seriously it's $250 per day, if you go on two days thats $500 >bucks. $20/per weeek if you started saving at the start of the year when >this was first mentioned (and I think I told people to start saving). > >If you present you get that day free. If you talk your work into a 5% >training budget then it'll cover it. > >Exactly what sort of pricing could you afford? I remmeber the little ISP >forum that Internetnz had a couple of years back, that was $50 per day and >nobody much attended. ></grump> > > Perhaps my _insane_ comment was a bit of an overstatement. First post I saw regarding it was 9th of 3rd. So that would make it about $50 a week. And of course, we all have $50 spare a week dont we? _______________________________________________ Nznog mailing list Nznog(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog ================================================================ CAUTION: This e-mail and any attachment(s) contains information that is intended to be read only by the named recipient(s). It may contain information that is confidential, proprietary or the subject of legal privilege. This information is not to be used by any other person and/or organisation. If you are not the intended recipient, please advise us immediately and delete this e-mail from your system. Do not use any information contained in it. ================================================================ For more information on nzoom.com, visit us online at http://www.nzoom.com ================================================================

1 0

Netforum - I'm in !
by Tim John 03 Jul '03

03 Jul '03

> On another note, Whos going to Netforum? > A quick survey of Auckland Thursday Night Curry attendees didn't look too > promising.. Chris and I from Domainz are coming up for the Thursday and Friday. We'll be the ones hiding in the shadows :) We're looking forward to Joe's presentation ... and of course the curry on Thursday ! Tim DISCLAIMER: The content of this email is confidential and may contain legally privileged information intended only for the individual or entity named above. Access to this message by anyone else is unauthorised. If you are not the intended recipient, please be advised that the use, distribution and publication of the above information is prohibited. If you have received this email in error, please contact Domainz by returning the email and destroying the original. Thank you.

2 1

19" Cases.....
by Roger De Salis 03 Jul '03

03 Jul '03

I have built two self assembly 19" cases, simply designed to be a simple as possible, and extremely low cost. Unit One, 2.5RU (ie the same height as a standard PCI card.) 450mm deep. Accepts standard power supply, any ATX board (full, mini, micro). Combos are Std CDROM + Floppy + 6 drives OR up to 10 disk drives without CDROM/Floppy Assembly. No risers. One case fan (included). Unit Two, Same Height as standard ATX power supply 90mm, 2RU, 275mm deep. Accepts micro ATX board only. Accepts Standard ATX power supply. Accepts laptop 1/3high floppy and CDROM (which I can supply if required) $169 for CD, $79 for floppy. Accepts 1/2 high PCI Cards only. No risers Unit Two currently supports 1 x 3.5" DD and 3 x 2.5"DD. Production version will likely be modded to accept 2 x 3.5"DD and 2 x 2.5" DD ========================================================== Removable 19" Rack wings on both. Mounting combinations are: Flush front, recess 50mm, centre pillar mount, or reverse mount, and 50mm recessed reversed. The intention is to place a full shelf underneath the base unit, then I would not have any qualms about 4-5 racked up on top of each other. There is currently no provision for slides, but if someone was desperate..... Henry Ford Colour scheme. NZ$260+GST complete with PSU, wiring assembly pwr/hdd assy, screws. Netforum Special NZ$230+GST. I'll have three units on show at the Waipuna next week if someone wants to look/dicuss. The second small unit was intended to complement Cisco 2600 in a rack, but also be the right size for home stereo with silent PSU and 2.5"DDs, so if you want to buy your own power supply, knock $35 off the price. Further discounts for quantity (ie 4up.) If you want to buy just the metalwork, and make up your own, happy to oblige... Basically I run them as telephone controllers, log servers etc etc, with a Duron 1300, MSI 6787 board with LAN on-board, single drive and CD for approx $700, rack mounted with a 2 year warranty on everything. About 14 day delivery. I'll include a couple of JPEG's later this morning. Rgds Roger De Salis -- \_ Roger De Salis rdesalis(a)fx.net.nz </' FX Networks +64 25 481 452 /) Wellington, New Zealand roger(a)desalis.gen.nz (/ ` Bentley win Le Mans! - What next, English win cricket in Aus?

1 0

Net4U's earlier actions
by Sahil Gupta - NET4U LIMITED 02 Jul '03

02 Jul '03

Hi, Firstly, I'd like to apologise for actions made earlier during the day with respect to a mailout to a certain group of ISP's. I wasnt thinking clearly when I thought to add a few more addresses to the mailout to existing contacts. My bad, wont be repeated. As Richard has suggested, if anyone has any concerns or issues that need addressing, please contact us off-list. Just for those that were concerned, issues with abuse(a)net4u.co.nz have now been resolved. Once again, my apologies for the drama here in NZNOG. Regards, Sahil Gupta Senior Account Manager NET4U LIMITED Phone: 0508-263-848 Fax: 07-8582659 Mobile: 029-366-6375

1 0

RE: [nznog] APE Peering
by Richard Parkinson 02 Jul '03

02 Jul '03

You have some valid points here. The whole thing is quite disappointing, and for many, quite frustrating. This abuse(a)net4u is also becoming a sore point, and clearly there has been an issue with this address. I can only chase up as much as was passed on to me. There are a number of other recommended tasks which were to be carried out but have not :( Please contact me off-list with more details, and I will be happy to deal with things. As I said, I'm sill helping Net4U (Unpaid I might add) here and there when I am not involved with my regular clients. If anyone else is reading this and has ANY issues with Net4U that have been ignored, please feel free to contact me off-list or directly on 021409987, and I will to my best to deal with things. This is not the place for this nonsense, so lets get all this off-list, contact me, and lets get everyone happy. If no one has any other abuse they want to throw this way, perhaps we can move back to other interesting threads such as Multicast which I enjoyed following? How about why ISP's should/shouldn't be able to control assignment of IP addresses on ADSL Starter? Anyone have any views on this? Cheers, Richard. -----Original Message----- From: Dave Howes [mailto:mish(a)doomx.net] Sent: Thursday, 3 July 2003 6:49 p.m. To: nznog(a)list.waikato.ac.nz Subject: Re: [nznog] APE Peering I think we should all take a good look at ourselves, and the motivation behind the pettiness that from time to time, makes me wonder just how many children play on this list, and how many people are here to get work/business done. Lets just get on with our work please everyone. Each time the topic of Net4u has come up I've resisted posting as previously the entire situation was already at boiling point, but suggesting people are here to play when they're obviously just frustrated by actions that they see as detremental and disrespectful to other New Zealand Network Operators really rubs me the wrong way. Net4u does seem to be operating in a more legal fashion than before but they're still not admin friendly by any stretch of the imagination. I've received spam from net4u customers to domains I previously managed, I contacted Net4u to advise them of this ( abuse(a)net4u.co.nz) but have never received any response. I was also informed of a 'hole' in their security through which anyone can log into the net4u network and gain free ADSL service by use of an 'admin' account, I emailed the administrator of net4u to advise of this but despite sending two emails I never received a response and (I just tested) the hole still seems to be wide open. I'm glad you see the spam from Net4u as a bad thing as even though the operators of Net4u are (reasonably) new to the game, in this 'net enabled' age even the newest player has no excuse for thinking that unsolicited commercial email to a soa address is a good idea, the same goes for their previous dubious actions. You can feel free to view comments like these as 'pettiness' but I for one am glad to be informed of the actions (or inaction) of New Zealand ISPs even if the observations are at times coloured by external factors. -- Regards, Dave Howes.

1 0

LOL - Tis so odd.....
by Michael Hallager 02 Jul '03

02 Jul '03

Richard's entire post looks clearly like a Sahil marketing effort: COPY We have made a brief report which is not for public viewing, but which has identified a small number of issues on the Net4U network (which were quickly rectified) that were as a result of previous employees. We found nothing that was causing deliberate loss of bandwidth to any other party. We did not fully complete the work due to budget restraints, however we did cover most of the important aspects. Some of our recommendations have been implemented, and sadly others have not been done, but Net4U are operating somewhat better than they were. /COPY YEAH RIGHT. We all have the MP3 of Sahil BOASTING about taking bandwidth. How do you reconcile that with your above claim? I think we would all like the answer. Sahil also ropes his friends into fronting for him, including doing the following actions, both people have admitted that Sahil got them to contact me: 1) Sending me an abusive email 2) Contacting me to rent several thousand dollars worth of equipment that I would never loan to Sahil. COPY > I can assure you the bandwidth offered by Net4U in that "distributed" > email is legitimate, and I should warn you that continued accusations > and alligations are a direct attack against me and my company, which > left Net4U operating legally and above board, and there is no > justification for this blatant deformation. /COPY Don't like the heat, get out of the fire. You knew full well what you were getting into when you associated yourself with Net4u by doing this contracting job. COPY It doesn't take much for everyone to see that some of you are making an issue simply because it's Sahil and Net4U, and because you were a reject at school who was picked on and bullied, and now have a psychological disorder resulting in you playing out the role of your boyhood deamon from school, dishing out what you received. /COPY OK, whatever. I have a small **** or a demon or whatever (This is starting to sound like whacky religious stuff). How did you KNOW??? Michael Hallager Managing Director Networkstuff / Comsolve

1 0

RE: [nznog] APE Peering
by Richard Parkinson 02 Jul '03

02 Jul '03

Thanks Dan. There are one or two ISP's and their administrators out there that have been VERY generous, sympathetic and helpful towards Sahil & Net4U and yet more who have been giving Net4U advise, and telling him off when needed :). As I say, Net4U are "growing up" slowly, but like me, are bound to make mistakes along the way. I enjoy helping others where help is needed, but sometimes this pisses other people off, especially those that don't think that particular person or business deserves to be helped or to get ahead, and I'm not just talking about Net4U. Anyway, rest assured, he has just had a verbal assault from me for yet again, not thinking carefully and using common sense before acting. ie sending Spam etc Thanks for your patience and understanding everyone. He wont be doing that again. :) Cheers, Richard. -----Original Message----- From: Dan Clark [mailto:dan(a)scarfies.net] Sent: Thursday, 3 July 2003 4:04 p.m. To: Richard Parkinson; nznog(a)list.waikato.ac.nz Subject: Re: [nznog] APE Peering I have to agree with Richard here, the problem is the young man who set this particular ISP up has historicly been ignorant as to some of the ethical rules and unwritten policy's of the internet community. We all make mistakes and maybe he just needs a little guidance and support from fellow ISP's who, will no doubt have started from penny's in the early days themselves. Regards Dan Clark Network Manager Scarfies.Net Ltd ----- Original Message ----- From: Richard <mailto:Richard(a)sigel.co.nz> Parkinson To: nznog(a)list.waikato.ac.nz Sent: Thursday, July 03, 2003 3:35 PM Subject: RE: [nznog] APE Peering We have made a brief report which is not for public viewing, but which has identified a small number of issues on the Net4U network (which were quickly rectified) that were as a result of previous employees. We found nothing that was causing deliberate loss of bandwidth to any other party. We did not fully complete the work due to budget restraints, however we did cover most of the important aspects. Some of our recommendations have been implemented, and sadly others have not been done, but Net4U are operating somewhat better than they were. We no longer oversee the operation of Net4U, but have kept in touch with them, and assist with other matters both business related and technical, and feel Net4U & Sahil are slowly "growing up" so to speak, but I expect mystiques will still be made from time to time. None of us are perfect. I can assure you the bandwidth offered by Net4U in that "distributed" email is legitimate, and I should warn you that continued accusations and alligations are a direct attack against me and my company, which left Net4U operating legally and above board, and there is no justification for this blatant deformation. I must say that I also disagree with the method of advertising chosen. Had I been consulted I would have recommended against it, but in saying that, I welcome email in my inbox that relates directly to my line of business and would rather receive such email as opposed to the ones about increasing the size of certain body parts or some other "amazing offer" which we see all to often of late, depending on how good your mail filters are. It doesn't take much for everyone to see that some of you are making an issue simply because it's Sahil and Net4U, and because you were a reject at school who was picked on and bullied, and now have a psychological disorder resulting in you playing out the role of your boyhood deamon from school, dishing out what you received. Without naming anyone, I would also like to point out that there are those of you on this list making such accusations who are the last people to do so, or should we raise the matter of a VAST amount of bandwidth stolen from Telecom for a number of months, by a much larger ISP than Net4U, who even taught another ISP's network administrator how to do it only days before Telecom figured it all out... or perhaps I could send the list a copy of some forged court documents? To these few people I say, I suggest you stop stirring the pot and leave the past alone, or you will get more than just a little of it on you. I think we should all take a good look at ourselves, and the motivation behind the pettiness that from time to time, makes me wonder just how many children play on this list, and how many people are here to get work/business done. Lets just get on with our work please everyone. Cheers, Richard Parkinson (Director) Sigel Data Systems Ltd. -----Original Message----- From: Craig Whitmore [mailto:lennon(a)orcon.net.nz] Sent: Thursday, 3 July 2003 2:13 p.m. To: nznog(a)list.waikato.ac.nz; Steve Phillips Subject: Re: [nznog] APE Peering If anyone had forgotten, where is the "Report" from Sigel Systems about Net4u's runnings over the last 3 months. I believe the impartial 3rd party was hired as one of net4u's staff a very short while after (so couldn't be impartial) Thanks Craig > >> >[snippage] > > > We can deliver using several methods as I've outlined above and can also > > > take care of transporting your existing I.P. Address ranges supplied to > > > you by your current provider to us. > > That would be a neat trick. Almost worth taking him up on that just to > watch him fail dismally. _______________________________________________ Nznog mailing list Nznog(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog _____ _______________________________________________ Nznog mailing list Nznog(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog

2 1

APE Peering
by Sahil Gupta - NET4U LIMITED 02 Jul '03

02 Jul '03

Hi, This announcement is more centered towards Network Administrators at ISP's that are connected to the APE. Net4U (www.net4u.co.nz) connected to the APE since May 2003 and since then have been peering with a number of ISP's around the country. We are currently looking for more ISP's to peer with and so if you feel that we could have a domestic peering arrangement between your ISP and Net4U, please get back to me off-list as we would be more than happy to do so. Regards, Sahil Gupta Senior Account Manager NET4U LIMITED Phone: 0508-263-848 Fax: 07-8582659 Mobile: 029-366-6375

7 6

APE Peering
by Richard Patterson 02 Jul '03

02 Jul '03

1 0

RE: [nznog] APE Peering
by Richard Parkinson 02 Jul '03

02 Jul '03

We have made a brief report which is not for public viewing, but which has identified a small number of issues on the Net4U network (which were quickly rectified) that were as a result of previous employees. We found nothing that was causing deliberate loss of bandwidth to any other party. We did not fully complete the work due to budget restraints, however we did cover most of the important aspects. Some of our recommendations have been implemented, and sadly others have not been done, but Net4U are operating somewhat better than they were. We no longer oversee the operation of Net4U, but have kept in touch with them, and assist with other matters both business related and technical, and feel Net4U & Sahil are slowly "growing up" so to speak, but I expect mystiques will still be made from time to time. None of us are perfect. I can assure you the bandwidth offered by Net4U in that "distributed" email is legitimate, and I should warn you that continued accusations and alligations are a direct attack against me and my company, which left Net4U operating legally and above board, and there is no justification for this blatant deformation. I must say that I also disagree with the method of advertising chosen. Had I been consulted I would have recommended against it, but in saying that, I welcome email in my inbox that relates directly to my line of business and would rather receive such email as opposed to the ones about increasing the size of certain body parts or some other "amazing offer" which we see all to often of late, depending on how good your mail filters are. It doesn't take much for everyone to see that some of you are making an issue simply because it's Sahil and Net4U, and because you were a reject at school who was picked on and bullied, and now have a psychological disorder resulting in you playing out the role of your boyhood deamon from school, dishing out what you received. Without naming anyone, I would also like to point out that there are those of you on this list making such accusations who are the last people to do so, or should we raise the matter of a VAST amount of bandwidth stolen from Telecom for a number of months, by a much larger ISP than Net4U, who even taught another ISP's network administrator how to do it only days before Telecom figured it all out... or perhaps I could send the list a copy of some forged court documents? To these few people I say, I suggest you stop stirring the pot and leave the past alone, or you will get more than just a little of it on you. I think we should all take a good look at ourselves, and the motivation behind the pettiness that from time to time, makes me wonder just how many children play on this list, and how many people are here to get work/business done. Lets just get on with our work please everyone. Cheers, Richard Parkinson (Director) Sigel Data Systems Ltd. -----Original Message----- From: Craig Whitmore [mailto:lennon(a)orcon.net.nz] Sent: Thursday, 3 July 2003 2:13 p.m. To: nznog(a)list.waikato.ac.nz; Steve Phillips Subject: Re: [nznog] APE Peering If anyone had forgotten, where is the "Report" from Sigel Systems about Net4u's runnings over the last 3 months. I believe the impartial 3rd party was hired as one of net4u's staff a very short while after (so couldn't be impartial) Thanks Craig > >> >[snippage] > > > We can deliver using several methods as I've outlined above and can also > > > take care of transporting your existing I.P. Address ranges supplied to > > > you by your current provider to us. > > That would be a neat trick. Almost worth taking him up on that just to > watch him fail dismally. _______________________________________________ Nznog mailing list Nznog(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog

6 5

RE: [nznog] APE Peering
by Simon Byrnand 02 Jul '03

02 Jul '03

At 15:35 3/07/03 +1200, Richard Parkinson wrote: >I must say that I also disagree with the method of advertising chosen. Had >I been consulted I would have recommended against it, but in saying that, >I welcome email in my inbox that relates directly to my line of business >and would rather receive such email as opposed to the ones about >increasing the size of certain body parts or some other "amazing offer" >which we see all to often of late, depending on how good your mail filters >are. > Sorry, but that doesn't wash with me, or I suspect most members of the list. Spam is Spam whether its trying to sell me Viagra or Bandwidth. Anybody that received that mailout (fortunately I didn't) who had no previous business dealings with Net4U could be legitimately annoyed by it. The sample "message" appeared to be addressed to soa@ which suggests it might have been taken from domain or APNIC contact details. >It doesn't take much for everyone to see that some of you are making an >issue simply because it's Sahil and Net4U, and because you were a reject >at school who was picked on and bullied, and now have a psychological >disorder resulting in you playing out the role of your boyhood deamon from >school, dishing out what you received. > Pot, Kettle, Black ? Regards, Simon

2 1

RE: [nznog] APE Peering
by Richard Parkinson 02 Jul '03

02 Jul '03

I did say disagree with the "spam" method used. I agree this thread is a waste of time and should die. -----Original Message----- From: Gordon Smith [mailto:gordon(a)morenet.net.nz] Sent: Thursday, 3 July 2003 3:47 p.m. To: Richard Parkinson; nznog(a)list.waikato.ac.nz Subject: RE: [nznog] APE Peering Richard, Was there any point to that message at all? Firstly, spam is spam, not "distributed" email. It is unsolicited commercial email, which this was. Secondly, I think you'll find that ANY provider that has previously behaved as poorly would attract a similar response. I really don't care if they are mystical or deformed, this is a breach of what is generally accepted as "acceptable conduct". Perhaps this thread should die - it has very little to do with network operations. Gordon Smith CCNA Network Operations Manager MoreNet Ltd PGP Fingerprint: 4B12 FBE4 784A 3294 6637 4587 AB6F C893 AB2C 952C

1 0

RE: [nznog] APE Peering
by Richard Parkinson 02 Jul '03

02 Jul '03

And I knew this as soon as I saw it hit the list. Cheers -----Original Message----- From: Matthew Poole [mailto:lists(a)p00le.net] Sent: Thursday, 3 July 2003 3:45 p.m. To: Richard Parkinson Cc: NZNOG Subject: RE: [nznog] APE Peering Getting very OT here, but that word is EXCEPT! On Thu, 3 Jul 2003, Richard Parkinson wrote: > Accept for a spelling error or two. :) > > -----Original Message----- > From: Juha Saarinen [ mailto:juha(a)saarinen.org] > Sent: Thursday, 3 July 2003 3:44 p.m. > Cc: NZNOG > Subject: RE: [nznog] APE Peering > > > > On Thu, 3 Jul 2003, Richard Parkinson wrote: > > > I can assure you the bandwidth offered by Net4U in that "distributed" > > email is legitimate, and I should warn you that continued accusations > > and alligations are a direct attack against me and my company, which > > left Net4U operating legally and above board, and there is no > > justification for this blatant deformation. > > Priceless. > > > -- > Juha Saarinen > _______________________________________________ > Nznog mailing list > Nznog(a)list.waikato.ac.nz > http://list.waikato.ac.nz/mailman/listinfo/nznog > > >

1 0

RE: [nznog] APE Peering
by Richard Parkinson 02 Jul '03

02 Jul '03

Accept for a spelling error or two. :) -----Original Message----- From: Juha Saarinen [mailto:juha(a)saarinen.org] Sent: Thursday, 3 July 2003 3:44 p.m. Cc: NZNOG Subject: RE: [nznog] APE Peering On Thu, 3 Jul 2003, Richard Parkinson wrote: > I can assure you the bandwidth offered by Net4U in that "distributed" > email is legitimate, and I should warn you that continued accusations > and alligations are a direct attack against me and my company, which > left Net4U operating legally and above board, and there is no > justification for this blatant deformation. Priceless. -- Juha Saarinen _______________________________________________ Nznog mailing list Nznog(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog

2 1

dnis prefix stripping
by Mark Frater 02 Jul '03

02 Jul '03

Anyone know how to strip DNIS prefixes on a Lucent TNT? Mark

1 0

More Sahil spam
by Michael Hallager 02 Jul '03

02 Jul '03

This was contained in a spam/UCE email received from Sahil last week. Why I am on his mailing list, I don't know. I don't deal with him. He has not responded to my email questioing the hypocrisy. Uncharged Users: ---------------- It has come to our attention that there may be a very small number of users who have slipped through the cracks so to speak, either by devious and deliberate means, or otherwise, and are not paying for the service they have been using. This is known as Fraud! If you are one of those users who have not been paying for the service that you have been using, this is your chance to come forward before we take action. There will be an amnesty period of 7 days (until the 1st of July) for such users to come forward and pay last months, and next months usage, and join the ranks of our regular customers. Failure to do so by the 1st of July will result in fraud charges laid against the Telecom account holders responsible for the unlawful Jetstream connection to Net4U. We will also back date all charges associated to the unlawful use of our services, and pursue these in court if necessary. Sorry for the harsh news everyone. Lets move onto some better news.....

2 1

RE: [nznog] APE Peering
by Steve Phillips 02 Jul '03

02 Jul '03

At 13:59 3/07/2003, Seeby Woodhouse wrote: >I guess that Sahil finally decided that the dust had settled enough that >he could start selling off some of his stolen bandwidth I noticed the costs were rather below the market rates from a number of players in the market that _do_ actually sell bandwidth internationally.. Maybe he's found another way around paying the carriers for their services.. ? one wonders if it all hinges upon him getting peering partners at APE and WIX.. does anyone actually trust net4u enough to peer with them.. ? -- Steve.

1 0

RE: [nznog] APE Peering
by Seeby Woodhouse 02 Jul '03

02 Jul '03

I guess that Sahil finally decided that the dust had settled enough that he could start selling off some of his stolen bandwidth - perhaps he's been hoarding up all the ill-gotten bits and bytes in a big cache, and now he wants to release it to the world at a fantastically discounted rate! :-) In case you missed the original Net4u story about this, here are some links. http://www.reseller.co.nz/Reseller/Reseller.nsf/0/86256ABD006E93FCCC256C F4001F2C03?OpenDocument http://www.computerworld.co.nz/webhome.nsf/0/9624CB39A4EE23A0CC256CF5001 1DB4F?opendocument http://www.aardvark.co.nz/daily/2003/0327.shtml Cheers Seeby Woodhouse Managing Director Orcon Internet Limited - www.orcon.net.nz ____________ ----- Original Message ----- From: "Sahil Gupta - NET4U LIMITED" <sgupta(a)net4u.co.nz> To: <soa(a)wise.net.nz> Sent: Thursday, July 03, 2003 2:36 AM Subject: ATTN: Systems Administrator / Management > Hello there, > I would like to introduce Net4U Limited to you as an alternative bandwidth > wholesaler. > > We currently have a large network around New Zealand. We currently supply > 5 other ISP's in New Zealand with Bandwidth and supply our own customer > base with bandwidth for Dialup, ADSL, Wireless, Frame-Relay, ATM, Fiber, > Ethernet. > > We connect to many providers around New Zealand and are also a peer on the > Auckland Peering Exchange (www.ape.net.nz) > > Currently I can offer you these prices for International Bandwidth: > 64k - 2048k = $2000+GST (per megabit) > 2048k - 4096k = $1800+GST (per megabit) > 4096k - 10240k = $1600+GST (per megabit) > 10240k = POA. > > We can deliver using several methods as I've outlined above and can also > take care of transporting your existing I.P. Address ranges supplied to > you by your current provider to us. > > Above all, we can also deliver Domestic / International Traffic via a BGP > Feed on 2 Different PVC's. > > Please let me know what you think of our offer. > > Regards, > > Sahil Gupta > Senior Account Manager > NET4U LIMITED > > Phone: 0508-263-848 > Fax: 07-8582659 > Mobile: 029-366-6375

1 0

Anyone want 2U cases (again) ?
by Mark Frater 02 Jul '03

02 Jul '03

Hi List, I'm ordering some more 2U cases from Taiwan and wondered if others were interested in buying some aswell to reduce the shipping cost per unit. ( If I just order a couple, the airfreight cost is as much as the cases!) The cases are 2U 19" wide by (only) 19" deep cases from Taiwan direct from manufacturer. These shallow cases are ideal for 600mm deep cabinets. They cases take standard ATX mobo. We have deployed both P4 and Athlon boards in these cases already and they have been fine. They will take up to 4 internal disks, floppy and CDRom. Here is a PDF cad drawing. http://www.quicksilver.net.nz/272-dia.pdf. Made by Comix International. $US200 for case, 400W PSU and 3xPCI Riser card. PLUS freight, gst and handling. Spare PSUs and mounting rails are also available. 2. 400W ATX Slim type power supply US$70.00 3. 22" Sliding rails US$25.00 4. 20" Sliding rails US$22.00 Total cost worked out at under NZ$550/case last time after shipping, customs charges and GST were added. Realistically, about 4-5 weeks delivery ( ie 1 week to get deposits, 1-2 week for Comix to make order, 1 week for airfreight, 1 week for NZcustoms clearance. Pickup from Quicksilver Internet, Textile Centre, Kenwyn St, Parnell, or for a small fee we could arrange for a courier from here. I'd like to get a deposit of (say) NZ$400 per case off people before placing the order. Make out cheques to Mercury Telecommunications Ltd and send to: Attn: Mark Frater, Mercury Telecommunications Ltd P.O.Box 99856 New Market Contact me off list if you are interested. Mark Frater Quicksilver Internet ph 9160300

1 0

The New Zealand Network Operators' Group
by Donald Neal 01 Jul '03

01 Jul '03

The New Zealand Network Operators' Group The New Zealand Network Operators' Group (NZNOG) has no king, president or formal membership. At present it consists of the subscribers to this mailing list, which anyone is free to join. NZNOG held a face to face gathering as part of the UniForum NZ conference in 2002, and is to do the same again from 10-12 July this year. That's next week. See http://www.uniforum.org.nz/conference_2003/conference.html for details. If you're going - and you are, aren't you? - you need to register NOW. NZNOG doesn't hold other national face to face meetings, but see http://thursdaynightcurry.com/ if you live in or near Wellington or Auckland. Operators' Contact List See http://www.usenet.net.nz/noc/ for operational contact details for most New Zealand ISP's. These are intended for use by other network operators rather than by most customers. Auckland Peering Exchange See http://www.ape.net.nz/ for details of the Auckland Peering Exchange and those connected there. About This Mailing List This list has around 480 addresses subscribed. You may only post to the list from a subscribed address. A number of people subscribe addresses which do not receive email purely to allow posting from them. The NZNOG mailing list is provided through a server at The University of Waikato, and is administered by an employee of Alcatel NZ Ltd. Neither of these organisations, nor the administrator, is responsible for its content. NZNOG Mailing List Acceptable Use Policy The NZNOG mailing list exists to provide a forum for the exchange of technical information and the discussion of implementation issues that require cooperation among New Zealand network service providers. In order to continue to provide a useful forum for discussion of relevant technical issues, users of the list are asked to respect the following guidelines. 1. Discussion will focus on Internet operational and technical issues. 2. Discussion related to meetings of network service providers is appropriate. 3. Discussion unrelated to these topics is not appropriate. 4. Postings to multiple mailing lists are discouraged. 5. Postings that include foul language, character assassination, and lack of respect for other participants are unacceptable. 6. Blatant product or service marketing is unacceptable. 7. Postings of a political, philosophical or legal nature are discouraged. 8. Postings to the list should be in ASCII or MIME encoded as text/plain. Attachments should not be sent to the list. To present a document, a suitable URL may be referred to. For documents of general interest, the use of proprietary file formats is discouraged. 9. Breaches of list etiquette should be dealt with privately with the offending list user, and should not result in complaints being sent to the list. 10. A person repeatedly breaching list etiquette shall receive warnings from the list administrator. A further breach after the second such warning within thirty days shall result in the offender being unsubscribed from the list. Other action may also be taken to block postings to the list by the offender. Any such unsubscription is to be immediately announced to the list. Mailing List Archives A full archive is available at http://list.waikato.ac.nz/archives/nznog/ Any message sent to the list will be archived and made available on the web automatically. Changes are not made to the archive on request, though the administrator remains happy to assist the Office of the Privacy Commissioner should any complaint be laid with that office. Subscribing to the List See http://list.waikato.ac.nz/mailman/listinfo/nznog to subscribe. Donald Neal NZNOG Mailing List Owner/Administrator/Muggins ------------------------------------------------------------------------------ "This communication, including any attachments, is confidential. If you are not the intended recipient, you should not read it - please contact me immediately, destroy it, and do not copy or use any part of this communication or disclose anything about it. Thank you." ------------------------------------------------------------------------------

2 1

RE: [nznog] Multicast status in New Zealand
by Frank March 30 Jun '03

30 Jun '03

Electric fences are a problem with POTS when they are poorly designed and maintained. The major problem with ADSL in rural areas is the distance from the nearest enabled exchange - only a relatively small number of rural people are within the 5-7 km distance that ADSL will reach. It is likely that wireless technologies will be necessary to reach anyone more than this distance for an exchange and for some satellite will be the only practical solution. According to Fonterra, there could be as many as 5,000 farms (probably not dairy farms) in this category. --- Frank March Senior Specialist Adviser, IT Policy Group (and member of the PROBE project team) Ministry of Economic Development, PO Box 1473, Wellington, New Zealand Phone (+64 4) 474 2908; Fax (+64 4) 474 2659; Mobile (+64) 21 042 9205 -----Original Message----- From: Cameron Kerr [mailto:cameron.kerr(a)paradise.net.nz] Sent: Tuesday, 1 July 2003 00:35 To: nznog(a)list.waikato.ac.nz Subject: Re: [nznog] Multicast status in New Zealand On Mon, Jun 30, 2003 at 11:20:32PM +1200, Lin Nah wrote: > Some of the target audience in the groups above tend to live in > rural areas and it is a challenge for them to get a 56k dialup > connection going (without worrying about line quality, electric > fences etc) let alone worry about high speed internet. Hence the > need for Project Probe. That raises an interesting question. If a primary problem with POTS is with electric fences creating a large amount of interference, how on earth is ADSL going to fare??? Surely its higher frequencies would be even more messed up. Or would they use wireless for people in that position? _______________________________________________ Nznog mailing list Nznog(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog http://www.govt.nz - connecting you to New Zealand central & local government services Any opinions expressed in this message are not necessarily those of the Ministry of Economic Development. This message and any files transmitted with it are confidential and solely for the use of the intended recipient. If you are not the intended recipient or the person responsible for delivery to the intended recipient, be advised that you have received this message in error and that any use is strictly prohibited. Please contact the sender and delete the message and any attachment from your computer.

1 0

RE: [nznog] Multicast status in New Zealand
by Michael Sutton 30 Jun '03

30 Jun '03

Over 500 clients of Xtra voluntarily registered and received Radio New Zealand and BBC World Live as Multicast on Telecoms dial up service for 3 years from 1998. I attended and observed when Telecom engineers enabled the same service via adsl in Wellington as multicast sourced from my servers in Akl in 2000. If i was in the Ministry of Health and needed to distribute 3,000 * 10m bytes PDF document from my source server to all distribution points within 60 minutes (3GigaBytes) no New Zealand network can do it. The distribution server and network would fail. If I used multicast and have a 256kbit multicast injection source the upload to all 3000 GPs will be complete in less than 10 minutes. The clients will still be billed for 3 gigabytes if they were being changed for local traffic and the rest of the national network would remain stable, especially for servers colocated with the originating server. If future spam blocking uses a signature system, multicast would enable this information to be distributed to all enterprise mail servers instantly and efficiently using multicast distribution... If I was implementing Maori Television and Youth Radio I would use multicast for distribution of the network transmission to reach 150 National distribution points where I would convert the multicast program for terrestrial transmission and in one step have positively changed the operational budget as well as reduced complexity of distribution. Yes I would still have to pay for each clients data charges... If I ran Correspondence School I would use multicast... If I was the TAB I would use it... I could give you 20 project scenarios that unicast can not implement in the real world. All unicast can do in every application is show the prototype concept - scale-up can not occur without multicast... This is really an Interconnect issue: customers should have network access to inject on a case by case situation... It is not up to the networks to be arbitrarily prohibiting this protocol... Please name another network protocol that could make such a difference and which is disabled ... Its like saying that the protocol extensions enabling mobile TXT messaging should have been blocked until each application was identified. I thought that Telecom, Telstra etc stopped "telling" customers what are permissible applications... Telecom and Telstra etc are supposed to implement enabling technologies which can be used by its customers who know there own current and future applications... In my professional opinion if the Boards of both these organisations understood the damage that this decision does to their clients network application capabilities, all of those executives involved would be gone. New Zealand has never had a real Internet as far as I am concerned due to this network management decision. Multicast is a broadcast service and without it the network remains unicast spaghetti, like pieces of string with empty cans of W* Baked Beans on each end... If Probe does not require multicast as a mandatory network service then the future of that service will be DOA... Due to public obfuscation of the process I don't know what they thought they required anyway. My final view on this is; turn it on and make the interconnect arrangements necessary for peering at wix and ape before one or more customers takes this to the Commissioner as an interconnect issue. Michael Sutton +64 4 4759235 www.awacs.co.nz -----Original Message----- From: Donald Neal [mailto:Donald.Neal(a)telecom.co.nz] Sent: Friday, June 27, 2003 12:41 To: nznog(a)list.waikato.ac.nz Subject: RE: [nznog] Multicast status in New Zealand My own opinion - and I must stress that it is just my opinion - is that this will be exactly Telecom's attitude. To change the answer you'd need to change the question. If you say "Look, to provide new service X which your customers will want, you need to enable IP multicasting", that's a different issue. But that would require the identification of service X. - Donald Neal ---------------------------------------------------------------------------- -- "This communication, including any attachments, is confidential. If you are not the intended recipient, you should not read it - please contact me immediately, destroy it, and do not copy or use any part of this communication or disclose anything about it. Thank you." ---------------------------------------------------------------------------- -- _______________________________________________ Nznog mailing list Nznog(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog

4 3

Test the Nation, Request (REPOST)
by Chris O'Donoghue 29 Jun '03

29 Jun '03

Sorry had to repost from home email Hi all, We (TVNZ) are running a programme tonight that _may_ attract considerable audience online. To try and make things run smoothly and lower calls to our and your call centres, can those of you that aggressively cache make sure you don't cache the following URL http://ttndata.nzoom.com/batches/data.xml This is the XML data that defines the current batch of questions. It will change in content frequently between 19:30 and midnight Ta Chris Chris ODonoghue Technology Manager Online & Digital TVNZ codonoghue(a)tvnz.co.nz

1 0

Test the Nation, request
by Chris O'Donoghue 29 Jun '03

29 Jun '03

Hi all, We (TVNZ) are running a programme tonight that _may_ attract considerable audience online. To try and make things run smoothly and lower calls to our and your call centres, can those of you that aggressively cache make sure you don't cache the following URL http://ttndata.nzoom.com/batches/data.xml This is the XML data that defines the current batch of questions. It will change in content frequently between 19:30 and midnight Ta Chris Chris O'Donoghue Technology Manager Online & Digital TVNZ ================================================================ CAUTION: This e-mail and any attachment(s) contains information that is intended to be read only by the named recipient(s). It may contain information that is confidential, proprietary or the subject of legal privilege. This information is not to be used by any other person and/or organisation. If you are not the intended recipient, please advise us immediately and delete this e-mail from your system. Do not use any information contained in it. ================================================================ For more information on nzoom.com, visit us online at http://www.nzoom.com ================================================================

1 0

Re: [nznog] Multicast status in New Zealand
by Ewen McNeill 27 Jun '03

27 Jun '03

In message <5.2.0.9.0.20030627141054.038683c0(a)pele.citylink.co.nz>, Richard Naylor writes: >>[Multicast] >Well the biggest part of the business is video on demand and that can >really only be unicast as getting viewers to agree on what they watch is >like agreeing on a TV Channel in a huge flat - hopeless. Even aside from the live situation you mention (eg, LOTR last year), general overseas experience with video-on-demand has shown that people really only want (to pay for) video-soon-after-demanded. Eg, for a 1-2 hour thing, having to wait, say, 2-5 minutes for it to start isn't a big deal. Even waiting 1 minute for a 10 minute thing isn't _that big a deal. Which means that for popular stuff that is "on demand" it might not be enough to have one channel with it, where the wait time is, say, 15 minutes for it to cycle around -- but it might be fine to have 10-20 channels, suitably staggered, where the wait time was 1-2 minutes. (Add channels to reduce the wait time.) Especially if there was some nice front end whereby people could find out which channel would be showing their thing starting next, and tune into that one. And it's much easier to scale channels-starting-every-minute (say) than it is to scale each-stream-is-unicast-with-its-own-start-point. (Particularly if you don't both starting/continuing the channels if there's nobody receiving it after a few minutes -- that requires some feedback outside multicast, but wouldn't be hard to do with a suitable client application and, say, UDP upstream responses every minute or so.) >back to streaming live and did the LOTR premiere last year with 10,000 >clients. Its a lot of fun and didn't really stress much other than a few ISPs. At least once some traction was made on the urgent call for more peering from the source point to the main sink points. But multicast fully deployed would definitely have helped a lot there. Ewen

3 2

RE: [nznog] Multicast status in New Zealand
by Donald Neal 27 Jun '03

27 Jun '03

> From: Simon Lyall [mailto:simon.lyall(a)ihug.co.nz] > Sent: Thursday, 26 June 2003 17:46 > To: nznog(a)list.waikato.ac.nz > Subject: Re: [nznog] Multicast status in New Zealand > > > On Thu, 26 Jun 2003, Craig Whitmore wrote: > > But wihtout having a killer ap or connections which can use > > them (like Telecom looking into enabling then DialIP/IPNET/Jetstream > > Network) 99% of the peopel conencted on these mediums won't > see anything) > > I'm sure there would be a few people that would jump through > the hoops to > get a non-commercial broadcast arrangement with APRA ( I > think one person > on this list has something along these lines) if they could multicast > their musical tastes to DSL people. Is anyone able to point me at some such people? - Donald Neal ------------------------------------------------------------------------------ "This communication, including any attachments, is confidential. If you are not the intended recipient, you should not read it - please contact me immediately, destroy it, and do not copy or use any part of this communication or disclose anything about it. Thank you." ------------------------------------------------------------------------------

2 1

RE: [nznog] Multicast status in New Zealand
by Donald Neal 26 Jun '03

26 Jun '03

> From: Michael Sutton [mailto:michael.sutton(a)awacs.co.nz] > Sent: Friday, 27 June 2003 14:55 > To: nznog(a)list.waikato.ac.nz > Cc: Donald Neal > Subject: RE: [nznog] Multicast status in New Zealand > > > Over 500 clients of Xtra voluntarily registered and received > Radio New Zealand and BBC World Live as Multicast on Telecoms > dial up service for 3 years from 1998. > > I attended and observed when Telecom engineers enabled the > same service via adsl in Wellington as multicast sourced from > my servers in Akl in 2000. > > If [...] What I'm looking for is someone who has _today_ content which they want to distribute where a) the availability of IP multicasting could reasonably be expected to make some difference to customer experience/network load, and b) the level of demand for this content can reasonably be expected to be such that either extra revenue for someone would come from making that content available OR its availability can reasonably be expected to increase the uptake of broadband service. The first of these is actually a harder test than it looks, given that there are other ways of doing point to multipoint comunication than unvarnished IP unicast or multicast. (The classic way to allow download of big documents many times is with proxy caching, to take just one example.) - Donald Neal All opinions my own. ------------------------------------------------------------------------------ "This communication, including any attachments, is confidential. If you are not the intended recipient, you should not read it - please contact me immediately, destroy it, and do not copy or use any part of this communication or disclose anything about it. Thank you." ------------------------------------------------------------------------------

1 0

RE: [nznog] Multicast status in New Zealand <<< CORRECTION >>>
by Michael Sutton 26 Jun '03

26 Jun '03

Correction to my earlier post: Para 3 Please read 30 gigabytes in 60 minutes. I wrote 3 gigabytes... M -----Original Message----- From: Michael Sutton [mailto:michael.sutton(a)awacs.co.nz] Sent: Friday, June 27, 2003 02:55 To: nznog(a)list.waikato.ac.nz Subject: RE: [nznog] Multicast status in New Zealand <snip> If i was in the Ministry of Health and needed to distribute 3,000 * 10m bytes PDF document from my source server to all distribution points within 60 minutes (30 GigaBytes) no New Zealand network can do it. The distribution server and network would fail. If I used multicast and have a 256kbit multicast injection source the upload to all 3000 GPs will be complete in less than 10 minutes. The clients will still be billed for 30 gigabytes if they were being changed for local traffic and the rest of the national network would remain stable, especially for servers colocated with the originating server. <snip>

1 0

Sobig.MM infected users?
by Neil Gardner 26 Jun '03

26 Jun '03

Hi guys, (specifially those at IHUG) any chance someone can do something about this user on IHUGs ADSL system? - (203-118-165-45.adsl.ihug.co.nz) This post is in desperation after the correct procedure for reporting this was followed twice with IHUG and no-one did anything about it except send a request for the full email which was given, and then sent me back a totally blank reply. IHUGs Helpdesk were apologetic, but said that no-one could do anything about it except between the hours of midnight and 8am (!!!!) Anyway, it wouldn't normally be an urgent issue, but the poor sucker that's infected has just subscribed to about 5 more lists that I'm on, as well as a lot of not so IT literate users, so he's going to catch a few of them... As an aside, what do most ISPs do if they find someone is infected and is sending out stuff lke this? (Yes, those dates in the email below are old - that's from the first bunch of emails he sent out when I first complained - and yes, I have checked the IP is still the same as of about 20 minutes ago) Cheers - Neil G > Return-Path: <big(a)boss.com> > Delivered-To: moderator for ultimate(a)nzfda.org.nz > Received: (qmail 32200 invoked from network); 18 Jun 2003 19:47:03 > -0000 > Received: from 203-118-165-45.adsl.ihug.co.nz (HELO MCNEILLJ-JLG772) > (203.118.165.45) > by 202-0-37-249.cable.paradise.net.nz with SMTP; 18 Jun 2003 19:47:03 > -0000 > From: <big(a)boss.com> > To: <ultimate(a)nzfda.org.nz> > Subject: Re: Movies > Date: Thu, 19 Jun 2003 7:47:09 +1200 > Importance: Normal > X-Mailer: Microsoft Outlook Express 6.00.2600.0000 > X-MSMail-Priority: Normal > X-Priority: 3 (Normal) > MIME-Version: 1.0 > Content-Type: multipart/mixed; > boundary="CSmtpMsgPart123X456_000_0001EFBA"

2 1

Sobig.MM infected users?
by nznog＠neilnz.com 26 Jun '03

26 Jun '03

Hi guys, (specifially those at IHUG) any chance someone can do something about this user on IHUGs ADSL system? - (203-118-165-45.adsl.ihug.co.nz) This post is in desperation after the correct procedure for reporting this was followed twice with IHUG and no-one did anything about it except send a request for the full email which was given, and then sent me back a totally blank reply. IHUGs Helpdesk were apologetic, but said that no-one could do anything about it except between the hours of midnight and 8am (!!!!) Anyway, it wouldn't normally be an urgent issue, but the poor sucker that's infected has just subscribed to about 5 more lists that I'm on, as well as a lot of not so IT literate users, so he's going to catch a few of them... As an aside, what do most ISPs do if they find someone is infected and is sending out stuff lke this? (Yes, those dates in the email below are old - that's from the first bunch of emails he sent out when I first complained - and yes, I have checked the IP is still the same as of about 20 minutes ago) Cheers - Neil G > Return-Path: <big(a)boss.com> > Delivered-To: moderator for ultimate(a)nzfda.org.nz > Received: (qmail 32200 invoked from network); 18 Jun 2003 19:47:03 > -0000 > Received: from 203-118-165-45.adsl.ihug.co.nz (HELO MCNEILLJ-JLG772) > (203.118.165.45) > by 202-0-37-249.cable.paradise.net.nz with SMTP; 18 Jun 2003 19:47:03 > -0000 > From: <big(a)boss.com> > To: <ultimate(a)nzfda.org.nz> > Subject: Re: Movies > Date: Thu, 19 Jun 2003 7:47:09 +1200 > Importance: Normal > X-Mailer: Microsoft Outlook Express 6.00.2600.0000 > X-MSMail-Priority: Normal > X-Priority: 3 (Normal) > MIME-Version: 1.0 > Content-Type: multipart/mixed; > boundary="CSmtpMsgPart123X456_000_0001EFBA"

1 0

Multicast status in New Zealand
by Cameron Kerr 26 Jun '03

26 Jun '03

Hello, I work as a teaching fellow in Telecommunications, teaching small-time network management and network programming. I am currently trying to learn more about multicast (IPv4 now, v6 later), in preparation for teaching multicast programming half way through the second semester. However, in the course we won't be connected to the internet, so I'm using my own home network to advance my understanding. I have a few questions about the current state of affairs wrt ISPs and content in New Zealand. 1) What broadband (and dial-up, for completeness) ISPs are multicast capable/friendly? Particularly Orcon, since our flat has just moved there. 2) What is needed to activate it at the users end (anything they need to do with mbone etc), or does the ISP deal with that? 3) Is there much in the way of content available? 4) Are there issues with NAT??? (I have a Nokia M1122 doing NAT, with Linux router/firewall behind it) Or alternatively, is there any documentation that answers these questions in the New Zealand environment. (If not, I'd be willing to help write/test.) Thank you all. -- Cameron Kerr cameron.kerr(a)paradise.net.nz : http://nzgeeks.org/cameron/ Empowered by Perl!

8 16

Re: [nznog] Multicast status in New Zealand
by Richard Naylor 26 Jun '03

26 Jun '03

At 01:48 p.m. 27/06/2003 +1200, David Robb wrote: <snip> >Overseas content proved to be largely boring, lossy, and not worth getting >back when I played with it at ihug. Now this might have changed since >then, but I suspect that locally generated content is still the way to go. I used to be able to get a copyright clearance out of TVNZ for streaming provided I had a minder present. That stopped some years ago. So now I create my own content. Its still boring, but thats the subject matter. I get round the lossy issues with bandwidth and better codecs. Its a very niche business but I make money. More in the talk at Uniforum. > > Then you have to get it to the users,(The hard part). Customers would have > > to run Tunnels to the ISP (as Telecom Jetstream/Jetstart/Dialup) network > >Running many tunnels defeats some of the purpose of multicast, since >you're then back to multiple streams through the core of your network. >Unless of course you can distribute the tunnel endpoints out to close to >your customers, but then you may as well just use unicast and relay it. Well the biggest part of the business is video on demand and that can really only be unicast as getting viewers to agree on what they watch is like agreeing on a TV Channel in a huge flat - hopeless. But I have gone back to streaming live and did the LOTR premiere last year with 10,000 clients. Its a lot of fun and didn't really stress much other than a few ISPs. The streaming business generally just uses unicast as getting network wide multicast is impossible. HOWEVER, Access Grids require multicast and will be running shortly (Cpus arrive monday). But I will tunnel the multicast to try and have a quiet life. Tunnels are the easy way out. The Mbone tools haven't kept up with codec development and aren't great quality. On the other hand divx/mp4 gives dvd quality at 800kbps which isn't hard to deliver. I've even got 300kbyte files going onto cell phones with very good feedback. Codecs certainly have got better. So my input is that the market (ie the viewers) want VOD and that doesn't need multicast. rich

1 0

Re: [nznog] Multicast status in New Zealand
by Nathan Ward 26 Jun '03

26 Jun '03

> This the thing that I find hard to understand. Multicast to me seems like > a cost reduction strategy rather than a revenue improvement one.....Does > no one want to reduce costs? Or is the easier path to profit through > increased revenue.... Sure, it reduces costs, but, who pays to get the content in? The ISP. How do they pass that cost on to thier customers fairly? IMO the only way to fairly do it is to watch your IGMP and see who is listening to what, and devide the costs up nicely. However, the cost per customer will differ per stream and also per minute. Did I mention the fact that you now have to account per multicast group and keep track of IGMP on all your routers... And what about in NZ where we have one or 2 main ISPs, and many smaller ISPs hanging off them. The cost that the smaller ISP gets charged by the larger ISP changes all the time now too... as a smaller ISP, try factor that into your billing system. Nathan Ward

1 0

Re: [nznog] Multicast status in New Zealand
by Jamie Baddeley 26 Jun '03

26 Jun '03

"..I remember at uniforum it was mentioned that the hold up on multicast in NZ (read: Telecom ADSL and the like), was that it was hard to charge for.." This the thing that I find hard to understand. Multicast to me seems like a cost reduction strategy rather than a revenue improvement one.....Does no one want to reduce costs? Or is the easier path to profit through increased revenue.... sigh. jamie >>> Nathan Ward <nward(a)esphion.com> 06/27 12:45 PM >>> On Fri, 27 Jun 2003 12:22:49 +1200, Cameron Kerr <cameron.kerr(a)paradise.net.nz> wrote: > Judging by the responses I recieved, I'm led to believe that no ISPs > currently support multicast. > > I'm forced then to consider the MBone. However there is very little in > the way of instructions for connecting to the mbone (all the > instructions say is to start mrouted). However, where does the other > endpoint for the tunnel go? Is anyone here attached to the MBone? Are > there any places you can connect to (preferably in NZ) for free? > > I'm starting to think that IPv4 multicast will never come, instead, the > first public offering of multicast capabilities to the general public > will come with IPv6. Afterall, the corporate attitude is the same > towards the two technologies is the same (No-one uses it, so we won't > provide it). Is this a reasonable conclusion do you think? > > Thanks for your answers. DISCLAIMER: This email is what I recall, it may be completely incorrect "The mbone is dead" - Greg Shepherd, Uniforum 2002. The mbone was a test network. What is left of it now is more of an informal thing. Lots of people use multicast internally. I remember at uniforum it was mentioned that the hold up on multicast in NZ (read: Telecom ADSL and the like), was that it was hard to charge for. -- Nathan Ward Esphion Ltd. _______________________________________________ Nznog mailing list Nznog(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog

1 0

RE: [nznog] Multicast status in New Zealand
by Donald Neal 26 Jun '03

26 Jun '03

> From: Cameron Kerr [mailto:cameron.kerr(a)paradise.net.nz] > Sent: Friday, 27 June 2003 12:23 > To: nznog(a)list.waikato.ac.nz > Subject: Re: [nznog] Multicast status in New Zealand [...] > I'm starting to think that IPv4 multicast will never come, > instead, the > first public offering of multicast capabilities to the general public > will come with IPv6. Afterall, the corporate attitude is the same > towards the two technologies is the same (No-one uses it, so we won't > provide it). Is this a reasonable conclusion do you think? My own opinion - and I must stress that it is just my opinion - is that this will be exactly Telecom's attitude. To change the answer you'd need to change the question. If you say "Look, to provide new service X which your customers will want, you need to enable IP multicasting", that's a different issue. But that would require the identification of service X. - Donald Neal ------------------------------------------------------------------------------ "This communication, including any attachments, is confidential. If you are not the intended recipient, you should not read it - please contact me immediately, destroy it, and do not copy or use any part of this communication or disclose anything about it. Thank you." ------------------------------------------------------------------------------

1 0

Orcon Internet Prefix List Update (2003-6-26)
by Craig Whitmore 26 Jun '03

26 Jun '03

For all those peering with Orcon Internet (AS17746) please update your Prefix Lists/BGP to allow the Following Network(s) ip prefix-list orcon-national permit 202.36.16.0/21 le 24 ip prefix-list orcon-national permit 202.36.24.0/22 le 24 These will be coming from AS23838 behind AS17746 if you do any AS filtering as well. Thanks Craig Whitmore Systems Administrator Orcon Internet http://www.orcon.net.nz

1 0

Server Co-location
by Aaron Martin 25 Jun '03

25 Jun '03

Anyone in Hawkes Bay want to house a server for one of my clients, in return for my client hosting one of your servers? Server is just for MX / DNS backup.

1 0

Re: [nznog] co-location query
by Colin Templeman 25 Jun '03

25 Jun '03

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I do know that Synergy (Queens Wharf) have plenty of space available in their custom server room. Probably worth an enquiry. <SNIP> | HI there, | | Does anyone know of companies in Wellington with spare machine room that they rent | out? I'm looking for somewhere to set up a few machines without incurring the cost of | building a whole machine room. | | Thanks in advance, | -Rebecca Piatek | | ------------------------------ - -- Regards, Colin Templeman At home, Wellington, New Zealand. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE++kpq1TWUpqMFtqoRAnoRAJsFSik2BK9p8FMmrZyUuK/L1uxq/wCeJqWN S1bce8RzkRik8QSylYqJO9Q= =E+Ox -----END PGP SIGNATURE-----

1 0

co-location query
by rebecca.piatek＠paradise.net.nz 24 Jun '03

24 Jun '03

HI there, Does anyone know of companies in Wellington with spare machine room that they rent out? I'm looking for somewhere to set up a few machines without incurring the cost of building a whole machine room. Thanks in advance, -Rebecca Piatek

1 0

Spam spam spam spam ...
by David Farrar 14 Jun '03

14 Jun '03

I'm facilitating a session on spam at the InternetNZ Summit on Thursday, and am going to do a quick backgrounder on how big the problem is both overseas and in NZ, plus look at some potential solutions. I've got lots of overseas stats but would love to be able to include some more local stuff. If anyone on the list can easily find out and send to me and stats they have on spam and their ISP, it would be most welcome. The sort of stuff I'm after is: - No of spams received pre day/week/year - % of spam is of overall e-mail, by number and GB - Any cost estimates for your ISP either in direct costs such as bandwidth or indirect costs like % of helpdesk time - What spam filtering, if any, you offer. - Any significant problems with false positives using blacklists etc - what calibre bullets should be used to eliminate spammers :-) Ta DPF

1 0

ihug Updated Prefix list.
by Simon Lyall 11 Jun '03

11 Jun '03

If you are peering with ihug (AS7657) can you please update you filters to accept our advertisements for the following network: ip prefix-list ihug-networks permit 202.46.160.0/24 Our current Prefix list can be obtained from: http://www.ihug.net/ihug-prefix-list -- Simon Lyall. | Newsmaster | Work: simon.lyall(a)ihug.co.nz Senior Network/System Admin | Postmaster | Home: simon(a)darkmere.gen.nz Ihug Ltd, Auckland, NZ | Asst Doorman | Web: http://www.darkmere.gen.nz

1 0

"Borrowed" /16 bought for $500
by Juha Saarinen 11 Jun '03

11 Jun '03

http://www.securityfocus.com/news/5654 -- Juha Saarinen

1 0

The New Zealand Network Operators' Group
by Donald Neal 09 Jun '03

09 Jun '03

The New Zealand Network Operators' Group The New Zealand Network Operators' Group (NZNOG) has no king, president or formal membership. At present it consists of the subscribers to this mailing list, which anyone is free to join. NZNOG held a face to face gathering as part of the UniForum NZ conference in 2002, and is to do the same again from 10-12 July this year. See http://www.uniforum.org.nz/conference 2003/conference.html for details. If you're going - and you are, aren't you? - it's time to get on with registering. NZNOG doesn't hold other national face to face meetings, but see http://thursdaynightcurry.com/ if you live in or near Wellington or Auckland. Operators' Contact List See http://www.usenet.net.nz/noc/ for operational contact details for most New Zealand ISP's. These are intended for use by other network operators rather than by most customers. Auckland Peering Exchange See http://www.ape.net.nz/ for details of the Auckland Peering Exchange and those connected there. About This Mailing List This list has around 480 addresses subscribed. You may only post to the list from a subscribed address. A number of people subscribe addresses which do not receive email purely to allow posting from them. The NZNOG mailing list is provided through a server at The University of Waikato, and is administered by an employee of Telecom NZ Ltd. Neither of these organisations, nor the administrator, is responsible for its content. NZNOG Mailing List Acceptable Use Policy The NZNOG mailing list exists to provide a forum for the exchange of technical information and the discussion of implementation issues that require cooperation among New Zealand network service providers. In order to continue to provide a useful forum for discussion of relevant technical issues, users of the list are asked to respect the following guidelines. 1. Discussion will focus on Internet operational and technical issues. 2. Discussion related to meetings of network service providers is appropriate. 3. Discussion unrelated to these topics is not appropriate. 4. Postings to multiple mailing lists are discouraged. 5. Postings that include foul language, character assassination, and lack of respect for other participants are unacceptable. 6. Blatant product or service marketing is unacceptable. 7. Postings of a political, philosophical or legal nature are discouraged. 8. Postings to the list should be in ASCII or MIME encoded as text/plain. Attachments should not be sent to the list. To present a document, a suitable URL may be referred to. For documents of general interest, the use of proprietary file formats is discouraged. 9. Breaches of list etiquette should be dealt with privately with the offending list user, and should not result in complaints being sent to the list. 10. A person repeatedly breaching list etiquette shall receive warnings from the list administrator. A further breach after the second such warning within thirty days shall result in the offender being unsubscribed from the list. Other action may also be taken to block postings to the list by the offender. Any such unsubscription is to be immediately announced to the list. Mailing List Archives A full archive is available at http://list.waikato.ac.nz/archives/nznog/ Any message sent to the list will be archived and made available on the web automatically. Changes are not made to the archive on request, though the administrator remains happy to assist the Office of the Privacy Commissioner should any complaint be laid with that office. Subscribing to the List See http://list.waikato.ac.nz/mailman/listinfo/nznog to subscribe. Donald Neal NZNOG Mailing List Owner/Administrator/Muggins ------------------------------------------------------------------------------ "This communication, including any attachments, is confidential. If you are not the intended recipient, you should not read it - please contact me immediately, destroy it, and do not copy or use any part of this communication or disclose anything about it. Thank you." ------------------------------------------------------------------------------

1 0

Orcon Internet Prefix List Update (2003-6-7)
by Craig Whitmore 06 Jun '03

06 Jun '03

For all those peering with Orcon Internet (AS17746) please update your Prefix Lists/BGP to allow the Following Network(s) ip prefix-list orcon-national permit 203.99.0.0/19 le 24 Thanks Craig Whitmore Systems Administrator Orcon Internet http://www.orcon.net.nz

1 0

SRS
by Nick Griffin 06 Jun '03

06 Jun '03

SRS and the whois was unavailable this morning as a result of a Citylink outage. SRS came back onstream at around 10:10am. cheers Nick -- Nick Griffin Registry Manager .nz Registry Services PO Box 24361 Wellington New Zealand e nick.griffin(a)nzrs.net.nz p + 64 4 931 6977 m + 64 21 505 229 f + 64 4 931 6979 w www.nzrs.net.nz

1 0

SRS
by Tim John 06 Jun '03

06 Jun '03

Anyone having difficulty connecting to the SRS this morning. I'm not getting there with on 'whois.srs.net.nz' Tim DISCLAIMER: The content of this email is confidential and may contain legally privileged information intended only for the individual or entity named above. Access to this message by anyone else is unauthorised. If you are not the intended recipient, please be advised that the use, distribution and publication of the above information is prohibited. If you have received this email in error, please contact Domainz by returning the email and destroying the original. Thank you.

2 1

Re: [nznog] W32/Bugbear-B
by Matthew Poole 05 Jun '03

05 Jun '03

On Fri, 06 Jun 2003 14:49:37 +1200, Ewen McNeill <ewen(a)naos.co.nz> wrote : > In message <003d01c32bba$88f42940$fd00a8c0(a)morpheus>, "Matthew G Brown" writes: *SNIP* > list at the nai.com URL that Dan Clark gave). Curiously anz.com.au is > there, but anz.co.nz is not, and westpac.com.au is there but > westpac.co.nz is not. > Not particularly curious when you consider the heavy consolidation that both ANZ and Westpac have recently done to move their operations across the Tasman. From experience I know that ANZ's 'net banking site is based in Aus (https://www.anz.com) and would imagine that WPT have probably done the same thing. If there's no secure traffic from the .co.nz domains, will BugBear even pay attention to them? > Obviously it's trying to pretend to be "The Bank" (almost all the > domains in its internal list seem banking related) despite the fact that > almost all banks have "webmail" systems rather than sending actual > email. > I used to hate ANZ's webmail system, until I reflected on the fact that their servers are considerably more secure than my home network - And they've definitely got a better chance of picking up an intrusion and doing something to the instigator. -- Matthew Poole Auckland, New Zealand

1 0

Re: [nznog] W32/Bugbear-B
by Ewen McNeill 05 Jun '03

05 Jun '03

In message <003d01c32bba$88f42940$fd00a8c0(a)morpheus>, "Matthew G Brown" writes: >Dan Clark wrote: >>http://vil.nai.com/vil/content/v_100358.htm > >Interesting, It has the domains asbbank.co.nz bankdirect.co.nz bnz.co.nz >and trustbank.co.nz as its sending domains. Ive had several people open >this already with the bankdirect.co.nz domain suffix. The "nz" bank domains appear to be: asbbank.co.nz bankdirect.co.nz bnz.co.nz nationalbank.co.nz trustbank.co.nz (obtained by grepping for "nz$" in a suitable transformed copy of the list at the nai.com URL that Dan Clark gave). Curiously anz.com.au is there, but anz.co.nz is not, and westpac.com.au is there but westpac.co.nz is not. Obviously it's trying to pretend to be "The Bank" (almost all the domains in its internal list seem banking related) despite the fact that almost all banks have "webmail" systems rather than sending actual email. Ewen

1 0

RE: [nznog] The End Is Nigh... Asia's running out of IP addresses
by Matthew Lamb 05 Jun '03

05 Jun '03

I wont be greedy, ill just take 10 or so, if you can spare them :-) Matt On Thu, 29 May 2003 11:39:11 +1200, "Brett Healy" <fork(a)btw.co.nz> wrote : > ill have it.. ill give it a good home. promise :D > > > Regards, > Brett Healy, > BTW Navigation Systems Ltd > > > -----Original Message----- > From: Kerry Thompson [mailto:kez-nznog(a)crypt.gen.nz] > Sent: Thursday, 29 May 2003 11:18 > To: nznog(a)list.waikato.ac.nz > Subject: Re: [nznog] The End Is Nigh... Asia's running out of IP > addresses > > > David Robb said: > > > > And just how much of that space is actually in use? > > > > And sometimes I wonder how much of the APNIC/NZ space is actually used as > well. > Years ago I registered a /22 off Netgate for a company, who never used it > and it stayed registered to my APNIC handle. I'm still wondering what to > do with it. And there's plenty of other such blocks out there that are > forgotten and unused. > > Kerry > > > -- > Kerry Thompson, CCNA CISSP > Information Systems Security Consultant > http://www.crypt.gen.nz > > > > _______________________________________________ > Nznog mailing list > Nznog(a)list.waikato.ac.nz > http://list.waikato.ac.nz/mailman/listinfo/nznog > > _______________________________________________ > Nznog mailing list > Nznog(a)list.waikato.ac.nz > http://list.waikato.ac.nz/mailman/listinfo/nznog > > >

2 1

W32/Bugbear-B
by Pipes Cuchifrito 05 Jun '03

05 Jun '03

Good Morning, Does anyone have any initial information on this virus? Are we looking downt he barrel of another network slow down? (another sleepless weekend?) Cheers, Pipes Rapturesecurity.com

3 3

Xtra Abuse
by Philip D'Ath 05 Jun '03

05 Jun '03

Isn't this typical. I try to report SPAM to Xtra's abuse account, and get an error message back saying that they have exceeded their own quota limit! --- This is a system generated message. Please DO NOT REPLY. Your message was not delivered for the following reason: The user(s) account is temporarily over quota. <responses(a)xtra.co.nz> For more information on why this message wasn't delivered, and an explanation of other common mail delivery errors, visit our Web site at: http://xtra.co.nz/maildelivery Kind regards. The Xtra Messaging Team

2 1

Could a mail admin from Xtra please contact me?
by Juha Saarinen 04 Jun '03

04 Jun '03

Apologies for this message, but I don't have a contact address for anyone there. -- Juha Saarinen

1 0

geek.nz approved in interim decision
by DPF 31 May '03

31 May '03

Many here will be pleased/interested to hear that in a unanimous 14-0 vote the InternetNZ Council voted in favour of creating geek.nz as the 12th 2LD for .nz. The interim decision is subject to further submissions, along with discussion of implementation details. A final decision will be taken at the next Council meeting in early July. DPF -- E-mail: david(a)farrar.com ICQ: 29964527 MSN: dpf666(a)hotmail.com

1 0

Update to the bogon route-server project
by Rob Thomas 29 May '03

29 May '03

Hi, NZNOG folk. We're pleased to announce the release of version 1.7 of the Bogon Route-Server Project. The major change in release 1.7 is the addition of three more bogon route-servers to the bogon route-server project, for a total of four. These are all managed by Team Cymru, and provide additional redundancy for the project. All of the bogon route-servers announce the same bogon prefixes and use the same ASN and community. Folks are free to peer with as many as they like, though we recommend a minimum of two. Peering with the bogon route-servers is *FREE*, though you are welcome to buy a cup of coffee for Rob at the SLC NANOG if you feel kindly. :) You can read more about the project here: <http://www.cymru.com/BGP/bogon-rs.html> You can read more about bogon filtering and tracking here: <http://www.cymru.com/Bogons/> Thanks! Rob, for Team Cymru. -- Rob Thomas http://www.cymru.com ASSERT(coffee != empty);

1 0

The End Is Nigh... Asia's running out of IP addresses
by Juha Saarinen 28 May '03

28 May '03

http://zdnet.com.com/2100-1103_2-1010666.html?tag=fdfeed I guess this means Australia/NZ too. Seems Joe's missive about IPv6 was quite prescient. -- Juha Saarinen

7 8

Re: [nznog] The End Is Nigh... Asia's running out of IP addresses
by Ewen McNeill 28 May '03

28 May '03

In message <Pine.LNX.4.30.0305291823140.17378-100000(a)boggle.ihug.co.nz>, Simon L yall writes: >On Thu, 29 May 2003, Joe Abley wrote: >> So, only 14% of the available IPv4 address space had been assigned to >> RIRs at the time of that presentation. > >Which is fairly meaningless since half those 202 are instead delegated >to Large Organisations, Various Registries etc. For sure. But if push comes to shove IANA can talk quietly (perhaps in the "talk quietly and carry a big stick" sense) to some of those Large Organisations and see if they couldn't perhaps manage with somewhat less than 2**24 addresses. >As the cost of putting a full IP stack and connection drops to only a >couple of dollars or less all sorts of random things will start having >them. And before you say NAT remember that the power company will want to >directly access your meter and hotwater cylinder, your car company the >car, your whiteware company the fridge etc. Did I mention the games >console? For many of those it could easily enough be done with NAT. It seems to me that "phoning home" isn't, inheriently, any more problematic than being able to interogate the devices remotely for the vendor. And it's probably somewhat preferable for the customer too. (Even if everything was globally routable, would you want Joe Random Company connecting in to arbitrary devices your network? This isn't your grandmother's Internet any longer. Sure you can use a firewall. You've just moved the problem to being one of ensuring a million or so firewalls are properly maintained. If I were a vendor, I'd take "phoning home".) >When stuff like that comes along we really want them to be deployed on a >nice ipv6 internet rather than have to suddenly switch cause demand >increases by a factor of 10 overnight. It would be nice to have $1,000,000 tomorrow too. I don't think either of them will happen.[0] Even at the current ease of use the cost/benefit ratio for converting to IPv6 is too low for (m)any(one) to put effort into doing so. It'll only be when there's a whole lot more benefit (eg, lots of IPv6-only services, or stuff which cannot be done with IPv4+NAT) or a lot less effort (works out of the box without even thinking about it, and has for years) that'll actually happen. Especially since we've had the better part of 10 years for everyone to get pretty good at designing IPv4+NAT compatible protocols and networks, thus greatly mitigating the perceived benefit of switching. Ewen [0] Although should someone wish to give me $1,000,000 tomorrow, I'd be willing to look suitably surprised on camera.

1 0

WTS Tracking controler and beacon receiver!
by Latchezar Dinev 28 May '03

28 May '03

1 0

WTS SSE Satellite SM3000modem in perfect condition
by Latchezar Dinev 28 May '03

28 May '03

1 0

WTS SSE Satellite SM3000modem in perfect condition
by Latchezar Dinev 28 May '03

28 May '03

1 0

WTS PM4 with 27E1 ports full loaded
by Latchezar Dinev 28 May '03

28 May '03

1 0

WTS CISCO AS5200-60DM-CH
by Latchezar Dinev 28 May '03

28 May '03

1 0

WTS 3COM Total Control 4E1 ports!
by Latchezar Dinev 28 May '03

28 May '03

1 0

IPv6 at APE
by Joe Abley 27 May '03

27 May '03

is anybody at the APE equipped to do IPv6 peering? Private replies are fine, I'll summarise if there's interest (and if there are replies).

11 18

Netforum Call for Papers
by Donald Neal 27 May '03

27 May '03

Roger De Salis sent this to the list: - - - - - The Netforum conference for 2003 is scheduled for July 10,11,12. The Theme of the conference is Next Generation Internet: Advanced Network Operations and Computer Networking in Aviation The conference will be extremely technical with >2/3 content devoted to advanced networking and related topics. Speakers are invited to submit proposals for papers to the conference committee by sending a synopsis and Title to "netforum(a)fx.net.nz". We look forward to an expanded conference in 2003, and the conference committee will be working very hard to meet or exceed the standard set by the 2002 conference, which I hope many of you enjoyed. The committee looks forward to receiving proposals. ==================================================================== In a similar manner, attendees are welcome to suggest topics or papers they are interested in seeing, and the conference organisers will then be able to help persuade likely speakersto stump up a talk. Send to "suggestions(a)fx.net.nz" Rgds Roger De Salis ------------------------------------------------------------------------------ "This communication, including any attachments, is confidential. If you are not the intended recipient, you should not read it - please contact me immediately, destroy it, and do not copy or use any part of this communication or disclose anything about it. Thank you." ------------------------------------------------------------------------------

3 2

Re: [nznog] IPv6 at APE
by Ewen McNeill 25 May '03

25 May '03

In message <5.2.0.9.1.20030526172452.055d4380(a)mail.igrin.co.nz>, Simon Byrnand writes: >The problem I can see with the introduction of ipv6 is that its such a >fundamental change, a bit like converting an entire country from imperial >to metric, except that you're trying to convert the WHOLE world :) Which sounds bad, except when you realise that the process doesn't require a "flag day", and has been very carefully designed so that it can happen over the course of several years (dual stacks, tunnels, etc). The major thing which is leading to slow progress, IMHO, is the lack of a really compelling need for it. IPv4 + NAT is a 90% solution. (OTOH there's something approaching a compelling need ofr multicasting, and that hasn't exactly happened much since last year either.) I think you're probably right that it'll take a very long time before IPv4 will be completely gone. But there've been plenty of other network protocols and many of them are nearly extinct. ("Native" windows networking is nearly gone -- haven't seen it in ages -- and even IPX is looking endangered (Novell went IP a couple of versions back), without even looking at protocols which were much less widely deployed.) FWIW, I do still keep meaning to experiment some more with IPv6 given some spare time, especially as most (all?) of the operating systems I'm using support IPv6 out of the box (OpenBSD, Linux, Solaris, etc, all support it out of the box these days). Ewen

1 0

Historical netblock allocation data?
by Juha Saarinen 22 May '03

22 May '03

Is there any publicly accessible repository that keeps information as to changes in netblock allocations? That is, noting to whom e.g. 152.152.0.0/16 or whatever was allocated originally, as opposed to whatever the current info happens to say? -- Juha Saarinen

1 0

Clear Dunedin Routing??
by Dan Clark 22 May '03

22 May '03

Hi guys, Is anyone on a local Clear/Telstra Frame anywhere in Dunedin area? Basicly we can see everything apart from another local ISP here in Dunedin on a similar Clear Frame as us. Its weird, we try connecting to port 25 on their IP and it fails, they try the same thing towards us with similar results. If we trace route to each other we get to an auckland clear router, then sent to wellington, then back to auckland in what seems like a loop. Can anyone shed some light on the situation, or if anyone else has a similar Clear POP in Dunedin area? Regards Dan Clark Network Manager Scarfies.Net Ltd

2 1

New and unacknowledged Exchange / Win2k SMTP vulnerability?
by Neil Gardner 21 May '03

21 May '03

Hi guys - for the last few weeks I've been working with Microsoft to try and track down why on Earth a correctly configured Exchange 2000 Server has been relaying. All of the standard sites report that it's closed, my own telnetting to it says it's closed, and yes, I've accounted for trojans on the LAN - but we're still going to try unplugging the rest of the LAN at some stage for a while and see what happens. But still, it's relaying. I add the IPs as I see them to a blacklist and it quietens down for a while, and MS keep promising they'll find the problem - but I send them SMTP logs, System and App logs and nothing adds up. All tests show it's closed, and all Logs (and complaining recipients) prove it's open for at least one attacker. Most of the reported sender addresses are in the format SMTPxxxx.YAHOO.COM (where xxxx is a random 4 digit number) But all resolve to chinanet or something. Recently though (today), they have been reporting as just 'exploder' or 'range' This is screaming 'vulnerability' to me, but MS refuse to acknowledge anything. I have heard in the last 20 minutes that a different organisation in Wgtn (with a different integrator) is having exactly the same problem, and that "Telecom is talking to Microsoft about it, but is getting nowhere" - I can't substantiate that yet though. No, the client isn't using an SMTP AV gateway, or firewall, Yes, they should be - and this will may in fact be the straw that broke the Financial Controllers back. But my current question is does anyone know WHAT this attack is, or if there's a configuration workaround I can do short of sticking a non win2k SMTP gateway between the net and Exchange? I can't post the SMTP logs publically because of a confidentiality agreement, but if anyone has an idea and would like to see a sample, please let me know and I'll see if the IT admin of the affected site will allow it. Cheers - Neil G.

1 0

Netforum 2003
by Roger De Salis 20 May '03

20 May '03

/* Early bird registrations close on 30th May, so please make sure you have your bookings in, we only have so much space.. */ The following additional talks have been scheduled for the conference Simon Lyall has kindly volunteered a talk about SPAM from an ISP perspective ----------------------------- - Filtering Products and and technology - Customer expectations - Managing Customer expectations ------------------------------------------------------- David Harris, of Pegasus fame is travelling all the way from Dunedin to talk about spam from the MUA persepctive and join a panel discussion on SPAM, and possible ISP and User solutions(?) to SPAM, which we all know is reaching epidemic proportions..... (should there be a small programming competition, the best 5 line perl program which can generate the most eloquent version of "my name is Enkidei Duee, son of Fred Duee, who has some implausible sum in the bank, and needs.....") ----------------------------------------------------------- David Hawke from Genaware is talking about GIS on Linux, and will no doubt have some comments about Linux on the desktop as opposed to linux in a server environment. ------------------------------------------------------------- KC Claffy from Caida in San Diego has indicated a willingness to join us in Auckland, and talk about some of the stuff CAIDA get up to. ------------------------------------------------------------ The flight simulator demo will include a discussion about the power of the internet to accelerate development, and particularly hooking the display (3-5 projectors) to live telemetry data and radio channels, thus effectively hooking yourself into the cockpit of a 737 currently landing at Auckland Airport. ------------------------------------------------------------ As we get closer to the conference, I shall be sending out small notes weekly to add the various talks and information as it comes to hand.. Rgds Roger De Salis -- \_ Roger De Salis rdesalis(a)fx.net.nz </' FX Networks +64 25 481 452 /) Wellington, New Zealand roger(a)desalis.gen.nz (/ ` DSL - the 56k modem technology of 2004

1 0

Sun RAQ's
by Matthew G Brown 20 May '03

20 May '03

Who in NZ distributes Sun's Cobalt range Web Hosting Appliances? Any admins have a good contact ? Best Regards Matthew G Brown B & R Holdings LTD http://www.brh.co.nz

2 1

RE: [nznog] XTRA Primary DNS Funkiness?
by Neil Gardner 19 May '03

19 May '03

Well, after 5 days of constant hassling, someone from Xtra finally rang me back and said they had fixed the TCP query problem on alien, and it does appear to be ok (for me at least) now... They also mentioned off the record that alien was slow this morning but didn't elaborate. They did say they were looking at it though. Cheers - N. -----Original Message----- From: Simon Byrnand [mailto:simon(a)igrin.co.nz] Sent: Tuesday, 20 May 2003 10:47 a.m. To: Neil Gardner; nznog(a)list.waikato.ac.nz Subject: Re: [nznog] XTRA Primary DNS Funkiness? At 17:26 15/05/03 +1200, Neil Gardner wrote: >Hi guys - has anyone noticed anything funky with Xtra's DNS over the >last 2 or 3 days? I have a client that had periodic mail buildups on >outbound SMTP and the error was 'Unable to bind to the destination >server in DNS'. After lots of false starts I got to Xtra DNS... Just checked both Xtra's DNS servers now for other reasons (tracking down an incorrect authorative dns record) and noticed that 202.27.184.3 is sometimes not responding at all - just getting a timeout rather than incomplete data. 202.27.184.5 seems ok. Regards, Simon

1 0

Re: [nznog] XTRA Primary DNS Funkiness?
by Simon Byrnand 19 May '03

19 May '03

At 17:26 15/05/03 +1200, Neil Gardner wrote: >Hi guys - has anyone noticed anything funky with Xtra's DNS over the >last 2 or 3 days? I have a client that had periodic mail buildups on >outbound SMTP and the error was 'Unable to bind to the destination >server in DNS'. After lots of false starts I got to Xtra DNS... Just checked both Xtra's DNS servers now for other reasons (tracking down an incorrect authorative dns record) and noticed that 202.27.184.3 is sometimes not responding at all - just getting a timeout rather than incomplete data. 202.27.184.5 seems ok. Regards, Simon

1 0

Anti Spam software
by Terence Bllyth 19 May '03

19 May '03

Can anyone tell me what the name of the Linux spam stopping software is, some one mentioned it a while ago, Email senders have to send a reply to it before it will pass on the email. (I know this description is vague). Thanks Terence Blyth Managing Director Computer Technologies Ltd 19 Alma Street Box 584, Nelson New Zealand Phone ++ 643 545 9001 Fax ++ 643 545 9002 www.ctec.co.nz PRIVILEGED - PRIVATE AND CONFIDENTIAL This email and any files transmitted with it are intended solely for the use of the addressee(s) and may contain information, which is confidential or privileged. If you receive this email and you are not the addressee (or responsible for delivery of the email to the addressee), please disregard the contents of the email, delete the email and notify the author immediately.

6 5

[c-announce] The InternetNZ Festival of Technology and AGM June 18-20 2003
by Peter Macaulay 19 May '03

19 May '03

(Informal announcement!) Please plan to be in Wellington for at least some part of these three days. The InternetNZ team, Industry NZ, the Next Generation Internet, and TUANZ in partnership with most of our sibling organisations has assembled an event which will deliver impact and value for every member of the internet community. The festival is is a work in progress and your input is welcome. To see the draft program. www.internetnz.net.nz/members/agm2003/festival_of_technology.html We will keep you informed through the discussion list as we develop the event. Please let any of your associates and friends now about our event. Registration will be available in the next week. We have appointed Martin Foster ( martin(a)internetnz.net.nz )as Festival Maestro. -- Peter Macaulay Executive Director InternetNZ Direct +64 4 495 2113 _______________________________________________

1 0

XTRA Primary DNS Funkiness?
by Neil Gardner 18 May '03

18 May '03

Hi guys - has anyone noticed anything funky with Xtra's DNS over the last 2 or 3 days? I have a client that had periodic mail buildups on outbound SMTP and the error was 'Unable to bind to the destination server in DNS'. After lots of false starts I got to Xtra DNS... >Nslookup >Set vc (to force TCP which is I think SMTP's default lookup protocol) >Set q=mx >Server 202.27.184.3 I tried that and got much strangeness when I put in >swiftlink.co.nz I should have gotten... >Server: alien.xtra.co.nz >Address: 202.27.184.3 > >Non-authoritative answer: >swiftlink.co.nz MX preference = 10, mail exchanger = mail.swiftlink.co.nz > >swiftlink.co.nz nameserver = dns1.clear.net.nz >swiftlink.co.nz nameserver = dns2.clear.net.nz >mail.swiftlink.co.nz internet address = 203.167.202.72 >dns1.clear.net.nz internet address = 203.97.33.1 >dns2.clear.net.nz internet address = 203.97.37.1 And in fact, I often do, but I also get... >Server: alien.xtra.co.nz >Address: 202.27.184.3 > >Non-authoritative answer: That's right, end of report - I have received stranger though - how about this??? >Server: alien.xtra.co.nz >Address: 202.27.184.3 >Non-authoritative answer: >swiftlink.co.nz MX preference = 10, mail exchanger = mail.swiftlink.co.nz >swiftlink.co.nz nameserver = Invalid Name at offset 66! >*** Error: record size incorrect (-326254 != 17) >Non-authoritative answer: >swiftlink.co.nz MX preference = 10, mail exchanger = mail.swiftlink.co.nz >swiftlink.co.nz nameserver = Invalid Name at offset 66! >*** Error: record size incorrect (-326254 != 17) >*** alien.xtra.co.nz can't find swiftlink.co.nz: Unspecified error (Blank lines removed for readability - sorry if they were important) I have reproduced these results from 3 different Internet connections, 2 Jetstreams (Both with Xtra) and a Jetstart with Attica. Same results at all 3 places... Oh, if I type >server 203.97.33.14 It all works perfectly... I rang Xtra and did speak to someone that sounded as if they knew what they were talking about, and even emailed copies of the above logs, and they claimed that nothing was wrong. Have I missed something blindingly obvious? Also, omitting 'set vc' to leave it on UDP makes alien.xtra.co.nz play nice again. Late discovery - 202.27.184.5 seems ok - this makes me suspect Xtra has problems even more, but my problems have been manifest over the last 3-4 days and they have denied any problems. Cheers - Neil Gardner Swiftlink NZ.

9 8

RE: [nznog] XTRA mail system
by Neil Gardner 18 May '03

18 May '03

Well, I was having big problems with Mail delivery from an Xtra ADSL connection a few days ago and it turned out to be a misbehaving alien.xtra.co.nz - it was intermittently returning empty results or actual errors. Xtra fobbed me off and said there was nothing wrong with it, even in the face of logs showing actual errors... Any chance they are related? Am I going to get a bunch of calls from clients with Xtra this morning? Cheers - Neil G Simon Lyall wrote: >A quick look at the logs shows it's been dead since around 23:56 last night >apart from a couple of 10 minute wondows around an hour ago. A few errors >before that even. The online Network status even shows a problem so it must >be really bad (I've got a theory that Theresa has to approve these herself) > >They were advertising for a mail admin a couple of months ago so maybe the >new guy pressed the wrong button.

2 1

Correction....
by rdesalis＠paradise.net.nz 17 May '03

17 May '03

That should have read...... /* Early bird registrations close on the 30th MAY......" sorry about that... brain thinking 30 words ahead of fingers... Also John H'ng from APNIC will be providing a full days training on Wednesday the 9th July, to complement Joe Ableys tutorials... I'll be away from my mail for the next couple of days but my phone number is 025 481 452 should anyone have any queries about the conference.. Rgds Roger De Salis

1 0

SIP/PSTN gateway in New Zealand
by Joe Abley 14 May '03

14 May '03

Does anybody know of any SIP/PSTN gateways operating in New Zealand, commercial or otherwise?

1 0

RE: [nznog] Xtra having smtp problems ?
by Michael Bordignon 08 May '03

08 May '03

> db:/var/www/webmail2/horde/imp# telnet xtra.co.nz 25 > Trying 202.27.184.102... > telnet: Unable to connect to remote host: No route to host My apologies, wrong host.. though same response for mta.xtra.co.nz

3 2

RE: [nznog] Xtra having smtp problems ?
by Alan Howard 08 May '03

08 May '03

One of my colleagues has spoken to the helpdesk who informed him that there was a minor problem with emails being delayed approx 2 hours. Regards Alan. Pacific Technology Solutions -----Original Message----- From: Edward Yardley [mailto:edward(a)edan.co.nz] Sent: Friday, 9 May 2003 16:47 To: Simon Byrnand Cc: nznog(a)list.waikato.ac.nz Subject: Re: [nznog] Xtra having smtp problems ? I just tried it on another line here - seemed to work fine. Edward Edan NET ----- Original Message ----- From: "Simon Byrnand" <simon(a)igrin.co.nz> To: <nznog(a)list.waikato.ac.nz> Sent: Friday, May 09, 2003 4:43 PM Subject: [nznog] Xtra having smtp problems ? > Hi People, > > Is anyone else noticing problems trying to deliver mail to xtra ? I've just > noticed I've got several hours worth of stuff in the outgoing queue > for xtra that isn't getting through. Manually telneting to > mta.xtra.co.nz 25 results in a hanging connection. > > Naturally, "Currently there are no known problems on the Xtra > network." according to Xtra's help page ;-) > > Regards, > Simon Byrnand > iGRIN Internet > > _______________________________________________ > Nznog mailing list > Nznog(a)list.waikato.ac.nz > http://list.waikato.ac.nz/mailman/listinfo/nznog > _______________________________________________ Nznog mailing list Nznog(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog

1 0

RE: [nznog] Xtra having smtp problems ?
by Michael Bordignon 08 May '03

08 May '03

> > Hi People, > > > > Is anyone else noticing problems trying to deliver mail to > xtra ? I've > just > > noticed I've got several hours worth of stuff in the > outgoing queue for > > xtra that isn't getting through. Manually telneting to > mta.xtra.co.nz 25 > > results in a hanging connection. > > > > Naturally, "Currently there are no known problems on the > Xtra network." > > according to Xtra's help page ;-) db:/var/www/webmail2/horde/imp# telnet xtra.co.nz 25 Trying 202.27.184.102... telnet: Unable to connect to remote host: No route to host

1 0

Xtra having smtp problems ?
by Simon Byrnand 08 May '03

08 May '03

Hi People, Is anyone else noticing problems trying to deliver mail to xtra ? I've just noticed I've got several hours worth of stuff in the outgoing queue for xtra that isn't getting through. Manually telneting to mta.xtra.co.nz 25 results in a hanging connection. Naturally, "Currently there are no known problems on the Xtra network." according to Xtra's help page ;-) Regards, Simon Byrnand iGRIN Internet

2 1

Can anyone tell me
by Simon Son 08 May '03

08 May '03

Can anyone tell me how ISP differentiate how much National and International traffic their jetstart customers uses? I think that If accounting packet is proxies from telecom's radius,then ISP must do something to distinguish National and International traffic. Thanks in advance SImon

5 5

Cisco 7206/7204 router chassis...
by Dan Clark 07 May '03

07 May '03

Hi all, Does anyone happen to have a Cisco 7206/7204 router chassis we could borrow for a lab/project for a short period of time? Please contact me offlist. Kind Regards Dan Clark Network Manager Scarfies.Net Ltd

1 0

OT: Cisco Flash
by Dan Clark 07 May '03

07 May '03

Hey guys, I'm after a 16 Meg Cisco Flash Card, would anyone of you happen to have one spare? If you do, please contact me off-list Regards, Dan Clark Network Manager Scarfies.Net Ltd

2 1

Anyone want a job?
by Mark Frater 07 May '03

07 May '03

http://www.quicksilver.net.nz/sysadmin.html contact me off list. Mark

1 0

The New Zealand Network Operators' Group
by Donald Neal 05 May '03

05 May '03

The New Zealand Network Operators' Group The New Zealand Network Operators' Group (NZNOG) has no king, president or formal membership. At present it consists of the subscribers to this mailing list, which anyone is free to join. NZNOG held a face to face gathering as part of the UniForum NZ conference in 2002, and is to do the same again from 10-12 July this year. See http://www.uniforum.org.nz/conference 2003/conference.html for details. The NZNOG schedule there is well short of final. NZNOG doesn't hold other national face to face meetings, but see http://thursdaynightcurry.com/ if you live in or near Wellington or Auckland. Operators' Contact List See http://www.usenet.net.nz/noc/ for operational contact details for most New Zealand ISP's. These are intended for use by other network operators rather than by most customers. Auckland Peering Exchange See http://www.ape.net.nz/ for details of the Auckland Peering Exchange and those connected there. About This Mailing List This list has around 470 addresses subscribed. You may only post to the list from a subscribed address. A number of people subscribe addresses which do not receive email purely to allow posting from them. The NZNOG mailing list is provided through a server at The University of Waikato, and is administered by an employee of Telecom NZ Ltd. Neither of these organisations, nor the administrator, is responsible for its content. NZNOG Mailing List Acceptable Use Policy The NZNOG mailing list exists to provide a forum for the exchange of technical information and the discussion of implementation issues that require cooperation among New Zealand network service providers. In order to continue to provide a useful forum for discussion of relevant technical issues, users of the list are asked to respect the following guidelines. 1. Discussion will focus on Internet operational and technical issues. 2. Discussion related to meetings of network service providers is appropriate. 3. Discussion unrelated to these topics is not appropriate. 4. Postings to multiple mailing lists are discouraged. 5. Postings that include foul language, character assassination, and lack of respect for other participants are unacceptable. 6. Blatant product or service marketing is unacceptable. 7. Postings of a political, philosophical or legal nature are discouraged. 8. Postings to the list should be in ASCII or MIME encoded as text/plain. Attachments should not be sent to the list. To present a document, a suitable URL may be referred to. For documents of general interest, the use of proprietary file formats is discouraged. 9. Breaches of list etiquette should be dealt with privately with the offending list user, and should not result in complaints being sent to the list. 10. A person repeatedly breaching list etiquette shall receive warnings from the list administrator. A further breach after the second such warning within thirty days shall result in the offender being unsubscribed from the list. Other action may also be taken to block postings to the list by the offender. Any such unsubscription is to be immediately announced to the list. Mailing List Archives A full archive is available at http://list.waikato.ac.nz/archives/nznog/ Any message sent to the list will be archived and made available on the web automatically. Changes are not made to the archive on request, though the administrator remains happy to assist the Office of the Privacy Commissioner should any complaint be laid with that office. Subscribing to the List See http://list.waikato.ac.nz/mailman/listinfo/nznog to subscribe. Donald Neal NZNOG Mailing List Owner/Administrator/Muggins ------------------------------------------------------------------------------ "This communication, including any attachments, is confidential. If you are not the intended recipient, you should not read it - please contact me immediately, destroy it, and do not copy or use any part of this communication or disclose anything about it. Thank you." ------------------------------------------------------------------------------

1 0

Live Web Presentations On the Certificate in Web-based Instruction
by Derek Lee 05 May '03

05 May '03

Hi: I would like to invite you to a live Web presentation from The Learning and Instructional Development Centre at Simon Fraser University (www.sfu.ca/lidc/telestraining/) about the Certificate in Web-Based Instruction (CWI), an online program to teach participants to design, produce, and teach online courses. The CWI instructors will give presentations to respond to questions about the next offering of the program, scheduled on June 2nd. There will be three presentation sessions in May: May 12 - 1200hrs Pacific Time (GMT -08:00), May 21 - 1700hrs Pacific Time (GMT -08:00), and May 26 - 0800hrs Pacific Time (GMT -08:00). These interactive presentations will be led by the program instructors Dr. Lucio Teles and Judith Jensen. Please go to http://www.sfu.ca/lidc/telestraining for more information and to register for the presentation sessions. If you have questions about the program, please contact Jill Jodrey at jajodrey(a)sfu.ca Derek Lee

1 0

people blocking "all APNIC space"
by Joe Abley 04 May '03

04 May '03

There's recurring wisdom on other lists that people outside the Asia Pacific region routinely block "all APNIC space" in order to reduce the amount of spam they receive (the most recent example was on NANOG, when someone inferred that APNIC address space was useless because it is so regularly blocked). I've run MTAs numbered within 202/8 and 203/8 before, and I've never noticed a problem; if the practice of blocking all APNIC space was that commonplace, I would have expected to have noticed. Maybe I was just lucky, or maybe these block-happy ISPs don't include 202/8 and 203/8 in "all APNIC space". Anybody here noticed widespread blocking of any APNIC ranges by ISPs elsewhere in the world? Joe

6 5

RE: [nznog] IPv6 in NZ?
by Paul Brislen 04 May '03

04 May '03

In defence of the Xtra PR spokeswoman Anna, I have to say she is entirely new to the world of ICT and when I asked her about IP numbers/addresses she'd never heard the term before... I asked her about IPv6 more as a separate point ("... and what about plans to roll out IPv6?") rather than as a solution to the allocation issue... I guess it's not really on topic to have it in the story alongside the rest but she had so little to say on the matter (oddly) that there really wasn't enough for a separate story.

2 1

OT - Remote access
by rod_christie＠wilsonandhorton.co.nz 30 Apr '03

30 Apr '03

OT - Is anyone working on anything new for high-speed remote access, for areas that will never yet DSL or other cable services? Satellite with dialup is fine, but after 15 km of copper, having bypassed electric fence units, then factoring encapsulation, corporate VPN, and remote access client to said box, more gg's would be good. It's a question I get asked from time to time. Any suggestions would be good. Reply of list. Cheers Rod Christie APN News & Media *************************************************************************** This may contain privileged and confidential information intended only for the use of the intended recipient. If you are not the intended recipient of this message, any use, dissemination, distribution or reproduction of this message is prohibited. Any views expressed in this message are those of the individual sender and may not necessarily reflect the views of Wilson & Horton Limited. For more information on Wilson & Horton please visit our web site at http://www.wilsonandhorton.co.nz ***************************************************************************

2 1

Re: [nznog] people blocking "all APNIC space"
by Steve Phillips 29 Apr '03

29 Apr '03

Just recently came across another blocking of 210.0.0.0/8 with chat servers. While probably not considered by many to be a productive service :-) it does still show attitudes that say "APNIC ? forget it" and this attitude appears to be markedly prevalent amongst US based admins and now appears to be expanding to cover services other than e-mail. -- Steve. At 11:46 30/04/2003 +1200, Alastair Johnson wrote: >Yes - we have seen this quite reguarly. Specifically, the >210/8 network seems particuarly disliked. > >pbi.net used to block connections from 210/8 but not from >202/7 for a good part of 2002. > > >We have customers complain about it every so often, but I forget >what the most recent case was - some little ISP in TX, IIRC. > > >aj... > >On Tue, 29 Apr 2003, Joe Abley wrote: > > > Date: Tue, 29 Apr 2003 19:35:10 -0400 > > From: Joe Abley <jabley(a)automagic.org> > > To: nznog(a)list.waikato.ac.nz > > Subject: [nznog] people blocking "all APNIC space" > > > > There's recurring wisdom on other lists that people outside the Asia > > Pacific region routinely block "all APNIC space" in order to reduce the > > amount of spam they receive (the most recent example was on NANOG, when > > someone inferred that APNIC address space was useless because it is so > > regularly blocked). > > > > I've run MTAs numbered within 202/8 and 203/8 before, and I've never > > noticed a problem; if the practice of blocking all APNIC space was that > > commonplace, I would have expected to have noticed. Maybe I was just > > lucky, or maybe these block-happy ISPs don't include 202/8 and 203/8 in > > "all APNIC space". > > > > Anybody here noticed widespread blocking of any APNIC ranges by ISPs > > elsewhere in the world? > > > > > > Joe > > > > _______________________________________________ > > Nznog mailing list > > Nznog(a)list.waikato.ac.nz > > http://list.waikato.ac.nz/mailman/listinfo/nznog > > > >--- >Never attempt with words what can be achieved with a flame thrower. > >_______________________________________________ >Nznog mailing list >Nznog(a)list.waikato.ac.nz >http://list.waikato.ac.nz/mailman/listinfo/nznog

2 1

WTS: CISCO AS5800 192VOX 2CT3 - new! Oboxed - LOW PRICE!
by cavin＠getintoweb.com 26 Apr '03

26 Apr '03

We have 2 units in stock ready to ship - GREAT & LOW PRICE! OBO: CISCO AS5800 ACCESS SERVER w/ DS58-192VOX + DS58-2CT3 FULLY LOADED !!! (1 of) AS5800 Top Level Dial Shelf Controller Card (2 of) AS5800 12-Port T3 Ingress Line Card The AS5800 supports up to two channelized T3 (CT3) interfaces. Each CT3 interface delivers up to 672 calls. info: http://www.cisco.com/warp/public/cc/pd/as/as5800/prodlit/as58_ov.htm They are new, open box. - GREAT & LOW PRICE! OBO Standard 90 day warranty Please email me or call me directly. Ask us for Cisco 12416 OC3 (4)OC12 OC48 6DS3 cards or 15454 chassis. Cavin PP 408-921-5028 cavin(a)getintoweb.com

1 0

Telstra Outage
by robbie_gernandt＠wilsonandhorton.co.nz 16 Apr '03

16 Apr '03

Did anybody else experience problems with Telstra IP Services this morning ( 00:30 to 02:00 and 06:50 to 7:50)? Apparently one of their main core switches had a faulty port or something, I'm still waiting for a report Robbie Gernandt Network Consultant APN News & Media robbie_gernandt(a)apn.co.nz Mobile: (64) 21 736 086 DDI: (64) 9 977 9577 Fax: (64) 9 373 6411 *************************************************************************** This may contain privileged and confidential information intended only for the use of the intended recipient. If you are not the intended recipient of this message, any use, dissemination, distribution or reproduction of this message is prohibited. Any views expressed in this message are those of the individual sender and may not necessarily reflect the views of Wilson & Horton Limited. For more information on Wilson & Horton please visit our web site at http://www.wilsonandhorton.co.nz ***************************************************************************

2 1

IPv6 in NZ?
by Juha Saarinen 15 Apr '03

15 Apr '03

Noticed on: http://snurl.com/1638 that Xtra "isn't considering moving to" IPv6 and also claims that "none of the ISPs are", presumably meaning the NZ ones. I know this is not correct, and that Joe Abley and Clear were at it back in '98 already, with the Uni of Canterbury. Where are things at with IPv6 in NZ now though? -- Juha Saarinen

8 8