- NZNOG - lists.nznog.org

Re: [nznog] What is this?
by Jeremy Strachan 01 Jun '06

01 Jun '06

2400, 4800, 9600, and yes even 14.4K was possible, and 19.2K. It probably ran over leased (conditioned) dedicated lines. It looks like a 1987 date on the back to me ... It is probably both large and heavy. Jeremy -----Original Message----- From: Joseph Miller [mailto:joseph(a)digiweb.net.nz] Sent: Friday, 2 June 2006 4:58 p.m. To: nznog(a)list.waikato.ac.nz Subject: Re: [nznog] What is this? It can't be that old - it's a whole 14.4k!

1 0

Re: [nznog] What is this?
by Jeremy Strachan 01 Jun '06

01 Jun '06

ah, so young ... Its pre-Internet .. -----Original Message----- From: Perry Lorier [mailto:perry(a)coders.net] Sent: Friday, 2 June 2006 4:52 p.m. To: nznog(a)list.waikato.ac.nz Subject: [nznog] What is this? http://www.wlug.org.nz/archive/history/ Anyone guess what this modem was last used for? and when/where? We powered it on, it still works :) _______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog

3 2

Notification of NZRR Database changes
by NZRR Database Notifications 01 Jun '06

01 Jun '06

Dear Colleague, This is to notify you that some object(s) in NZRR database which you either maintain or are listed as to-be-notified have been added, deleted or changed. These objects are used to configure the various NZIX route servers (http://nzix.net/) so you can expect the relevant servers to be reloaded in the near future. The reloading of the servers is staggered over a period of time so that if you are peering with both servers at an exchange, you can maintain at least one BGP session at all times and consequently a full set of routes. --- PREVIOUS OBJECT: route-set: AS9560:RS-ROUTES:AS10022 descr: advertised to AS9560 by Datacom - AS10022 members: 202.175.128.0/21^21-29, 202.14.20.0/22^22-29, 202.36.198.0/23^23-29, 192.203.216.0/24^24-29, 202.14.83.0/24^24-29, 202.27.76.0/24^24-29, 202.27.140.0/24^24-29, 202.27.143.0/24^24-29, 202.27.250.0/24^24-29, 202.36.233.0/24^24-29, 210.55.5.0/24^24-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: idc(a)datacom.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20060210 source: NZRR REPLACED BY: route-set: AS9560:RS-ROUTES:AS10022 descr: advertised to AS9560 by Datacom - AS10022 members: 202.175.128.0/21^21-29, 202.14.20.0/22^22-29, 202.14.82.0/23^23-29, 202.36.198.0/23^23-29, 192.203.216.0/24^24-29, 202.14.84.0/24^24-29, 202.27.76.0/24^24-29, 202.27.140.0/24^24-29, 202.27.143.0/24^24-29, 202.27.250.0/24^24-29, 202.36.233.0/24^24-29, 210.55.5.0/24^24-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: idc(a)datacom.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20060602 source: NZRR

1 0

[RIR] Deprecation of ip6.int Scheduled for June 1, 2006
by bmanning＠vacation.karoshi.com 31 May '06

31 May '06

On Thu, Mar 02, 2006 at 09:19:56AM -0500, Member Services wrote: > In August 2005, RFC 4159 Deprecation of ip6.int was published as Best > Current Practice. This RFC noted that maintenance of ip6.int is no > longer required and that the Regional Internet Registries adopt a > schedule for cessation of ip6.int. All the RIRs have agreed to deprecate > ip6.int on June 1, 2006. Further note that ARIN no longer modifies any > of the zones it administers under ip6.int effective December 7, 2005. > > Ginny Listman > Director of Engineering > American Registry for Internet Numbers and: On Tue, 16 May 2006 11:09:10 +0200, Andrei Robachevsky wrote: > Below is the proposed plan of ip6.int deprecation. Could you please > check if it is detailed enough to be properly coordinated, or if it > misses something. > > Andrei > > ip6.int deprecation plan > ------------------------- > > Advance Work: > > Contact Bill Manning at bmanning(a)vacation.karoshi.com and > hostmaster(a)ep.net before the 25th of May and ask him to schedule the > following: > > o June 1st 12:00 GMT: Remove all delegations within the 2.ip6.int zone. > > RIR Plan (common) > > o May 30th 12:00 GMT: Drop TTL on authoritative NS records within the > ip6.int zones to 3600. > > o June 1st 12:00 GMT: All delegations within the ip6.int zone are > removed. No RIR Action needed, other than checking. > > o June 1st 13:00 GMT - 23:59 GMT: All RIR's remove their respective > ip6.int zones from their servers. ........ while i noted the following: not all the zones or data in ip6.int are being removed.... so no, i am not changing the TTLs. the delegations that the RIR's have asked to be removed are scheduled for automatic removal. I will check on the process when i wake up roughly 3.5 hours later. I will be glad to send you email at that time to confirm removal. --bill ....... that being said, the RIR requested delegations have been removed from the IP6.INT zone. what remains is: # dig 2.ip6.int. axfr @::1 ; <<>> DiG 9.3.2 <<>> 2.ip6.int. axfr @::1 ; (1 server found) ;; global options: printcmd 2.ip6.int. 86400 IN SOA dot.ep.net. hostmaster.ep.net. 1999061700 10800 900 604800 129600 2.ip6.int. 86400 IN NS z.ip6.int. 2.ip6.int. 86400 IN NS dot.ep.net. 2.ip6.int. 86400 IN NS flag.ep.net. 0.0.1.0.0.2.ip6.int. 86400 IN NS z.ip6.int. 0.0.1.0.0.2.ip6.int. 86400 IN NS dot.ep.net. 0.0.1.0.0.2.ip6.int. 86400 IN NS flag.ep.net. 1.0.1.0.0.2.ip6.int. 86400 IN NS z.ip6.int. 1.0.1.0.0.2.ip6.int. 86400 IN NS dot.ep.net. 1.0.1.0.0.2.ip6.int. 86400 IN NS flag.ep.net. 2.0.0.2.ip6.int. 86400 IN NS z.ip6.int. 2.0.0.2.ip6.int. 86400 IN NS dot.ep.net. 2.0.0.2.ip6.int. 86400 IN NS flag.ep.net. 2.ip6.int. 86400 IN SOA dot.ep.net. hostmaster.ep.net. 1999061700 10800 900 604800 129600 ;; Query time: 4 msec ;; SERVER: ::1#53(::1) ;; WHEN: Thu Jun 1 06:44:20 2006 ;; XFR size: 14 records (messages 14) --bill

1 0

Notification of NZRR Database changes
by NZRR Database Notifications 31 May '06

31 May '06

Dear Colleague, This is to notify you that some object(s) in NZRR database which you either maintain or are listed as to-be-notified have been added, deleted or changed. These objects are used to configure the various NZIX route servers (http://nzix.net/) so you can expect the relevant servers to be reloaded in the near future. The reloading of the servers is staggered over a period of time so that if you are peering with both servers at an exchange, you can maintain at least one BGP session at all times and consequently a full set of routes. --- PREVIOUS OBJECT: route-set: AS9439:RS-ROUTES:AS18353 descr: Route set advertised to AS9439 by HDS - AS18353 members: 202.55.96.176/28^28-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: kenneth.liew(a)hdsnz.com mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20051006 source: NZRR REPLACED BY: route-set: AS9439:RS-ROUTES:AS18353 descr: advertised to AS9439 by Revera - AS18353 members: 202.55.99.0/24^24-29, 202.55.96.176/28^28-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: Marc.Nienkemper(a)revera.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20060601 source: NZRR

1 0

FW: GGIS Service Message : Major
by Paul Adshead 31 May '06

31 May '06

FYI -----Original Message----- From: noc(a)global-gateway.net.nz [mailto:noc(a)global-gateway.net.nz] Sent: Thursday, 1 June 2006 00:28 To: global-gateway outage contacts Subject: GGIS Service Message : Major GGIS Backbone Update Global-Gateway Internet is currently experiencing service disruption which began at 21:40 hrs, 31/05/06date You are likely to experience major international congestion of your service until this problem is resolved. A cable fault has been identified in the USA near San Francisco. Currently, we are have no expected time for restoration. GGIS apologises for any inconvenience to you or your customers, and an update will follow within 2 hours. Logged by Andrew Murray on Thu Jun 1 00:27:59 2006

3 2

Police Hoax Email
by Keith Davidson 30 May '06

30 May '06

Just a heads up for anyone not aware of this... Keith Davidson www.police.govt.nz/news/release/2445.html Hoax police email 10:03am 31 May 2006 A hoax email is circulating within New Zealand which purports to be a notification from NZ Police. The email has this subject line - "Notification from Police New_Zealand" The email is clearly a hoax but is causing some concern in the public with callers contacting police for clarification. The email suggests that recipients are "under suspicion of financial machination." It then asks receivers to fill in details and fax or email details. Police are investigating the email which does contain a trojan virus. The virus will be filtered out so long as computers have anti-virus software on their machines. Members of the public who are receiving the email with the subject line - "Notification from Police New_Zealand" - should simply delete it and do not need to contact Police about the matter. ENDS

1 0

wireline.co.nz domain
by Grant Zanetti 30 May '06

30 May '06

Can anyone at telecom tell me why they're sending emails from this domain (wireline.co.nz) when it has no useful DNS? Where is my mail system supposed to send bounces etc?

1 0

Podcasting Heads Up
by Webmaster 29 May '06

29 May '06

Operators should be aware that due to increased demand on our podcasting service, and the number of requests we've had to increase the quality of the files, we'll be increasing the data rates of all files offered from our US mirror. At the moment all US files have the same names as NZ hosted files, but are actually lower rates. Over the next 2 weeks this will change, with the US server becoming a full mirror. The data rates of files will double (from 24k to 48k) to match those hosted in NZ. We've been able to do this because we have extra capacity in the US and can serve the extra traffic at no additional cost to us. At present NZ bound traffic from the US server sits at 10-15 Mb/s during the day. Local operators who do not peer with our NZ servers will see an increase in international inbound traffic (about double) from the US mirror over the next two weeks. After that you should allow for an increase of 10-15% per week - our current growth rate. Those who peer with our servers in New Zealand are not affected by this change. regards, Richard Hulse Radio NZ

1 0

[Fwd: APNIC ip6.int services to end 1 June 2006]
by Andy Linton 29 May '06

29 May '06

Not that this isn't because the IPv6 camp are giving up and going home. (:-) andy -------- Original Message -------- Subject: APNIC ip6.int services to end 1 June 2006 Date: Mon, 29 May 2006 21:31:42 +1000 From: sanjaya(a)apnic.net To: asjl(a)citylink.co.nz Dear colleagues, APNIC will cease all ip6.int reverse delegation services at approximately 10:00 UTC+10 (00:00 UTC) on 1 June 2006. At that time, APNIC will withdraw the delegations for the following sub-domains under 1.0.0.2.ip6.int: 2.0.1.0.0.2.ip6.int 3.0.1.0.0.2.ip6.int c.0.1.0.0.2.ip6.int d.0.1.0.0.2.ip6.int e.0.1.0.0.2.ip6.int f.0.1.0.0.2.ip6.int 4.4.1.0.0.2.ip6.int 5.4.1.0.0.2.ip6.int 8.1.0.0.2.ip6.int 9.1.0.0.2.ip6.int a.1.0.0.2.ip6.int All ip6.int delegations within these sub-domains will then cease to be recognised by most DNS resolvers (although cached delegation information may take some time to expire). APNIC will back-up all whois objects associated with these sub-domains and will continue to monitor DNS traffic during this period to review behaviour. However, as the IETF has formally deprecated ip6.int for reverse-DNS, re-delegation is not expected to occur. Regards, Sanjaya ______________________________________________________________________ Technical Services Manager <sanjaya(a)apnic.net> APNIC ph +61 7 3858 3100 http://www.apnic.net fx +61 7 3858 3199 ______________________________________________________________________

3 2

(no subject)
by Russell STREET 25 May '06

25 May '06

Hello.. . TelstraClear hosts this NZ root name server replica on its infrastructure. We are physically moving the servers that run this name server this weekend. This will cause an outage to ns4.dns.net.nz at around 6AM Saturday 27th May 2006 for around 2 minutes, when we migrate the routing for the name server from one site to the new site. Russell (TelstraClear IS Operations)

1 0

Re: [nznog] Cell Tax
by Mark Seward 25 May '06

25 May '06

Interesting numbers. After a few weeks of bad performance on an Internet feed I look after I was drawn back to an issue I thought was long buried. This circuit was dropping 4-5% of its traffic at well below advertised capacity. The delivery method was ethernet over ATM/AAL5 (RFC1483). The usual suspects were rounded up and shot (duplex and error counters, purple switches, the cleaning lady). The next question was overhead for cell tax and encapsulation. 12% seems to be the allowance by our supplier. IIRC this is the same as was used 10 years ago for ATM VCs delivered directly to routers (no ethernet involved); nanog has a few dusty posts about this number. It seems this is no longer enough. Perhaps average packet sizes have changed since then if 12% was ever a reasonable number. In the end our supplier ramped overhead to about 20% and the pipe has performed nicely since. For an ethernet service, I don't understand why they don't simply provision the VC (VBR) as large as the customer bearer can handle and let the end devices do the shaping. Michael's numbers including AAL5 padding give this new figure some context: Upstream: cell tax = 14.84% (18.09% AAL5) Downstream: cell tax = 18.35% (23.43% AAL5) Is anyone aware of a recent study of packet size distribution on Internet traffic? CAIDA have some information from the AIX in 1999, NLANR from '97, and Sprint do a semi-regular dump from their ipmon project. http://www.caida.org/analysis/AIX/plen_hist http://www.nlanr.net/NA/Learn/packetsizes.html http://ipmon.sprint.com/packstat/packetoverview.php >From netflow stats on this link, I see a similar story with 64, 576 and 1536B being the points of most interest. The percentage of 1536B packets (~25) I think is larger now than previously. Has anyone had similar frustrations with PVC dimensioning? Does anyone else still use ATM? :) Mark. On 5/23/06, Michael Newbery < Michael.Newbery(a)team.telstraclear.co.nz> wrote: > > Prompted by Mark Seward, we have had a look at the cell tax incurred for > our > customers, in those cases where we are unfortunate enough to have to > transit > an ATM pipe. Which has not been the usual case on our network but becomes > interesting for things like UBS. > > This enables us to answer the question: for a pipe of x bps sufficient to > carry pure IP, how much bigger must the ATM PVC be to carry the same load? > > > IP_bw = x > ATM_bw = ceiling(x/48)*53 > Diff = ATM_bw - IP_bw > Cell_tax = Diff/IP_bw > > For a sample SAMP, we calculate the mean cell tax as > (sum(ceiling( SAMP/48)*53) - sum(SAMP))/sum(SAMP) > > Looking at a 24 hour sample, we get: > Upstream: cell tax = 14.84% > Downstream: cell tax = 18.35% > > I understand that this is somewhat at variance with the standard > provisioning rules applied by another provider. > -- > Michael Newbery IP Architect TelstraClear Limited > Tel: +64-4-920 3102 Mobile: +64-29-920 3102 Fax: +64-4-920 3361 > > > _______________________________________________ > NZNOG mailing list > NZNOG(a)list.waikato.ac.nz > http://list.waikato.ac.nz/mailman/listinfo/nznog > >

2 1

InternetNZ Internet Governance Positions
by Keith Davidson 24 May '06

24 May '06

Pardon the intrusion and slightly off topic subject: Interested in Internet governance? InternetNZ is recruiting directors to sit on the Board of its subsidiary company, New Zealand Domain Name Registry Ltd (trading as .nz Registry Services or "NZRS"); and members to sit on the .nz Oversight Committee ("NZOC"), which has stewardship of the .nz domain name space. These positions provide an exciting opportunity to contribute to the good governance of the .nz domain name space. Company directors and those with general governance skills are encouraged to apply for the appropriate positions. The retiring incumbents are eligible for reappointment. Complete descriptions and application details for both roles can be found online at www.internetnz.net.nz/vacancy. More information on the Office of the Domain Name Commissioner can be found at www.dnc.org.nz; and about the registry company at www.nzrs.net.nz. Applications by email to vacancy(a)internetnz.net.nz are invited from suitably qualified people, and close at midnight on Saturday 3 June. Please follow the links above for further details. If you are aware of anyone who you feel would be appropriate for one of the vacancies, we would be most grateful if you could forward this information to them. Furthermore, it is coming up to AGM time for InternetNZ and we are always on the lookout for enthusiastic people to serve on our Council and various committees and working groups. Links to further details on these positions are at www.internetnz.net.nz/vacancy. Any successful recruitment from a connection with NZNOG will result in a reward of provision of beer to all associated. Regards Keith Davidson Executive Director - InternetNZ

1 0

Notification of NZRR Database changes
by NZRR Database Notifications 24 May '06

24 May '06

Dear Colleague, This is to notify you that some object(s) in NZRR database which you either maintain or are listed as to-be-notified have been added, deleted or changed. These objects are used to configure the various NZIX route servers (http://nzix.net/) so you can expect the relevant servers to be reloaded in the near future. The reloading of the servers is staggered over a period of time so that if you are peering with both servers at an exchange, you can maintain at least one BGP session at all times and consequently a full set of routes. --- PREVIOUS OBJECT: route-set: AS9560:RS-ROUTES:AS9503 descr: advertised to AS9560 by FX Networks - AS9503 members: 131.203.0.0/16^16-29, 161.29.0.0/16^16-29, 161.65.0.0/16^16-29, 202.53.176.0/20^20-29, 202.174.160.0/20^20-29, 202.191.32.0/20^20-29, 202.50.200.0/21^21-29, 202.78.240.0/21^21-29, 203.190.208.0/21^21-29, 202.50.52.0/22^22-29, 202.50.196.0/22^22-29, 202.59.4.0/22^22-29, 202.37.86.0/23^23-29, 202.49.80.0/23^23-29, 202.124.106.0/23^23-29, 192.88.85.0/24^24-29, 192.133.31.0/24^24-29, 202.20.97.0/24^24-29, 202.27.208.0/24^24-29, 202.36.119.0/24^24-29, 202.36.183.0/24^24-29, 202.36.226.0/24^24-29, 202.46.190.0/24^24-29, 202.50.247.0/24^24-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: noc-minor(a)fx.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20060523 source: NZRR REPLACED BY: route-set: AS9560:RS-ROUTES:AS9503 descr: advertised to AS9560 by FX Networks - AS9503 members: 131.203.0.0/16^16-29, 161.29.0.0/16^16-29, 161.65.0.0/16^16-29, 202.53.176.0/20^20-29, 202.174.160.0/20^20-29, 202.191.32.0/20^20-29, 202.50.200.0/21^21-29, 202.78.240.0/21^21-29, 203.190.208.0/21^21-29, 202.50.52.0/22^22-29, 202.50.196.0/22^22-29, 202.59.4.0/22^22-29, 202.37.86.0/23^23-29, 202.49.80.0/23^23-29, 202.124.106.0/23^23-29, 192.88.85.0/24^24-29, 192.133.31.0/24^24-29, 202.20.97.0/24^24-29, 202.27.208.0/24^24-29, 202.36.119.0/24^24-29, 202.36.183.0/24^24-29, 202.36.226.0/24^24-29, 202.46.190.0/24^24-29, 202.50.247.0/24^24-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: noc-minor(a)fx.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20060525 source: NZRR

1 0

Xtra mail issues to AOL.com
by Drew Broadley 24 May '06

24 May '06

Could someone on Xtra's side please contact me offlist in regards to this. In the last four plus days this has happened and mail coming from AOL to Xtra is fine. -----Original Message----- From: "Mail Administrator"<Postmaster(a)xtra.co.nz> Sent: 25/05/06 8:54:57 a.m. To: "goldenfleece(a)clear.net.nz"<goldenfleece(a)clear.net.nz> Subject: Mail System Error - Returned Mail This is a system generated message. Please DO NOT REPLY. Your message was not delivered for the following reason: Your message was not delivered because the destination computer was not reachable within the allowed queue period. The amount of time a message is queued before it is returned depends on local configura- tion parameters. Most likely there is a network problem that prevented delivery, but it is also possible that the computer is turned off, or does not have a mail system running right now. Your message was not delivered within 4 days and 0 hours. Host aol.com is not responding. The following recipients did not receive this message: <wooluk(a)aol.com> For more information on why this message wasn't delivered, and an explanati [Message truncated. Tap Edit->Mark for Download to get remaining portion.]

1 1

for those who have spare time today and aren't here.....
by Richard Naylor 22 May '06

22 May '06

http://www.r2.co.nz/20060524/

2 1

Sorbs - Further Notification
by Bruce Harding 22 May '06

22 May '06

For those using Sorbs for any sort of blocking, you may have trouble receiving mail from Inspire Net now that they have chosen to block our 2 primary Mail servers. -- Bruce Harding Inspire Net Ltd Phone : 06 357 8559 Fax : 06 353 1154 Mobile : 021 519 024

3 2

Re: [nznog] DNS lookup for IPs of healthalliance.co.nz
by Clement Ashwal 22 May '06

22 May '06

Thanks for all your inputs guys. Since 2:15pm the nslookup for the URLs and also to all the SMTP servers hosted by Healthalliance have started to work by itself without anybody having to do any changes. I did get in touch with the Healthalliance techs and they seemed to have done nothing at all. Quite mysterious I must say. Hope it continues to work without any disruptions. Clement Ashwal Sr Network Analyst The University of Auckland + 6493737599 x 87993 -----Original Message----- From: jfp [mailto:jfp(a)clearfield.com] Sent: Tuesday, 23 May 2006 1:42 p.m. To: nznog(a)list.waikato.ac.nz Subject: Re: [nznog] DNS lookup for IPs of healthalliance.co.nz Well it looks like ns1.healthalliance.co.nz is down. dig www.healthalliance.co.nz @210.54.1.142 works dig www.healthalliance.co.nz @210.54.1.143 fails. given the the reverse DNS for 210.54.1.143 and 210.54.1.142 is also on those servers, you're going to get timeouts galore. ns1.healthalliance.co.nz. 86400 IN A 210.54.1.143 ns2.healthalliance.co.nz. 86400 IN A 210.54.1.142 jfp. ------------------------------------------------------------------------ Jean-Francois Pirus <jfp(a)clearfield.com> Senior Software Engineer Phone (+64-9) 358 2081 Clearfield Software Ltd Fax (+64-9) 358 2083 4th Floor 8-10 Whitaker Place Mob (+64-21) 640 779 P O Box 3901 Auckland, New Zealand ------------------------------------------------------------------------ _______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog

1 0

Notification of NZRR Database changes
by NZRR Database Notifications 22 May '06

22 May '06

Dear Colleague, This is to notify you that some object(s) in NZRR database which you either maintain or are listed as to-be-notified have been added, deleted or changed. These objects are used to configure the various NZIX route servers (http://nzix.net/) so you can expect the relevant servers to be reloaded in the near future. The reloading of the servers is staggered over a period of time so that if you are peering with both servers at an exchange, you can maintain at least one BGP session at all times and consequently a full set of routes. --- PREVIOUS OBJECT: route-set: AS9439:RS-ROUTES:AS9503 descr: advertised to AS9439 by FX Networks - AS9503 members: 131.203.0.0/16^16-29, 161.29.0.0/16^16-29, 161.65.0.0/16^16-29, 202.50.208.0/20^20-29, 202.53.176.0/20^20-29, 202.174.160.0/20^20-29, 202.191.32.0/20^20-29, 202.50.200.0/21^21-29, 202.78.240.0/21^21-29, 203.190.208.0/21^21-29, 202.50.52.0/22^22-29, 202.50.196.0/22^22-29, 202.59.4.0/22^22-29, 202.37.86.0/23^23-29, 202.49.80.0/23^23-29, 202.124.106.0/23^23-29, 192.88.85.0/24^24-29, 192.133.31.0/24^24-29, 202.20.97.0/24^24-29, 202.27.208.0/24^24-29, 202.36.119.0/24^24-29, 202.36.183.0/24^24-29, 202.36.226.0/24^24-29, 202.46.190.0/24^24-29, 202.50.247.0/24^24-29, 203.97.5.0/24^24-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: noc-minor(a)fx.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20060522 source: NZRR REPLACED BY: route-set: AS9439:RS-ROUTES:AS9503 descr: advertised to AS9439 by FX Networks - AS9503 members: 131.203.0.0/16^16-29, 161.29.0.0/16^16-29, 161.65.0.0/16^16-29, 202.53.176.0/20^20-29, 202.174.160.0/20^20-29, 202.191.32.0/20^20-29, 202.50.200.0/21^21-29, 202.78.240.0/21^21-29, 203.190.208.0/21^21-29, 202.50.52.0/22^22-29, 202.50.196.0/22^22-29, 202.59.4.0/22^22-29, 202.37.86.0/23^23-29, 202.49.80.0/23^23-29, 202.124.106.0/23^23-29, 192.88.85.0/24^24-29, 192.133.31.0/24^24-29, 202.20.97.0/24^24-29, 202.27.208.0/24^24-29, 202.36.119.0/24^24-29, 202.36.183.0/24^24-29, 202.36.226.0/24^24-29, 202.46.190.0/24^24-29, 202.50.247.0/24^24-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: noc-minor(a)fx.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20060523 source: NZRR

1 0

Notification of NZRR Database changes
by NZRR Database Notifications 22 May '06

22 May '06

Dear Colleague, This is to notify you that some object(s) in NZRR database which you either maintain or are listed as to-be-notified have been added, deleted or changed. These objects are used to configure the various NZIX route servers (http://nzix.net/) so you can expect the relevant servers to be reloaded in the near future. The reloading of the servers is staggered over a period of time so that if you are peering with both servers at an exchange, you can maintain at least one BGP session at all times and consequently a full set of routes. --- PREVIOUS OBJECT: route-set: AS9560:RS-ROUTES:AS9503 descr: advertised to AS9560 by FX Networks - AS9503 members: 131.203.0.0/16^16-29, 161.29.0.0/16^16-29, 161.65.0.0/16^16-29, 202.50.208.0/20^20-29, 202.53.176.0/20^20-29, 202.174.160.0/20^20-29, 202.191.32.0/20^20-29, 202.50.200.0/21^21-29, 202.78.240.0/21^21-29, 203.190.208.0/21^21-29, 202.50.52.0/22^22-29, 202.50.196.0/22^22-29, 202.59.4.0/22^22-29, 202.37.86.0/23^23-29, 202.49.80.0/23^23-29, 202.124.106.0/23^23-29, 192.88.85.0/24^24-29, 192.133.31.0/24^24-29, 202.20.97.0/24^24-29, 202.27.208.0/24^24-29, 202.36.119.0/24^24-29, 202.36.183.0/24^24-29, 202.36.226.0/24^24-29, 202.46.190.0/24^24-29, 202.50.247.0/24^24-29, 203.97.5.0/24^24-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: noc-minor(a)fx.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20060522 source: NZRR REPLACED BY: route-set: AS9560:RS-ROUTES:AS9503 descr: advertised to AS9560 by FX Networks - AS9503 members: 131.203.0.0/16^16-29, 161.29.0.0/16^16-29, 161.65.0.0/16^16-29, 202.53.176.0/20^20-29, 202.174.160.0/20^20-29, 202.191.32.0/20^20-29, 202.50.200.0/21^21-29, 202.78.240.0/21^21-29, 203.190.208.0/21^21-29, 202.50.52.0/22^22-29, 202.50.196.0/22^22-29, 202.59.4.0/22^22-29, 202.37.86.0/23^23-29, 202.49.80.0/23^23-29, 202.124.106.0/23^23-29, 192.88.85.0/24^24-29, 192.133.31.0/24^24-29, 202.20.97.0/24^24-29, 202.27.208.0/24^24-29, 202.36.119.0/24^24-29, 202.36.183.0/24^24-29, 202.36.226.0/24^24-29, 202.46.190.0/24^24-29, 202.50.247.0/24^24-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: noc-minor(a)fx.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20060523 source: NZRR

1 0

Cell Tax
by Michael Newbery 22 May '06

22 May '06

Prompted by Mark Seward, we have had a look at the cell tax incurred for our customers, in those cases where we are unfortunate enough to have to transit an ATM pipe. Which has not been the usual case on our network but becomes interesting for things like UBS. This enables us to answer the question: for a pipe of x bps sufficient to carry pure IP, how much bigger must the ATM PVC be to carry the same load? IP_bw = x ATM_bw = ceiling(x/48)*53 Diff = ATM_bw - IP_bw Cell_tax = Diff/IP_bw For a sample SAMP, we calculate the mean cell tax as (sum(ceiling( SAMP/48)*53) - sum(SAMP))/sum(SAMP) Looking at a 24 hour sample, we get: Upstream: cell tax = 14.84% Downstream: cell tax = 18.35% I understand that this is somewhat at variance with the standard provisioning rules applied by another provider. -- Michael Newbery IP Architect TelstraClear Limited Tel: +64-4-920 3102 Mobile: +64-29-920 3102 Fax: +64-4-920 3361

1 0

DNS lookup for IPs of healthalliance.co.nz
by Clement Ashwal 22 May '06

22 May '06

Hi, If somebody could throw some light on this issue would very much appreciate. We are having problems resolving few of the following URLs from our DNS servers at the University. www.countiesmanukaudhb.org.nz <http://www.countiesmanukaudhb.org.nz/> webmail.middlemore.co.nz www.waitematahealth.co.nz <http://www.waitematahealth.co.nz/> www.healthalliance.co.nz and others. All these names are registered with Healthalliance. There have been no changes to our DNS whatsoever and the reverse-lookups are working fine. Clement Ashwal Sr Network Analyst - ITSS The University of Auckland Private Bag 92019 Auckland New Zealand Phone + 64 9 3737599 x 87993 CAUTION - This message may contain privileged and confidential information intended only for the use of the addressee named above. If you are not the intended recipient of this message you are hereby notified that any use, dissemination, distribution or reproduction of this message is prohibited. If you have received this message in error please notify the sender immediately.

6 5

SORBS still listing Telecom static IPs as dynamic...
by Paul Adshead 22 May '06

22 May '06

It appears that SORBS are atill listing Telecom static IP ranges (- which my address is in,) as dynamic ranges. Wasn't this in the process of being fixed weeks/months ago? Does anyone have any ideas on how long this is going to be until it's resolved? The whole SORBS situation over the past months is becoming a total joke, with mail admins I know turning off their use of SORBS - there is just far far far too many false positives... :-( Paul. -----Original Message----- From: System Administrator Sent: Thursday, 18 May 2006 15:58 To: <customer> Subject: Undeliverable:RE: <mail subject> Your message did not reach some or all of the intended recipients. Subject: RE: <mail subject> Sent: 18/05/2006 15:58 The following recipient(s) could not be reached: Robert Reid on 18/05/2006 15:58 You do not have permission to send to this recipient. For assistance, contact your system administrator. <mailserver.mycompany.co.nz #5.7.1 smtp;554 5.7.1 Rejected 210.55.xx.xxx is a dynamic IP (see: http://www.au.sorbs.net/faq/dul.shtml for more information)>

13 21

IPv6 allocation and APNIC
by Brendon Wyber 22 May '06

22 May '06

Hi, Anyone had experience with getting a range of IPv6 numbers allocated to them through APNIC? Does NZ have the equivalent of a NIR (National Internet Registry) set up for allocation of IPv6? Cheers Brendon ========================================= Brendon Wyber, Wide Area Network Consultant, IT Department, University of Canterbury, Private Bag 4800, Christchurch, New Zealand. Phone: +64 3 364 2336 Fax: +64 3 364 2332 email: brendon.wyber(a)canterbury.ac.nz

3 2

IHUG Peering policy
by Simon Allard 22 May '06

22 May '06

Hi NZNOG :-) IHUG is changing its peering policy for peering over WIX and APE. We will no longer be directly peering with our current peers but will continue to peer with the route reflectors. Customers of IHUG who require APE/WIX peering directly will not be affected by this policy. This change is not because we don't like peering; it's just our way of trying to make our network simpler to manage. We are aware that some isp's are not huge fans of the route reflectors and prefer direct peering. We have heard all the arguments about why direct peering is much better than the "evil route reflectors of doom", but we personally have had no problems with them and they have proven to be reliable. If you have any questions, please contact me off list. Thank you :-) Simon Allard Ihug Limited P +64 9 962 9827 M +64 21 456 412 E simon.allard(a)staff.ihug.co.nz

2 1

Notification of NZRR Database changes
by NZRR Database Notifications 21 May '06

21 May '06

Dear Colleague, This is to notify you that some object(s) in NZRR database which you either maintain or are listed as to-be-notified have been added, deleted or changed. These objects are used to configure the various NZIX route servers (http://nzix.net/) so you can expect the relevant servers to be reloaded in the near future. The reloading of the servers is staggered over a period of time so that if you are peering with both servers at an exchange, you can maintain at least one BGP session at all times and consequently a full set of routes. --- PREVIOUS OBJECT: route-set: AS9560:RS-ROUTES:AS9503 descr: advertised to AS9560 by FX Networks - AS9503 members: 131.203.0.0/16^16-29, 161.29.0.0/16^16-29, 161.65.0.0/16^16-29, 202.50.208.0/20^20-29, 202.53.176.0/20^20-29, 202.174.160.0/20^20-29, 202.191.32.0/20^20-29, 202.50.200.0/21^21-29, 202.78.240.0/21^21-29, 202.50.52.0/22^22-29, 202.50.196.0/22^22-29, 202.59.4.0/22^22-29, 202.37.86.0/23^23-29, 202.49.80.0/23^23-29, 202.124.106.0/23^23-29, 192.88.85.0/24^24-29, 192.133.31.0/24^24-29, 202.20.97.0/24^24-29, 202.27.208.0/24^24-29, 202.36.119.0/24^24-29, 202.36.183.0/24^24-29, 202.36.226.0/24^24-29, 202.46.190.0/24^24-29, 202.50.247.0/24^24-29, 203.97.5.0/24^24-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: noc-minor(a)fx.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20060505 source: NZRR REPLACED BY: route-set: AS9560:RS-ROUTES:AS9503 descr: advertised to AS9560 by FX Networks - AS9503 members: 131.203.0.0/16^16-29, 161.29.0.0/16^16-29, 161.65.0.0/16^16-29, 202.50.208.0/20^20-29, 202.53.176.0/20^20-29, 202.174.160.0/20^20-29, 202.191.32.0/20^20-29, 202.50.200.0/21^21-29, 202.78.240.0/21^21-29, 203.190.208.0/21^21-29, 202.50.52.0/22^22-29, 202.50.196.0/22^22-29, 202.59.4.0/22^22-29, 202.37.86.0/23^23-29, 202.49.80.0/23^23-29, 202.124.106.0/23^23-29, 192.88.85.0/24^24-29, 192.133.31.0/24^24-29, 202.20.97.0/24^24-29, 202.27.208.0/24^24-29, 202.36.119.0/24^24-29, 202.36.183.0/24^24-29, 202.36.226.0/24^24-29, 202.46.190.0/24^24-29, 202.50.247.0/24^24-29, 203.97.5.0/24^24-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: noc-minor(a)fx.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20060522 source: NZRR

1 0

Notification of NZRR Database changes
by NZRR Database Notifications 21 May '06

21 May '06

Dear Colleague, This is to notify you that some object(s) in NZRR database which you either maintain or are listed as to-be-notified have been added, deleted or changed. These objects are used to configure the various NZIX route servers (http://nzix.net/) so you can expect the relevant servers to be reloaded in the near future. The reloading of the servers is staggered over a period of time so that if you are peering with both servers at an exchange, you can maintain at least one BGP session at all times and consequently a full set of routes. --- PREVIOUS OBJECT: route-set: AS9439:RS-ROUTES:AS9503 descr: advertised to AS9439 by FX Networks - AS9503 members: 131.203.0.0/16^16-29, 161.29.0.0/16^16-29, 161.65.0.0/16^16-29, 202.50.208.0/20^20-29, 202.53.176.0/20^20-29, 202.174.160.0/20^20-29, 202.191.32.0/20^20-29, 202.50.200.0/21^21-29, 202.78.240.0/21^21-29, 202.50.52.0/22^22-29, 202.50.196.0/22^22-29, 202.59.4.0/22^22-29, 202.37.86.0/23^23-29, 202.49.80.0/23^23-29, 202.124.106.0/23^23-29, 192.88.85.0/24^24-29, 192.133.31.0/24^24-29, 202.20.97.0/24^24-29, 202.27.208.0/24^24-29, 202.36.119.0/24^24-29, 202.36.183.0/24^24-29, 202.36.226.0/24^24-29, 202.46.190.0/24^24-29, 202.50.247.0/24^24-29, 203.97.5.0/24^24-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: noc-minor(a)fx.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20060505 source: NZRR REPLACED BY: route-set: AS9439:RS-ROUTES:AS9503 descr: advertised to AS9439 by FX Networks - AS9503 members: 131.203.0.0/16^16-29, 161.29.0.0/16^16-29, 161.65.0.0/16^16-29, 202.50.208.0/20^20-29, 202.53.176.0/20^20-29, 202.174.160.0/20^20-29, 202.191.32.0/20^20-29, 202.50.200.0/21^21-29, 202.78.240.0/21^21-29, 203.190.208.0/21^21-29, 202.50.52.0/22^22-29, 202.50.196.0/22^22-29, 202.59.4.0/22^22-29, 202.37.86.0/23^23-29, 202.49.80.0/23^23-29, 202.124.106.0/23^23-29, 192.88.85.0/24^24-29, 192.133.31.0/24^24-29, 202.20.97.0/24^24-29, 202.27.208.0/24^24-29, 202.36.119.0/24^24-29, 202.36.183.0/24^24-29, 202.36.226.0/24^24-29, 202.46.190.0/24^24-29, 202.50.247.0/24^24-29, 203.97.5.0/24^24-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: noc-minor(a)fx.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20060522 source: NZRR

1 0

Re: [nznog] Routing question
by Justin Cook 21 May '06

21 May '06

Thanks to everyone who responded, particularly JSR. All sorted and working great.

1 0

Routing question
by Justin Cook 21 May '06

21 May '06

Quick question from a routing noob: I've just acquired 210.48.96.88/30. The two IP addresses in the block are intended for a couple of vmware instances. We're not using anything nice like a Cisco router, just a Linksys stand-in for now. It has some basic static routing capabilities. I had a short conversation with Iconz support but I'm not feeling very confident about the result. I've been instructed (or rather I said "this is what we came up with" and I got a vague "yes") to add the following entry to the routing table (where 202.37.231.84 is the existing IP that we're using as an external address): Destination: 210.48.96.88 Subnet: 255.255.255.252 Gateway: 202.37.231.84 Interface: Local It's the gateway bit we're unsure of - won't this cause a loop? My mate is concerned that it's not going to work as it needs to be on the same subnet. Cheers Justin

3 3

Notification of NZRR Database changes
by NZRR Database Notifications 21 May '06

21 May '06

Dear Colleague, This is to notify you that some object(s) in NZRR database which you either maintain or are listed as to-be-notified have been added, deleted or changed. These objects are used to configure the various NZIX route servers (http://nzix.net/) so you can expect the relevant servers to be reloaded in the near future. The reloading of the servers is staggered over a period of time so that if you are peering with both servers at an exchange, you can maintain at least one BGP session at all times and consequently a full set of routes. --- PREVIOUS OBJECT: route-set: AS9560:RS-ROUTES:AS7657 descr: advertised to AS9560 by ihug - AS7657 members: 124.168.0.0/16^16-29, 203.59.0.0/16^16-29, 203.109.128.0/17^17-29, 203.118.128.0/17^17-29, 203.173.128.0/17^17-29, 203.206.0.0/17^17-29, 203.214.0.0/17^17-29, 210.84.0.0/18^18-29, 202.161.0.0/19^19-29, 203.96.192.0/19^19-29, 203.158.32.0/19^19-29, 203.166.224.0/19^19-29, 203.173.0.0/19^19-29, 203.206.128.0/19^19-29, 203.206.224.0/19^19-29, 203.214.128.0/19^19-29, 203.217.32.0/19^19-29, 203.217.64.0/19^19-29, 202.36.16.0/20^20-29, 202.46.160.0/20^20-29, 202.137.96.0/20^20-29, 203.173.32.0/20^20-29, 203.190.192.0/20^20-29, 202.49.64.0/21^21-29, 202.126.80.0/21^21-29, 202.129.80.0/21^21-29, 202.129.96.0/21^21-29, 203.173.48.0/21^21-29, 203.206.168.0/21^21-29, 203.206.176.0/21^21-29, 203.215.0.0/21^21-29, 203.217.0.0/21^21-29, 203.217.16.0/21^21-29, 210.55.248.0/21^21-29, 198.48.0.0/22^22-29, 202.8.44.0/22^22-29, 202.49.240.0/22^22-29, 202.50.188.0/22^22-29, 202.129.68.0/22^22-29, 202.129.76.0/22^22-29, 202.129.108.0/22^22-29, 202.129.116.0/22^22-29, 202.129.120.0/22^22-29, 203.14.168.0/22^22-29, 203.55.228.0/22^22-29, 203.57.140.0/22^22-29, 203.62.212.0/22^22-29, 203.173.56.0/22^22-29, 203.206.164.0/22^22-29, 203.206.184.0/22^22-29, 203.206.192.0/22^22-29, 203.206.204.0/22^22-29, 203.206.220.0/22^22-29, 203.215.8.0/22^22-29, 203.217.12.0/22^22-29, 203.217.28.0/22^22-29, 202.21.136.0/23^23-29, 202.36.94.0/23^23-29, 202.36.230.0/23^23-29, 202.49.46.0/23^23-29, 202.49.88.0/23^23-29, 202.49.148.0/23^23-29, 202.49.176.0/23^23-29, 202.49.180.0/23^23-29, 202.61.2.0/23^23-29, 202.128.110.0/23^23-29, 202.129.72.0/23^23-29, 202.129.88.0/23^23-29, 202.129.92.0/23^23-29, 202.129.106.0/23^23-29, 202.129.114.0/23^23-29, 203.7.196.0/23^23-29, 203.8.92.0/23^23-29, 203.14.174.0/23^23-29, 203.17.62.0/23^23-29, 203.21.74.0/23^23-29, 203.29.86.0/23^23-29, 203.55.140.0/23^23-29, 203.56.30.0/23^23-29, 203.56.62.0/23^23-29, 203.57.10.0/23^23-29, 203.57.136.0/23^23-29, 203.173.60.0/23^23-29, 203.206.162.0/23^23-29, 203.206.188.0/23^23-29, 203.206.202.0/23^23-29, 203.206.208.0/23^23-29, 203.206.218.0/23^23-29, 203.215.14.0/23^23-29, 203.215.18.0/23^23-29, 203.217.10.0/23^23-29, 210.55.202.0/23^23-29, 192.107.113.0/24^24-29, 192.188.107.0/24^24-29, 198.32.71.0/24^24-29, 199.98.84.0/24^24-29, 202.7.6.0/24^24-29, 202.12.87.0/24^24-29, 202.21.130.0/24^24-29, 202.36.44.0/24^24-29, 202.36.46.0/24^24-29, 202.36.174.0/24^24-29, 202.37.182.0/24^24-29, 202.49.33.0/24^24-29, 202.49.59.0/24^24-29, 202.49.63.0/24^24-29, 202.49.140.0/24^24-29, 202.49.144.0/24^24-29, 202.49.178.0/24^24-29, 202.49.186.0/24^24-29, 202.49.249.0/24^24-29, 202.50.84.0/24^24-29, 202.50.103.0/24^24-29, 202.50.255.0/24^24-29, 202.128.109.0/24^24-29, 202.129.67.0/24^24-29, 202.129.91.0/24^24-29, 202.129.94.0/24^24-29, 202.129.104.0/24^24-29, 202.129.112.0/24^24-29, 202.129.125.0/24^24-29, 202.129.126.0/24^24-29, 202.169.97.0/24^24-29, 202.176.0.0/24^24-29, 203.0.12.0/24^24-29, 203.0.84.0/24^24-29, 203.0.139.0/24^24-29, 203.0.178.0/24^24-29, 203.1.24.0/24^24-29, 203.1.78.0/24^24-29, 203.2.199.0/24^24-29, 203.3.127.0/24^24-29, 203.4.173.0/24^24-29, 203.5.184.0/24^24-29, 203.7.155.0/24^24-29, 203.7.173.0/24^24-29, 203.8.161.0/24^24-29, 203.8.219.0/24^24-29, 203.12.1.0/24^24-29, 203.12.15.0/24^24-29, 203.12.44.0/24^24-29, 203.12.236.0/24^24-29, 203.14.172.0/24^24-29, 203.14.182.0/24^24-29, 203.15.111.0/24^24-29, 203.15.129.0/24^24-29, 203.16.34.0/24^24-29, 203.17.60.0/24^24-29, 203.17.194.0/24^24-29, 203.17.249.0/24^24-29, 203.17.251.0/24^24-29, 203.18.85.0/24^24-29, 203.18.140.0/24^24-29, 203.19.70.0/24^24-29, 203.20.82.0/24^24-29, 203.20.88.0/24^24-29, 203.20.116.0/24^24-29, 203.20.132.0/24^24-29, 203.21.5.0/24^24-29, 203.21.105.0/24^24-29, 203.22.19.0/24^24-29, 203.22.96.0/24^24-29, 203.23.7.0/24^24-29, 203.24.50.0/24^24-29, 203.24.189.0/24^24-29, 203.25.109.0/24^24-29, 203.25.144.0/24^24-29, 203.25.197.0/24^24-29, 203.26.32.0/24^24-29, 203.26.86.0/24^24-29, 203.26.92.0/24^24-29, 203.26.128.0/24^24-29, 203.27.58.0/24^24-29, 203.27.60.0/24^24-29, 203.27.89.0/24^24-29, 203.27.201.0/24^24-29, 203.28.157.0/24^24-29, 203.28.174.0/24^24-29, 203.29.221.0/24^24-29, 203.30.181.0/24^24-29, 203.30.194.0/24^24-29, 203.31.13.0/24^24-29, 203.31.96.0/24^24-29, 203.31.141.0/24^24-29, 203.34.95.0/24^24-29, 203.55.151.0/24^24-29, 203.56.243.0/24^24-29, 203.57.134.0/24^24-29, 203.61.76.0/24^24-29, 203.102.166.0/24^24-29, 203.108.77.0/24^24-29, 203.112.114.0/24^24-29, 203.173.63.0/24^24-29, 203.206.161.0/24^24-29, 203.206.190.0/24^24-29, 203.206.196.0/24^24-29, 203.206.198.0/24^24-29, 203.206.201.0/24^24-29, 203.206.213.0/24^24-29, 203.206.214.0/24^24-29, 203.206.217.0/24^24-29, 203.215.12.0/24^24-29, 203.215.17.0/24^24-29, 203.215.20.0/24^24-29, 210.8.138.0/24^24-29, 210.55.110.0/24^24-29, 210.55.184.0/24^24-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: noc(a)ihug.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20060403 source: NZRR REPLACED BY: route-set: AS9560:RS-ROUTES:AS7657 descr: advertised to AS9560 by IHUG - AS7657 members: 124.168.0.0/16^16-29, 203.59.0.0/16^16-29, 203.109.128.0/17^17-29, 203.118.128.0/17^17-29, 203.173.128.0/17^17-29, 203.206.0.0/17^17-29, 203.214.0.0/17^17-29, 210.84.0.0/18^18-29, 202.161.0.0/19^19-29, 203.96.192.0/19^19-29, 203.158.32.0/19^19-29, 203.166.224.0/19^19-29, 203.173.0.0/19^19-29, 203.206.128.0/19^19-29, 203.206.224.0/19^19-29, 203.214.128.0/19^19-29, 203.217.32.0/19^19-29, 203.217.64.0/19^19-29, 202.36.16.0/20^20-29, 202.46.160.0/20^20-29, 202.137.96.0/20^20-29, 203.173.32.0/20^20-29, 203.190.192.0/20^20-29, 202.49.64.0/21^21-29, 202.126.80.0/21^21-29, 202.129.80.0/21^21-29, 202.129.96.0/21^21-29, 203.173.48.0/21^21-29, 203.206.168.0/21^21-29, 203.206.176.0/21^21-29, 203.215.0.0/21^21-29, 203.217.0.0/21^21-29, 203.217.16.0/21^21-29, 210.55.248.0/21^21-29, 198.48.0.0/22^22-29, 202.8.44.0/22^22-29, 202.49.240.0/22^22-29, 202.50.188.0/22^22-29, 202.129.68.0/22^22-29, 202.129.76.0/22^22-29, 202.129.108.0/22^22-29, 202.129.116.0/22^22-29, 202.129.120.0/22^22-29, 203.14.168.0/22^22-29, 203.55.228.0/22^22-29, 203.57.140.0/22^22-29, 203.62.212.0/22^22-29, 203.173.56.0/22^22-29, 203.206.164.0/22^22-29, 203.206.184.0/22^22-29, 203.206.192.0/22^22-29, 203.206.204.0/22^22-29, 203.206.220.0/22^22-29, 203.215.8.0/22^22-29, 203.217.12.0/22^22-29, 203.217.28.0/22^22-29, 202.21.136.0/23^23-29, 202.36.94.0/23^23-29, 202.36.230.0/23^23-29, 202.49.46.0/23^23-29, 202.49.88.0/23^23-29, 202.49.148.0/23^23-29, 202.49.176.0/23^23-29, 202.49.180.0/23^23-29, 202.61.2.0/23^23-29, 202.128.110.0/23^23-29, 202.129.72.0/23^23-29, 202.129.88.0/23^23-29, 202.129.92.0/23^23-29, 202.129.106.0/23^23-29, 202.129.114.0/23^23-29, 203.7.196.0/23^23-29, 203.8.92.0/23^23-29, 203.14.174.0/23^23-29, 203.17.62.0/23^23-29, 203.21.74.0/23^23-29, 203.29.86.0/23^23-29, 203.55.140.0/23^23-29, 203.56.30.0/23^23-29, 203.56.62.0/23^23-29, 203.57.10.0/23^23-29, 203.57.136.0/23^23-29, 203.173.60.0/23^23-29, 203.206.162.0/23^23-29, 203.206.188.0/23^23-29, 203.206.202.0/23^23-29, 203.206.208.0/23^23-29, 203.206.218.0/23^23-29, 203.215.14.0/23^23-29, 203.215.18.0/23^23-29, 203.215.20.0/23^23-29, 203.217.10.0/23^23-29, 210.55.202.0/23^23-29, 192.107.113.0/24^24-29, 192.188.107.0/24^24-29, 198.32.71.0/24^24-29, 199.98.84.0/24^24-29, 202.7.6.0/24^24-29, 202.12.87.0/24^24-29, 202.21.130.0/24^24-29, 202.36.44.0/24^24-29, 202.36.46.0/24^24-29, 202.36.174.0/24^24-29, 202.37.182.0/24^24-29, 202.49.33.0/24^24-29, 202.49.59.0/24^24-29, 202.49.63.0/24^24-29, 202.49.140.0/24^24-29, 202.49.144.0/24^24-29, 202.49.178.0/24^24-29, 202.49.186.0/24^24-29, 202.49.249.0/24^24-29, 202.50.84.0/24^24-29, 202.50.103.0/24^24-29, 202.50.255.0/24^24-29, 202.128.109.0/24^24-29, 202.129.67.0/24^24-29, 202.129.91.0/24^24-29, 202.129.94.0/24^24-29, 202.129.104.0/24^24-29, 202.129.112.0/24^24-29, 202.129.125.0/24^24-29, 202.129.126.0/24^24-29, 202.169.97.0/24^24-29, 202.176.0.0/24^24-29, 203.0.12.0/24^24-29, 203.0.84.0/24^24-29, 203.0.139.0/24^24-29, 203.0.178.0/24^24-29, 203.1.24.0/24^24-29, 203.1.78.0/24^24-29, 203.2.199.0/24^24-29, 203.3.127.0/24^24-29, 203.4.173.0/24^24-29, 203.5.184.0/24^24-29, 203.7.155.0/24^24-29, 203.7.173.0/24^24-29, 203.8.161.0/24^24-29, 203.8.219.0/24^24-29, 203.12.1.0/24^24-29, 203.12.15.0/24^24-29, 203.12.44.0/24^24-29, 203.12.236.0/24^24-29, 203.14.172.0/24^24-29, 203.14.182.0/24^24-29, 203.15.111.0/24^24-29, 203.15.129.0/24^24-29, 203.16.34.0/24^24-29, 203.17.60.0/24^24-29, 203.17.194.0/24^24-29, 203.17.249.0/24^24-29, 203.17.251.0/24^24-29, 203.18.85.0/24^24-29, 203.18.140.0/24^24-29, 203.19.70.0/24^24-29, 203.20.82.0/24^24-29, 203.20.88.0/24^24-29, 203.20.116.0/24^24-29, 203.20.132.0/24^24-29, 203.21.5.0/24^24-29, 203.21.105.0/24^24-29, 203.22.19.0/24^24-29, 203.22.96.0/24^24-29, 203.23.7.0/24^24-29, 203.24.50.0/24^24-29, 203.24.189.0/24^24-29, 203.25.109.0/24^24-29, 203.25.144.0/24^24-29, 203.25.197.0/24^24-29, 203.26.32.0/24^24-29, 203.26.86.0/24^24-29, 203.26.92.0/24^24-29, 203.26.128.0/24^24-29, 203.27.58.0/24^24-29, 203.27.60.0/24^24-29, 203.27.89.0/24^24-29, 203.27.201.0/24^24-29, 203.28.157.0/24^24-29, 203.28.174.0/24^24-29, 203.29.221.0/24^24-29, 203.30.181.0/24^24-29, 203.30.194.0/24^24-29, 203.31.13.0/24^24-29, 203.31.96.0/24^24-29, 203.31.141.0/24^24-29, 203.34.95.0/24^24-29, 203.55.151.0/24^24-29, 203.56.243.0/24^24-29, 203.57.134.0/24^24-29, 203.61.76.0/24^24-29, 203.102.166.0/24^24-29, 203.108.77.0/24^24-29, 203.112.114.0/24^24-29, 203.173.63.0/24^24-29, 203.206.161.0/24^24-29, 203.206.190.0/24^24-29, 203.206.196.0/24^24-29, 203.206.198.0/24^24-29, 203.206.201.0/24^24-29, 203.206.213.0/24^24-29, 203.206.214.0/24^24-29, 203.206.217.0/24^24-29, 203.215.12.0/24^24-29, 203.215.17.0/24^24-29, 210.8.138.0/24^24-29, 210.55.110.0/24^24-29, 210.55.184.0/24^24-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: pshem.k(a)staff.ihug.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20060522 source: NZRR --- PREVIOUS OBJECT: route-set: AS9439:RS-ROUTES:AS7657 descr: advertised to AS9439 by Ihug Ltd - AS7657 members: 124.168.0.0/16^16-29, 203.59.0.0/16^16-29, 203.109.128.0/17^17-29, 203.118.128.0/17^17-29, 203.173.128.0/17^17-29, 203.206.0.0/17^17-29, 203.214.0.0/17^17-29, 210.84.0.0/18^18-29, 202.161.0.0/19^19-29, 203.96.192.0/19^19-29, 203.158.32.0/19^19-29, 203.166.224.0/19^19-29, 203.173.0.0/19^19-29, 203.206.128.0/19^19-29, 203.206.224.0/19^19-29, 203.214.128.0/19^19-29, 203.217.32.0/19^19-29, 203.217.64.0/19^19-29, 202.36.16.0/20^20-29, 202.46.160.0/20^20-29, 202.137.96.0/20^20-29, 203.173.32.0/20^20-29, 203.190.192.0/20^20-29, 202.49.64.0/21^21-29, 202.126.80.0/21^21-29, 202.129.80.0/21^21-29, 202.129.96.0/21^21-29, 203.173.48.0/21^21-29, 203.206.168.0/21^21-29, 203.206.176.0/21^21-29, 203.215.0.0/21^21-29, 203.217.0.0/21^21-29, 203.217.16.0/21^21-29, 210.55.248.0/21^21-29, 198.48.0.0/22^22-29, 202.8.44.0/22^22-29, 202.49.240.0/22^22-29, 202.50.188.0/22^22-29, 202.129.68.0/22^22-29, 202.129.76.0/22^22-29, 202.129.108.0/22^22-29, 202.129.116.0/22^22-29, 202.129.120.0/22^22-29, 203.14.168.0/22^22-29, 203.55.228.0/22^22-29, 203.57.140.0/22^22-29, 203.62.212.0/22^22-29, 203.173.56.0/22^22-29, 203.206.164.0/22^22-29, 203.206.184.0/22^22-29, 203.206.192.0/22^22-29, 203.206.204.0/22^22-29, 203.206.220.0/22^22-29, 203.215.8.0/22^22-29, 203.217.12.0/22^22-29, 203.217.28.0/22^22-29, 202.21.136.0/23^23-29, 202.36.94.0/23^23-29, 202.36.230.0/23^23-29, 202.49.46.0/23^23-29, 202.49.88.0/23^23-29, 202.49.148.0/23^23-29, 202.49.176.0/23^23-29, 202.49.180.0/23^23-29, 202.61.2.0/23^23-29, 202.128.110.0/23^23-29, 202.129.72.0/23^23-29, 202.129.88.0/23^23-29, 202.129.92.0/23^23-29, 202.129.106.0/23^23-29, 202.129.114.0/23^23-29, 203.7.196.0/23^23-29, 203.8.92.0/23^23-29, 203.14.174.0/23^23-29, 203.17.62.0/23^23-29, 203.21.74.0/23^23-29, 203.29.86.0/23^23-29, 203.55.140.0/23^23-29, 203.56.30.0/23^23-29, 203.56.62.0/23^23-29, 203.57.10.0/23^23-29, 203.57.136.0/23^23-29, 203.173.60.0/23^23-29, 203.206.162.0/23^23-29, 203.206.188.0/23^23-29, 203.206.202.0/23^23-29, 203.206.208.0/23^23-29, 203.206.218.0/23^23-29, 203.215.14.0/23^23-29, 203.215.18.0/23^23-29, 203.217.10.0/23^23-29, 210.55.202.0/23^23-29, 192.107.113.0/24^24-29, 192.188.107.0/24^24-29, 198.32.71.0/24^24-29, 199.98.84.0/24^24-29, 202.7.6.0/24^24-29, 202.12.87.0/24^24-29, 202.21.130.0/24^24-29, 202.36.44.0/24^24-29, 202.36.46.0/24^24-29, 202.36.174.0/24^24-29, 202.37.182.0/24^24-29, 202.49.33.0/24^24-29, 202.49.59.0/24^24-29, 202.49.63.0/24^24-29, 202.49.140.0/24^24-29, 202.49.144.0/24^24-29, 202.49.178.0/24^24-29, 202.49.186.0/24^24-29, 202.49.249.0/24^24-29, 202.50.84.0/24^24-29, 202.50.103.0/24^24-29, 202.50.255.0/24^24-29, 202.128.109.0/24^24-29, 202.129.67.0/24^24-29, 202.129.91.0/24^24-29, 202.129.94.0/24^24-29, 202.129.104.0/24^24-29, 202.129.112.0/24^24-29, 202.129.125.0/24^24-29, 202.129.126.0/24^24-29, 202.169.97.0/24^24-29, 202.176.0.0/24^24-29, 203.0.12.0/24^24-29, 203.0.84.0/24^24-29, 203.0.139.0/24^24-29, 203.0.178.0/24^24-29, 203.1.24.0/24^24-29, 203.1.78.0/24^24-29, 203.2.199.0/24^24-29, 203.3.127.0/24^24-29, 203.4.173.0/24^24-29, 203.5.184.0/24^24-29, 203.7.155.0/24^24-29, 203.7.173.0/24^24-29, 203.8.161.0/24^24-29, 203.8.219.0/24^24-29, 203.12.1.0/24^24-29, 203.12.15.0/24^24-29, 203.12.44.0/24^24-29, 203.12.236.0/24^24-29, 203.14.172.0/24^24-29, 203.14.182.0/24^24-29, 203.15.111.0/24^24-29, 203.15.129.0/24^24-29, 203.16.34.0/24^24-29, 203.17.60.0/24^24-29, 203.17.194.0/24^24-29, 203.17.249.0/24^24-29, 203.17.251.0/24^24-29, 203.18.85.0/24^24-29, 203.18.140.0/24^24-29, 203.19.70.0/24^24-29, 203.20.82.0/24^24-29, 203.20.88.0/24^24-29, 203.20.116.0/24^24-29, 203.20.132.0/24^24-29, 203.21.5.0/24^24-29, 203.21.105.0/24^24-29, 203.22.19.0/24^24-29, 203.22.96.0/24^24-29, 203.23.7.0/24^24-29, 203.24.50.0/24^24-29, 203.24.189.0/24^24-29, 203.25.109.0/24^24-29, 203.25.144.0/24^24-29, 203.25.197.0/24^24-29, 203.26.32.0/24^24-29, 203.26.86.0/24^24-29, 203.26.92.0/24^24-29, 203.26.128.0/24^24-29, 203.27.58.0/24^24-29, 203.27.60.0/24^24-29, 203.27.89.0/24^24-29, 203.27.201.0/24^24-29, 203.28.157.0/24^24-29, 203.28.174.0/24^24-29, 203.29.221.0/24^24-29, 203.30.181.0/24^24-29, 203.30.194.0/24^24-29, 203.31.13.0/24^24-29, 203.31.96.0/24^24-29, 203.31.141.0/24^24-29, 203.34.95.0/24^24-29, 203.55.151.0/24^24-29, 203.56.243.0/24^24-29, 203.57.134.0/24^24-29, 203.61.76.0/24^24-29, 203.102.166.0/24^24-29, 203.108.77.0/24^24-29, 203.112.114.0/24^24-29, 203.173.63.0/24^24-29, 203.206.161.0/24^24-29, 203.206.190.0/24^24-29, 203.206.196.0/24^24-29, 203.206.198.0/24^24-29, 203.206.201.0/24^24-29, 203.206.213.0/24^24-29, 203.206.214.0/24^24-29, 203.206.217.0/24^24-29, 203.215.12.0/24^24-29, 203.215.17.0/24^24-29, 203.215.20.0/24^24-29, 210.8.138.0/24^24-29, 210.55.110.0/24^24-29, 210.55.184.0/24^24-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: noc(a)ihug.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20060403 source: NZRR REPLACED BY: route-set: AS9439:RS-ROUTES:AS7657 descr: advertised to AS9439 by IHUG - AS7657 members: 124.168.0.0/16^16-29, 203.59.0.0/16^16-29, 203.109.128.0/17^17-29, 203.118.128.0/17^17-29, 203.173.128.0/17^17-29, 203.206.0.0/17^17-29, 203.214.0.0/17^17-29, 210.84.0.0/18^18-29, 202.161.0.0/19^19-29, 203.96.192.0/19^19-29, 203.158.32.0/19^19-29, 203.166.224.0/19^19-29, 203.173.0.0/19^19-29, 203.206.128.0/19^19-29, 203.206.224.0/19^19-29, 203.214.128.0/19^19-29, 203.217.32.0/19^19-29, 203.217.64.0/19^19-29, 202.36.16.0/20^20-29, 202.46.160.0/20^20-29, 202.137.96.0/20^20-29, 203.173.32.0/20^20-29, 203.190.192.0/20^20-29, 202.49.64.0/21^21-29, 202.126.80.0/21^21-29, 202.129.80.0/21^21-29, 202.129.96.0/21^21-29, 203.173.48.0/21^21-29, 203.206.168.0/21^21-29, 203.206.176.0/21^21-29, 203.215.0.0/21^21-29, 203.217.0.0/21^21-29, 203.217.16.0/21^21-29, 210.55.248.0/21^21-29, 198.48.0.0/22^22-29, 202.8.44.0/22^22-29, 202.49.240.0/22^22-29, 202.50.188.0/22^22-29, 202.129.68.0/22^22-29, 202.129.76.0/22^22-29, 202.129.108.0/22^22-29, 202.129.116.0/22^22-29, 202.129.120.0/22^22-29, 203.14.168.0/22^22-29, 203.55.228.0/22^22-29, 203.57.140.0/22^22-29, 203.62.212.0/22^22-29, 203.173.56.0/22^22-29, 203.206.164.0/22^22-29, 203.206.184.0/22^22-29, 203.206.192.0/22^22-29, 203.206.204.0/22^22-29, 203.206.220.0/22^22-29, 203.215.8.0/22^22-29, 203.217.12.0/22^22-29, 203.217.28.0/22^22-29, 202.21.136.0/23^23-29, 202.36.94.0/23^23-29, 202.36.230.0/23^23-29, 202.49.46.0/23^23-29, 202.49.88.0/23^23-29, 202.49.148.0/23^23-29, 202.49.176.0/23^23-29, 202.49.180.0/23^23-29, 202.61.2.0/23^23-29, 202.128.110.0/23^23-29, 202.129.72.0/23^23-29, 202.129.88.0/23^23-29, 202.129.92.0/23^23-29, 202.129.106.0/23^23-29, 202.129.114.0/23^23-29, 203.7.196.0/23^23-29, 203.8.92.0/23^23-29, 203.14.174.0/23^23-29, 203.17.62.0/23^23-29, 203.21.74.0/23^23-29, 203.29.86.0/23^23-29, 203.55.140.0/23^23-29, 203.56.30.0/23^23-29, 203.56.62.0/23^23-29, 203.57.10.0/23^23-29, 203.57.136.0/23^23-29, 203.173.60.0/23^23-29, 203.206.162.0/23^23-29, 203.206.188.0/23^23-29, 203.206.202.0/23^23-29, 203.206.208.0/23^23-29, 203.206.218.0/23^23-29, 203.215.14.0/23^23-29, 203.215.18.0/23^23-29, 203.215.20.0/23^23-29, 203.217.10.0/23^23-29, 210.55.202.0/23^23-29, 192.107.113.0/24^24-29, 192.188.107.0/24^24-29, 198.32.71.0/24^24-29, 199.98.84.0/24^24-29, 202.7.6.0/24^24-29, 202.12.87.0/24^24-29, 202.21.130.0/24^24-29, 202.36.44.0/24^24-29, 202.36.46.0/24^24-29, 202.36.174.0/24^24-29, 202.37.182.0/24^24-29, 202.49.33.0/24^24-29, 202.49.59.0/24^24-29, 202.49.63.0/24^24-29, 202.49.140.0/24^24-29, 202.49.144.0/24^24-29, 202.49.178.0/24^24-29, 202.49.186.0/24^24-29, 202.49.249.0/24^24-29, 202.50.84.0/24^24-29, 202.50.103.0/24^24-29, 202.50.255.0/24^24-29, 202.128.109.0/24^24-29, 202.129.67.0/24^24-29, 202.129.91.0/24^24-29, 202.129.94.0/24^24-29, 202.129.104.0/24^24-29, 202.129.112.0/24^24-29, 202.129.125.0/24^24-29, 202.129.126.0/24^24-29, 202.169.97.0/24^24-29, 202.176.0.0/24^24-29, 203.0.12.0/24^24-29, 203.0.84.0/24^24-29, 203.0.139.0/24^24-29, 203.0.178.0/24^24-29, 203.1.24.0/24^24-29, 203.1.78.0/24^24-29, 203.2.199.0/24^24-29, 203.3.127.0/24^24-29, 203.4.173.0/24^24-29, 203.5.184.0/24^24-29, 203.7.155.0/24^24-29, 203.7.173.0/24^24-29, 203.8.161.0/24^24-29, 203.8.219.0/24^24-29, 203.12.1.0/24^24-29, 203.12.15.0/24^24-29, 203.12.44.0/24^24-29, 203.12.236.0/24^24-29, 203.14.172.0/24^24-29, 203.14.182.0/24^24-29, 203.15.111.0/24^24-29, 203.15.129.0/24^24-29, 203.16.34.0/24^24-29, 203.17.60.0/24^24-29, 203.17.194.0/24^24-29, 203.17.249.0/24^24-29, 203.17.251.0/24^24-29, 203.18.85.0/24^24-29, 203.18.140.0/24^24-29, 203.19.70.0/24^24-29, 203.20.82.0/24^24-29, 203.20.88.0/24^24-29, 203.20.116.0/24^24-29, 203.20.132.0/24^24-29, 203.21.5.0/24^24-29, 203.21.105.0/24^24-29, 203.22.19.0/24^24-29, 203.22.96.0/24^24-29, 203.23.7.0/24^24-29, 203.24.50.0/24^24-29, 203.24.189.0/24^24-29, 203.25.109.0/24^24-29, 203.25.144.0/24^24-29, 203.25.197.0/24^24-29, 203.26.32.0/24^24-29, 203.26.86.0/24^24-29, 203.26.92.0/24^24-29, 203.26.128.0/24^24-29, 203.27.58.0/24^24-29, 203.27.60.0/24^24-29, 203.27.89.0/24^24-29, 203.27.201.0/24^24-29, 203.28.157.0/24^24-29, 203.28.174.0/24^24-29, 203.29.221.0/24^24-29, 203.30.181.0/24^24-29, 203.30.194.0/24^24-29, 203.31.13.0/24^24-29, 203.31.96.0/24^24-29, 203.31.141.0/24^24-29, 203.34.95.0/24^24-29, 203.55.151.0/24^24-29, 203.56.243.0/24^24-29, 203.57.134.0/24^24-29, 203.61.76.0/24^24-29, 203.102.166.0/24^24-29, 203.108.77.0/24^24-29, 203.112.114.0/24^24-29, 203.173.63.0/24^24-29, 203.206.161.0/24^24-29, 203.206.190.0/24^24-29, 203.206.196.0/24^24-29, 203.206.198.0/24^24-29, 203.206.201.0/24^24-29, 203.206.213.0/24^24-29, 203.206.214.0/24^24-29, 203.206.217.0/24^24-29, 203.215.12.0/24^24-29, 203.215.17.0/24^24-29, 210.8.138.0/24^24-29, 210.55.110.0/24^24-29, 210.55.184.0/24^24-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: pshem.k(a)staff.ihug.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20060522 source: NZRR

1 0

Are there any blakjak.net mail admins on this list?
by Juha Saarinen 20 May '06

20 May '06

The subject of the message is: Re: [nznog] SORBS still causing serious problems... The address to which the message has not yet been delivered is: blakjak(a)blakjak.net Delay reason: SMTP error from remote mail server after RCPT TO:<blakjak(a)blakjak.net>: host mx.blakjak.net [202.50.176.75]: 451 Dynamic IP Addresses See: http://www.sorbs.net/lookup.shtml?xxx.xxx.xxx.xxx "Does this not go back to people using the dnsBL the wrong way... (!) People who choose to use them to _drop_ mail need to instead be using them to _score_ mail... Surely people who are losing mission-critical services due to this should instead be petitioning relevant ISPs to change their dnsBL practises?" Yes yes! I agree! On a more serious note, even Outblaze bounces messages now based on the wrong SORBS listing. @#(*)^$@!!! -- Juha Saarinen www.geekzone.co.nz/juha www.computerworld.co.nz

2 2

E mails
by suzanne gerrard 20 May '06

20 May '06

3 2

Ihug Mail Admin?
by Erin Salmon - Unleash 20 May '06

20 May '06

Hi, If there are any Ihug Mail Admins floating around on the list would you be so good as to put your hand up? One of your customers is sending out thousands of promo newsletters with several images attached. It has been running since Friday and a number of our clients are already facing several hundred dollar excess usage charges from our good friends at Telecom from downloading it all. They have stupidly put the addresses in the CC field, and I believe the problem may be that some of the CC field recipients are running MS Exchange 2000. There is a bug if it is configured for open relaying which resends emails to the list of addresses if there are more than a certain number. I recall having this issue a year or two ago, but Im a bit hazy on the details, and Im not a mail guru myself. The KB seems to be taking this convenient moment to throw an error when I try to search it. If I recall correctly, SP3 for Exchange 2000 fixed the problem, so with any luck there would only be only server in the recipient list with the problem and we can stamp it out. If anyone recalls this Exchange issue, Id appreciate a steer too. Cheers, Erin Salmon Managing Director Unleash Technology Solutions <http://www.unleash.net.nz/> Phone: +64 3 365 1273 Mobile: +64 21 877 913 -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.392 / Virus Database: 268.6.1/344 - Release Date: 19/05/2006

3 3

Static IP in a hurry ?
by Richard Naylor 19 May '06

19 May '06

Anyone from Xtra online tonight ? I have one of your customers who needs a static IP number in a hurry. A family member has died and they're webcasting the tangi. We've had 3 number changes in as many minutes. - They'll pay. Rich

1 1

SORBS still causing serious problems...
by Kris Angerano 19 May '06

19 May '06

Heya NZ guys. I work for an ISP out in Oregon US (EasyStreet). And we have recently been hit hard by the mistakes at SORBS. They have mistakenly added our 209.x static group as a dynamic IP range and blocked them all. This has been happening for 5 days now. We have submitted tickets to Matthew and his crew describing the problem and we even gave him our entire Dynamic and Static IP Blocks. To no avail, our RT ticket sits there untouched and the problem is unresolved. RT 77734, 76636 The worse part is we use SORBS, so initially we couldn't even receive some of our own customers email. Since then we have whitelisted our own IP block to solve that problem. But that isn't even a band aid. I called Matthew yesterday and he explained to me about his current 'troubles' so I didn't give him a hard time about our ticket. But this is getting ridiculous. A significant part of our 209.x block is business customers with their own mail servers. They are getting frustrated and we may start to lose business because of this. If anyone cares or has their eyes open out there, we need some help please! Thanks, Kris A

5 5

Re: [nznog] SORBS still listing Telecom static IPs as dynamic...
by Donald Neal 18 May '06

18 May '06

> > > > Please don't use American English. Won't someone please think of the > > children! > > > > American English, thats an oxymoron isnt it ? > I have no doubt of the relevance of most of this thread, but it seems to have now run its course. - Donald Neal List Asministrator Donald Neal |"Email is not to be used to pass on Support Engineer |information or data. It should be NGN Operations |used only for company business." Integration & Services Division +----------------------------------- Alcatel NZ Ltd - Telecom's network operations manager 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. Please note that this communication does not designate an information system for the purposes of the Electronic Transactions Act 2002.

1 0

Re: [nznog] SORBS still listing Telecom static IPs as dynamic...
by Scott Weeks 18 May '06

18 May '06

----- Original Message Follows ----- From: "Jamie Riden" <jamesr(a)europe.com> > > No other blacklist operates like - or generates the hate > > - that S(ORBS) does. > > Actually, I've seen people say that and worse about every > single blacklist including SBL, which is probably the most > conservative one, all the way back to the MAPS original. They all say that if you're not a spammer, you have to pay LOTS of money to people they tell you to pay to be delisted? http://www.au.sorbs.net/faq/spamdb.shtml "Third and finally, if you are really not a spammer, or you are truly reformed, de-listing is relatively easy. You donate US$50 to a charity or trust approved by, and not connected with, SORBS for each spam received related to the listing. This is referred to as the SORBS 'fine'." scott

5 4

Re: [nznog] SORBS still listing Telecom static IPs as dynamic...
by Jeremy Strachan 18 May '06

18 May '06

My view is SORBS is a crock of shit, as was ORBS. If the day ends in "y" they block it ... Its called all care - no responsibility... They will blacklist entire (static) IP ranges with no warning, and no realistic way of removing the block, and treat everyone like s..t. The process is inherently flawed, because of the way static ranges end up on their list without reasonable checks. If they blocked a single IP address - then fine, its their wholesale and cavalier attitude to blocking entire ranges that is the root cause of the problem I have with S(ORBS), and why they are hated so much by people like me. No other blacklist operates like - or generates the hate - that S(ORBS) does. If they vanished tommorrow, the world would be a better place. Jeremy -----Original Message----- From: Tony Wicks [mailto:tony(a)prophecy.net.nz] Sent: Thursday, 18 May 2006 7:06 p.m. Cc: nznog(a)list.waikato.ac.nz Subject: Re: [nznog] SORBS still listing Telecom static IPs as dynamic... >> > One would wonder why any sane mail admin wouldnt pull data from as > many sources as possible when deciding on how to score spam. > Sure, but surely there has to be some measure of accuracy involved ? I mean SORBS is about as accurate as choosing every even IP address on Monday and public holidays, every odd one on every other day. It's just not even close to being what it is supposed to be billed as. _______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog

3 2

ANZ Phish
by Joseph Miller 16 May '06

16 May '06

Just a heads-up: I just got sent a phishing scam email for the ANZ... Subject is ANZ Account Security Measures, included link ends up at: http://www.sunrise.cc/bbs/anz.php Relevant parts of the header as follows: Received: from [210.205.6.77] (helo=web-77.blueweb.co.kr) by exorsus.net with esmtp (Exim 4.52) id 1FgAyH-0006MQ-Oq for joff(a)XXXXXXXX.com; Wed, 17 May 2006 13:37:15 +1200 Received: (from apache(a)localhost) by web-77.blueweb.co.kr (8.11.6/8.11.6) id k4H1avJ20690; Wed, 17 May 2006 10:36:57 +0900 Date: Wed, 17 May 2006 10:36:57 +0900 Message-Id: <200605170136.k4H1avJ20690(a)web-77.blueweb.co.kr> To: joff(a)XXXXXXXXXXX.com Subject: ANZ Account Security Measures From: <service(a)anz.com> Reply-To: service(a)anz.com -- Thanks, Joseph Miller Application Developer _________________________________________ http://www.digiweb.co.nz Webhosting, Dedicated Servers, E-commerce Phone: (64 3) 351 6713 PLEASE NOTE: The information contained in this email message and any attached files may be confidential and subject to privilege. The views expressed may not necessarily be the official view of Digiweb New Zealand Limited. All technical advice and opinions are offered on a 'no-liability' basis. If you are not the intended recipient, you are notified that any use, disclosure or copying of this email is unauthorised. If you have received this email in error, please notify us immediately by reply email and delete the original. Thank you.

1 0

Xtra Nationwide outage?
by Tristram Cheer 15 May '06

15 May '06

Anybody know anything about this? I got phones ringing off the hook from people saying xtra's got a nationwide outage right now. Rat got their cable again? -- ----------------------- Tristram Cheer UberNetworks Level 1 2a Vine St Whangarei 0101 M:021-715-823 W:09-438-5472 F:09-438-5473

6 6

Xtra on Spamcop now.
by Chris Hodgetts 14 May '06

14 May '06

May 15 11:12:35 caitlin postfix/smtpd[20038]: NOQUEUE: reject: RCPT from fep03.xtra.co.nz[210.54.141.243]: 554 Service unavailable; Client host [210.54.141.243] blocked using bl.spamcop.net; Blocked - see http://www.spamcop.net/bl.shtml?210.54.141.243; from=<someuser(a)xtra.co.nz> to=<user(a)domainname.com> proto=ESMTP helo=<fep03.xtra.co.nz> May 15 11:12:35 caitlin postfix/smtpd[20038]: disconnect from fep03.xtra.co.nz[210.54.141.243]

6 5

Re: [nznog] Xtra on Spamcop now.
by Ted Grenfell 14 May '06

14 May '06

So a particular customer of ours is having all email from you marked up as spam? Kind Regards, Ted Grenfell ISP Performance Manager T +64 9 359 5854 (extn 93254) F +64 9 377 0781 M +64 27 443 5455 E ted.grenfell(a)telecom.co.nz W www.telecom.co.nz Level 11, Telecom House, 8 Hereford Street, Private Bag 92028, Auckland CBD, New Zealand ________________________________ "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. Please note that this communication does not designate an information system for the purposes of the Electronic Transactions Act 2002." > -----Original Message----- > From: Joseph Miller [mailto:joseph(a)digiweb.net.nz] > Sent: Monday, 15 May 2006 11:47 a.m. > To: Ted Grenfell; nznog(a)list.waikato.ac.nz > Subject: Re: [nznog] Xtra on Spamcop now. > > Ted Grenfell wrote on 15/05/06 11:35: > > What IP addresses are you sending to Joseph? > Sending to mta.xtra.co.nz (210.54.141.1) > > > Any logs you can flick through? > I'll get our mail admin to dig up some SMTP delivery logs when he gets a > spare second, and we've got > someone who's going to send us some mail headers from a junked mail > > > What exactly do you mean by "Junked"? > All the mail is being put in the xtra customer's Junk mail folder > > > > > -- > Thanks, > Joseph Miller > Application Developer > _________________________________________ > http://www.digiweb.co.nz > Webhosting, Dedicated Servers, E-commerce > Phone: (64 3) 351 6713 > > PLEASE NOTE: The information contained in this email message and any > attached files may be > confidential and subject to privilege. The views expressed may not > necessarily be the official view > of Digiweb New Zealand Limited. All technical advice and opinions are > offered on a 'no-liability' > basis. If you are not the intended recipient, you are notified that any > use, disclosure or copying > of this email is unauthorised. If you have received this email in error, > please notify us > immediately by reply email and delete the original. Thank you.

3 2

Re: [nznog] Xtra on Spamcop now.
by Joseph Miller 14 May '06

14 May '06

Ted Grenfell wrote on 15/05/06 11:35: > What IP addresses are you sending to Joseph? Sending to mta.xtra.co.nz (210.54.141.1) > Any logs you can flick through? I'll get our mail admin to dig up some SMTP delivery logs when he gets a spare second, and we've got someone who's going to send us some mail headers from a junked mail > What exactly do you mean by "Junked"? All the mail is being put in the xtra customer's Junk mail folder -- Thanks, Joseph Miller Application Developer _________________________________________ http://www.digiweb.co.nz Webhosting, Dedicated Servers, E-commerce Phone: (64 3) 351 6713 PLEASE NOTE: The information contained in this email message and any attached files may be confidential and subject to privilege. The views expressed may not necessarily be the official view of Digiweb New Zealand Limited. All technical advice and opinions are offered on a 'no-liability' basis. If you are not the intended recipient, you are notified that any use, disclosure or copying of this email is unauthorised. If you have received this email in error, please notify us immediately by reply email and delete the original. Thank you.

1 0

Hosting Providers w/ unlimited traffic plans
by Jonathan Brewer 14 May '06

14 May '06

Hi Folks, We would like to hear from any web hosting provider with unlimited international traffic plans (rate shaped) or arrangements for dual US/NZ servers. A menu of service like "3U box hosting = $n, international traffic @ $n per 64kbps would be appreciated. Cheers, Jon ------------------------- Araneo Limited 230B Left Bank Cuba Street Wellington 6001 Ph: 04 978 7350 Fx: 04 978 7355 Mb: 021 345 054 http://www.araneo.net.nz/ -------------------------

1 0

Re: [nznog] Community Attributes
by Philip D'Ath 11 May '06

11 May '06

Perhaps a good place to start would be to get APE and WIX to implement a common policy, and then those that peer at those locations are likely to follow suit. -----Original Message----- ... Another thing I've also been thinking about is community attributes. Using it to turn on remote blackholing with upstreams is useful, and we saw at NZNOG the approach to communicate enhancements or variations of that. But lowest common denominator suggests that using an agreed set of community attributes (which works for everyone) to convey stuff is something that should be worked on first. So, combining an agreed set of local_pref's and some community attributes might be the basis of building a broader, and faster exchange between participants. Community String Attributes 1000 Route is locally-originated, and should be exported 1000 Route is locally-originated, but should be suppressed towards peers 1002 Route is a blackhole route 1100 Route was learnt from a customer 1200 Route was learnt from a peer 1300 Route was learnt from a backbone 1400 Route was learnt from a transit provider (domestic/international) Local Preference Values 130 - locally-originated 120 - customers 110 - peers 90 - backbone 85 - domestic 80 - international ...

3 4

Latest Opera Version (8.52) and Secure Sites
by Craig Whitmore 11 May '06

11 May '06

Just a headsup to NZ ISP's who may have customers using the latest version of Opera and unable to connect correctly to some secure sites such as the ANZ Bank Website. http://my.opera.com/community/forums/topic.dml?id=138010 Thanks Craig Whitmore

1 0

Your Local 'Local Preference' Preferences
by jamie.baddeley＠vpc.co.nz 09 May '06

09 May '06

Hi, Snazzy subject line huh? ;-) Anyway, Was pondering the impact of path-stuffed networks being announced into the APE combined with operators not actually setting APE learnt routes with a higher local pref. In other words, how many operators out there are not preffing up APE learnt routes? Cheers jamie

5 5

APNIC 22 update #2
by Nurani Nimpuno 09 May '06

09 May '06

Hi NZNOG:ers, I'm forwarding on an update about the APNIC 22 meeting in September. If you have any questions about it, don't hesitate to shoot me a mail. Also, if you want an invitation letter (pdf, or printed and posted to you), contact me and I can arrange it. Cheers! Nurani ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Asia Pacific Network Information Centre Ph :+61-7-38583100 PO Box 2131 Milton, QLD 4064 Fax:+61-7-38583199 Australia http://www.apnic.net ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ [Apologies for duplicates] APNIC 22 update #2 Invitation to APNIC 22 ______________________________________ 22nd APNIC Open Policy Meeting 4-8 September, 2006, Kaohsiung, Taiwan ______________________________________ Dear APNIC members and friends, It is our pleasure to invite you to attend the 22nd APNIC Open Policy Meeting, being held in Kaohsiung, Taiwan. Hosted by TWNIC (Taiwan Network Information Center), APNIC 22 includes an innovative program that showcases presentations on operational Internet issues. Details of the program will be released closer to the meeting; however, a draft schedule is now available at: http://www.apnic.net/meetings/22/program Contents -------- 1. Meeting registraion is open 2. APNIC fellowships 3. Sponsorship opportunities 4. Visa information 1. Meeting registration ---------------------- Meeting registration site is now open. Please visit: http://www.apnic.net/cgi-bin/registration.pl?event_id=90 Early bird registration will end on 14 July, 2006. 2. APNIC fellowship ------------------- The APNIC fellowship program provides basic assistance to Internet professionals from developing economies around the region. If you are interested in applying for an APNIC 22 fellowship, please visit: http://www.apnic.net/meetings/22/fellows The deadline for applications is 26 May, 2006. 3. Sponsorship opportunities ---------------------------- Sponsoring an APNIC meeting will provide you with a range of opportunities to expose your organisation to the Asia Pacific Internet community. If your organisation is interested in sponsoring APNIC 22, please visit: http://www.apnic.net/meetings/22/sponsors 4. Visa information ------------------- Some meeting attendees may require a visa to visit Taiwan. Attendees who require a visa should apply promptly after completing the meeting registration to ensure that the visa is issued on time. All necessary information can be found at: http://www.apnic22.tw/apnic22_visas.htm Any questions? Please contact the APNIC Secretariat at <meetings(a)apnic.net>. We look forward to seeing you in Kaohsiung! Regards, ______________________________________________________________________ APNIC Secretariat secretariat(a)apnic.net Asia Pacific Network Information Centre (APNIC) Tel: +61-7-3858-3100 PO Box 2131 Milton, QLD 4064 Australia Fax: +61-7-3858-3199 ---------------------------------------------------------------------- See you at APNIC 22! Kaohsiung, 4-8 September, 2006 www.apnic.net/meetings ______________________________________________________________________

1 0

Notification of NZRR Database changes
by NZRR Database Notifications 09 May '06

09 May '06

Dear Colleague, This is to notify you that some object(s) in NZRR database which you either maintain or are listed as to-be-notified have been added, deleted or changed. These objects are used to configure the various NZIX route servers (http://nzix.net/) so you can expect the relevant servers to be reloaded in the near future. The reloading of the servers is staggered over a period of time so that if you are peering with both servers at an exchange, you can maintain at least one BGP session at all times and consequently a full set of routes. --- OBJECT BELOW CREATED: aut-num: AS9897 as-name: NZRR-AS9897 descr: jsr.com descr: APE peering at '192.203.154.102' descr: see Citylink RT job #5456 admin-c: RPA1-NZRR tech-c: RPA1-NZRR import: from AS9560 accept ANY AND NOT fltr-bogons export: to AS9560 announce AS9897 notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: jsr(a)jsr.com mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20060510 source: NZRR --- OBJECT BELOW CREATED: route-set: AS9560:RS-ROUTES:AS9897 descr: Route set advertised to AS9560 by jsr.com - AS9897 members: 202.49.89.0/24^24-29, 205.233.243.0/24^24-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: jsr(a)jsr.com mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20060510 source: NZRR

1 0

Notification of NZRR Database changes
by NZRR Database Notifications 09 May '06

09 May '06

Dear Colleague, This is to notify you that some object(s) in NZRR database which you either maintain or are listed as to-be-notified have been added, deleted or changed. These objects are used to configure the various NZIX route servers (http://nzix.net/) so you can expect the relevant servers to be reloaded in the near future. The reloading of the servers is staggered over a period of time so that if you are peering with both servers at an exchange, you can maintain at least one BGP session at all times and consequently a full set of routes. --- PREVIOUS OBJECT: route-set: AS9560:RS-ROUTES:AS9790 descr: advertised to AS9560 by Callplus Limited - AS9790 members: 202.180.64.0/18^18-29, 203.184.0.0/18^18-29, 203.100.208.0/20^20-29, 203.160.112.0/20^20-29, 203.215.142.0/23^23-29, 202.36.232.0/24^24-29, 202.37.22.0/24^24-29, 202.50.109.0/24^24-29, 203.97.152.0/24^24-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: ops(a)noc.tranzpeer.net mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20060509 source: NZRR REPLACED BY: route-set: AS9560:RS-ROUTES:AS9790 descr: advertised to AS9560 by Callplus Limited - AS9790 members: 124.197.0.0/18^18-29, 202.180.64.0/18^18-29, 203.184.0.0/18^18-29, 203.100.208.0/20^20-29, 203.160.112.0/20^20-29, 202.49.34.0/23^23-29, 203.215.142.0/23^23-29, 202.36.232.0/24^24-29, 202.37.22.0/24^24-29, 202.50.109.0/24^24-29, 203.97.152.0/24^24-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: ops(a)noc.tranzpeer.net mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20060510 source: NZRR --- PREVIOUS OBJECT: route-set: AS9439:RS-ROUTES:AS9790 descr: advertised to AS9439 by Callplus Limited - AS9790 members: 202.180.64.0/18^18-29, 203.184.0.0/18^18-29, 203.100.208.0/20^20-29, 203.160.112.0/20^20-29, 203.215.142.0/23^23-29, 202.36.232.0/24^24-29, 202.37.22.0/24^24-29, 202.50.109.0/24^24-29, 203.97.152.0/24^24-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: ops(a)noc.tranzpeer.net mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20060509 source: NZRR REPLACED BY: route-set: AS9439:RS-ROUTES:AS9790 descr: advertised to AS9439 by Callplus Limited - AS9790 members: 124.197.0.0/18^18-29, 202.180.64.0/18^18-29, 203.184.0.0/18^18-29, 203.100.208.0/20^20-29, 203.160.112.0/20^20-29, 202.49.34.0/23^23-29, 203.215.142.0/23^23-29, 202.36.232.0/24^24-29, 202.37.22.0/24^24-29, 202.50.109.0/24^24-29, 203.97.152.0/24^24-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: ops(a)noc.tranzpeer.net mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20060510 source: NZRR

1 0

New IP ranges for Xtra's email platform
by Ted Grenfell 08 May '06

08 May '06

Very shortly (later this week or early next week) we will be modifying DNS entries for Xtra's SMTP servers to point to a new email platform and we would like to draw your attention to the new network IP address ranges that will then be in use as per below: 210.54.141.0/24 210.55.11.0/24 If you've configured any of the existing Xtra mail server IP's in to any of your systems then it might be worthwhile adding the above ranges as well taking note not to delete any existing entries as that may impact normal delivery at this time. If you rely solely on DNS for selecting IP's to deliver email through to Xtra's SMTP servers then you do not need to make any changes. -- Kind Regards, Ted Grenfell ISP Performance Manager T +64 9 359 5854 (extn 93254) F +64 9 377 0781 M +64 27 443 5455 E ted.grenfell(a)telecom.co.nz <mailto:ted.grenfell(a)telecom.co.nz> W www.telecom.co.nz <http://www.telecom.co.nz> Level 11, Telecom House, 8 Hereford Street, Private Bag 92028, Auckland CBD, New Zealand ________________________________ "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. Please note that this communication does not designate an information system for the purposes of the Electronic Transactions Act 2002."

3 2

Notification of NZRR Database changes
by NZRR Database Notifications 08 May '06

08 May '06

Dear Colleague, This is to notify you that some object(s) in NZRR database which you either maintain or are listed as to-be-notified have been added, deleted or changed. These objects are used to configure the various NZIX route servers (http://nzix.net/) so you can expect the relevant servers to be reloaded in the near future. The reloading of the servers is staggered over a period of time so that if you are peering with both servers at an exchange, you can maintain at least one BGP session at all times and consequently a full set of routes. --- PREVIOUS OBJECT: route-set: AS9439:RS-ROUTES:AS9790 descr: advertised to AS9439 by CallPlus Limited - AS9790 members: 202.36.232.0/24^24-29, 202.37.22.0/24^24-29, 202.37.129.0/24^24-29, 202.49.34.0/23^23-29, 202.50.109.0/24^24-29, 202.180.64.0/18^18-29, 203.97.152.0/24^24-29, 203.100.208.0/20^20-29, 203.184.0.0/18^18-29, 203.215.142.0/23^23-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: noc(a)callplus.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050223 source: NZRR REPLACED BY: route-set: AS9439:RS-ROUTES:AS9790 descr: advertised to AS9439 by Callplus Limited - AS9790 members: 202.180.64.0/18^18-29, 203.184.0.0/18^18-29, 203.100.208.0/20^20-29, 203.160.112.0/20^20-29, 203.215.142.0/23^23-29, 202.36.232.0/24^24-29, 202.37.22.0/24^24-29, 202.50.109.0/24^24-29, 203.97.152.0/24^24-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: ops(a)noc.tranzpeer.net mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20060509 source: NZRR --- PREVIOUS OBJECT: route-set: AS9560:RS-ROUTES:AS9790 descr: advertised to AS9560 by CallPlus Limited - AS9790 members: 202.36.232.0/24^24-27, 202.37.22.0/24^24-27, 202.37.129.0/24^24-27, 202.49.34.0/23^23-27, 202.50.109.0/24^24-27, 202.180.64.0/18^18-27, 203.97.152.0/24^24-27, 203.100.208.0/20^20-27, 203.184.0.0/18^18-27, 203.215.142.0/23^23-27 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: noc(a)callplus.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050223 source: NZRR REPLACED BY: route-set: AS9560:RS-ROUTES:AS9790 descr: advertised to AS9560 by Callplus Limited - AS9790 members: 202.180.64.0/18^18-29, 203.184.0.0/18^18-29, 203.100.208.0/20^20-29, 203.160.112.0/20^20-29, 203.215.142.0/23^23-29, 202.36.232.0/24^24-29, 202.37.22.0/24^24-29, 202.50.109.0/24^24-29, 203.97.152.0/24^24-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: ops(a)noc.tranzpeer.net mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20060509 source: NZRR

1 0

FYI: Trademe phish ...
by Jamie Riden 08 May '06

08 May '06

Haven't seen a trademe phish before. The actual link goes to http://www.furutech.co.kr/bbs/data/trademe.php . You might want to warn and filter. cheers, Jamie Subject: TradeMe Account Security Measures Dear foo(a)example.co.nz , We recently noticed one or more attempts to log in to your TradeMe account from a different IP addresses. If you recently accessed your account while traveling, the unusual log in attempts may have been initiated by you. However, if you did not initiate the log ins, please visit TradeMe as soon as possible to check-up your account information: http://www.trademe.co.nz/members/login.aspx Thanks for your patience. Sincerely, TradeMe ---------------------------------------------------------------- Please do not reply to this e-mail. Mail sent to this address cannot be answered. Email ID 376223

1 0

[Fwd: Skybox Security Solutions announcement]
by Justin Cook 07 May '06

07 May '06

Some interesting spam I received. Reading through it I noticed they claim to test your security with a botnet. Are these guys serious? I'm guessing that the only definition of' 'botnet' out there these days is an armada of compromised PCs. -------- Original Message -------- Subject: Skybox Security Solutions announcement Date: Mon, 08 May 2006 10:00:21 +0800 From: <114_reunited(a)jaydees.net> Reply-To: <114_reunited(a)jaydees.net> Skybox Security Solutions *Simulated DDoS Network Attacks and Network Intrusions* *Customer Challenge: * Large corporations often hire consultants to conduct quarterly penetration (DDoS) testing on specific segments of their corporate network. This testing can cost over hundreds of thousands of dollars, and also exposes the network to many potential disruptions. These disruptions are the result of the intense DDoS attacks testers can impose on live networks in order to isolate vulnerabilities and weaknesses. Since the network is constantly changing, and DDoS attacks are rarely dispersed from a centralized location, the penetration test results often become nullified and end up being limited to a small portion of the total network. *The Skybox Solution: *Skybox Security performs accurate and non-intrusive DDoS attacks across a larger portion of the corporate network. The tests are modeled and analyzed through an automated process via our large botnet network rather than manually performed on a live network. As a result, the tests are repeated rigorously on a scheduled basis without any fear of network disruption. Through DDoS attack and access simulation, vulnerability exposures as well as security control weaknesses are revealed instantly. DDoS attack simulation discovers all possible attack scenarios and reveals the step by step process that an attacker or worm may follow. It illustrates specific vulnerabilities to be exploited and network access traversed for each exploitable path. Access simulation calculates network access privileges determined by firewall and routing configuration. Our botnet helps characterize the interconnectivity between any two given points, reporting not just whether access is possible, but also the detailed path to reach a final destination. Based on these combined results, security personnel are able to determine what additional DDoS attacks are necessary and where to deploy our organizations penetration testers. *Awards:* Info Security - Info Security Hot Companies 2006 The Wall Street Journal - One of the most innovative companies in 2005 Information Security Magazine - Product of the year Network Magazine - Most Visionary Security Product Network Magazine - Best of the Best in all categories Secure Enterprise Magazine - Editor's Choice Gartner - " Cool Vendor " in the security & privacy space SC Magazine Awards 2006 Winner - The Best Security Solution for Financial Services IM2005 Award finalist - Information Security and Product of the Year *Company Profile:* Eran Reshef Founder, Chairman & CEO of Blue Security ( www.bluesecurity.com <http://www.bluesecurity.com>) A serial entrepreneur, Eran is currently the founder, chairman & CEO of Blue Security, the do-not-disturb registry pioneer. Prior to Blue, Eran co-founded Skybox Security and served as its Chairman. Prior to Skybox Eran founded and managed Sanctum (acquired by WatchFire), the leader in web application security. Eran holds a variety of security- related patents that are based on his inventions. Rina Shainski General Partner at Carmel Ventures ( www.carmelventures.com <http://www.carmelventures.com>) Following a successful career leading business development and R&D operations in high-growth software companies, Rina has been investing in software companies ever since. Before joining Carmel she served as the VP Business Development at Clal Industries and Investments where she was responsible for software investments. From 1989 to 1996, Rina held several managerial positions in Tecnomatix including VP Business Development and R&D Director. Rina serves on the boards of Followap Communications, Skybox Security, mFormation and Silicon Design Systems. Rina holds a B.Sc. degree in Physics from Tel Aviv University and a Master of Science degree in Computer Science from Weizmann Institute. *Contact Information:* 2077 Gateway Place, Suite 550 San Jose, California 95110 USA Phone: 866-6SKYBOX Phone: 408 441 8060 Fax: 408 441 8068 Regional Offices (Israel) 60 Medinat Hayehudim St. P.O.Box 4109 Herzliya Pituach 46140 Israel Phone: +972-9-9545922 Fax: +972-9-9545933

5 4

new netblocks for Callplus/Slingshot
by Kevin Stewart 07 May '06

07 May '06

We are about to start advertising our new address blocks at the APE and WIX 124.197.0.0 /18 and 203.160.112.0/20 here is our current prefix list ASN 9790 ip prefix-list callplus-networks seq 5 permit 124.197.0.0/18 ip prefix-list callplus-networks seq 10 permit 202.36.232.0 ip prefix-list callplus-networks seq 15 permit 202.37.22.0 ip prefix-list callplus-networks seq 20 permit 202.49.34.0/23 le 24 ip prefix-list callplus-networks seq 25 permit 202.50.109.0 ip prefix-list callplus-networks seq 30 permit 202.180.64.0/18 ip prefix-list callplus-networks seq 35 permit 203.97.152.0 ip prefix-list callplus-networks seq 40 permit 203.100.208.0/20 ip prefix-list callplus-networks seq 45 permit 203.160.112.0/20 ip prefix-list callplus-networks seq 50 permit 203.184.0.0/18 ip prefix-list callplus-networks seq 55 permit 203.215.142.0 ip prefix-list callplus-networks seq 60 permit 203.215.143.0 -- Kevin Stewart Network Engineer DDI ++ 64 9 919 6120 Mobile ++ 64 21 885 505 Email kevins(a)callplus.co.nz ----------------------------------------------------------------------------------------------- This message and any attachments contain privileged and confidential information. If you are not the intended recipient of this message, you are hereby notified that any use, dissemination, distribution or reproduction of this message is prohibited. If you have received this message in error please notify the sender immediately via email and then destroy this message and any attachments.

2 1

Re: [nznog] Oh dear, no more room on the intarweb
by barry＠unix.co.nz 07 May '06

07 May '06

I'm sure majority of the devices would be added on an internal network such as telstra clears cable tv (digital) and cable modems (management), only 1 live ip is assigned for internet services. From memory a few mobile providers assign you a internal ip too and you're nat'ed out to the net. But yeah IPv6 is just around the corner. Thanks Barry > http://www.techweb.com/wire/networking/187200459 > > > -- > Juha Saarinen > www.geekzone.co.nz/juha > www.computerworld.co.nz > > _______________________________________________ > NZNOG mailing list > NZNOG(a)list.waikato.ac.nz > http://list.waikato.ac.nz/mailman/listinfo/nznog >

12 23

Re: [nznog] Oh dear, no more room on the intarweb
by Philip D'Ath 07 May '06

07 May '06

It allows each machine to have a globally unique IP address, without any form NAT. NAT breaks several protocols, and generally makes life more difficult. Also, if you want to use the same port for several machines (like 443) and you only have a single IP address then it makes life more difficult. For example, we have a single IPv4 address on a DSL tail. However, our entire network is IPv6 enabled using a 6to4 tunnel. We have several of our servers providing an https service. Thanks to IPv6 I can now easily browse to any of these servers from any of the remote locations that we have already IPv6 enabled. We are looking to actively start using IPv6 at many of our clients this year. We'll be using 6to4 tunnels again (because no one sells IPv6 transit ...). This means we can load a management agent on their machines, and have our server talk to those agents over a VPN. Normally we would have the grief of ensuring their private IP address range is different from all of our other client addresses ranges. With every machine having a globally unqiue IPv6 address this is no longer an issue. Of course, there is always an IPv4 RFC1918 clash, and we end up with the option of limited management, or a renumbering exercise. The sooner everyone adopts IPv6, and we can easily get native IPv6 transit the better. -----Original Message----- Still, I'm a little puzzled why a single IPv4 address (with lots of NAT behind it) is really any different from a single IPv6 prefix with lots of bits on the right hand side.

1 0

Re: [nznog] Oh dear, no more room on the intarweb
by Andy Linton 07 May '06

07 May '06

Joe complained that the Dancing Turtle wasn't enough justification to go to IPv6 but clearly the risk of eternal damnation should be a good reason. Devout Catholics will soon be issued with an IPv6 address at Mass on Sundays and those who don't have one that's regularly used.... -------- Original Message -------- Subject: [ipv6-wg] The Pope gets IPv6 PA space (not PI :) Date: Wed, 19 Apr 2006 09:28:30 +0200 From: Jeroen Massar <jeroen(a)unfix.org> Reply-To: jeroen(a)unfix.org Organization: Unfix To: v6ops(a)ops.ietf.org <v6ops(a)ops.ietf.org>, nanog(a)merit.edu <nanog(a)merit.edu> CC: ARIN PPML <ppml(a)arin.net>, ipv6-wg(a)ripe.net inet6num: 2a01:b8::/32 netname: VA-VATICAN-20060418 descr: Holy See - Vatican City State country: VA So now that IPv6 is officially blessed go deploy it :) Greets, Jeroen

1 0

search engine that shows illegal downloads
by Antonio Broughton 07 May '06

07 May '06

Hi, just found this news article.. http://tvnz.co.nz/view/page/411365/711264 what interested me most, was this "search engine" that allows the federation to see "any illegal downloading in New Zealand" 1) Is this something Telecom has come up with :) (couldn't resist it) 2) How do they determine if its illegal, or not just someones home made video of Debbie does Auckland etc 3) How would this be possible? The third question is the most serious one, just wondering how there could be a search engine that showed this information? This would have to be implemented at the backbone level? -- Antonio Broughton

5 4

Re: [nznog] Oh dear, no more room on the intarweb
by Philip D'Ath 06 May '06

06 May '06

I've tried to buy commercial IPv6 connectivity in NZ. I can't buy it, full stop. -----Original Message----- ... IPv6 has been well-and-truly implemented. It's the deployment that's missing. To replay a conversation that we had in Wellington earlier in the year: Deployment costs money; money requires budget; budget requires either revenue or cost reduction (or both). Who is willing to pay more for IPv6, given that pretty much the only extra content available for your money will be a lonely, somewhat poorly-animated Japanese turtle? (Don't all shout at once.)

2 1

Re: [nznog] Oh dear, no more room on the intarweb
by Philip D'Ath 06 May '06

06 May '06

How about every ISP in NZ. -----Original Message----- From: Lindsay Druett [mailto:lindsay(a)wired.net.nz] Sent: Sunday, 7 May 2006 8:09 p.m. To: nznog(a)list.waikato.ac.nz Subject: Re: [nznog] Oh dear, no more room on the intarweb ... Anyway, what doesn't support IPv6 now ? I'm picking that what doesn't support IPv6 now is more than likely to be either upgraded or in the bin by 2008.

1 0

Oh dear, no more room on the intarweb
by Juha Saarinen 06 May '06

06 May '06

http://www.techweb.com/wire/networking/187200459 -- Juha Saarinen www.geekzone.co.nz/juha www.computerworld.co.nz

1 0

Notification of NZRR Database changes
by NZRR Database Notifications 04 May '06

04 May '06

Dear Colleague, This is to notify you that some object(s) in NZRR database which you either maintain or are listed as to-be-notified have been added, deleted or changed. These objects are used to configure the various NZIX route servers (http://nzix.net/) so you can expect the relevant servers to be reloaded in the near future. The reloading of the servers is staggered over a period of time so that if you are peering with both servers at an exchange, you can maintain at least one BGP session at all times and consequently a full set of routes. --- PREVIOUS OBJECT: route-set: AS9560:RS-ROUTES:AS9503 descr: advertised to AS9560 by FX Networks - AS9503 members: 131.203.0.0/16^16-29, 161.29.0.0/16^16-29, 161.65.0.0/16^16-29, 202.50.208.0/20^20-29, 202.53.176.0/20^20-29, 202.174.160.0/20^20-29, 202.191.32.0/20^20-29, 202.50.200.0/21^21-29, 202.50.52.0/22^22-29, 202.50.196.0/22^22-29, 202.59.4.0/22^22-29, 202.37.86.0/23^23-29, 202.49.80.0/23^23-29, 202.124.106.0/23^23-29, 192.88.85.0/24^24-29, 192.133.31.0/24^24-29, 202.20.97.0/24^24-29, 202.27.208.0/24^24-29, 202.36.183.0/24^24-29, 202.36.226.0/24^24-29, 202.50.247.0/24^24-29, 203.97.5.0/24^24-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: noc-minor(a)fx.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20060209 source: NZRR REPLACED BY: route-set: AS9560:RS-ROUTES:AS9503 descr: advertised to AS9560 by FX Networks - AS9503 members: 131.203.0.0/16^16-29, 161.29.0.0/16^16-29, 161.65.0.0/16^16-29, 202.50.208.0/20^20-29, 202.53.176.0/20^20-29, 202.174.160.0/20^20-29, 202.191.32.0/20^20-29, 202.50.200.0/21^21-29, 202.78.240.0/21^21-29, 202.50.52.0/22^22-29, 202.50.196.0/22^22-29, 202.59.4.0/22^22-29, 202.37.86.0/23^23-29, 202.49.80.0/23^23-29, 202.124.106.0/23^23-29, 192.88.85.0/24^24-29, 192.133.31.0/24^24-29, 202.20.97.0/24^24-29, 202.27.208.0/24^24-29, 202.36.119.0/24^24-29, 202.36.183.0/24^24-29, 202.36.226.0/24^24-29, 202.46.190.0/24^24-29, 202.50.247.0/24^24-29, 203.97.5.0/24^24-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: noc-minor(a)fx.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20060505 source: NZRR --- PREVIOUS OBJECT: route-set: AS9439:RS-ROUTES:AS9503 descr: advertised to AS9439 by FX Networks - AS9503 members: 131.203.0.0/16^16-29, 161.29.0.0/16^16-29, 161.65.0.0/16^16-29, 202.50.208.0/20^20-29, 202.53.176.0/20^20-29, 202.174.160.0/20^20-29, 202.191.32.0/20^20-29, 202.50.200.0/21^21-29, 202.50.52.0/22^22-29, 202.50.196.0/22^22-29, 202.59.4.0/22^22-29, 202.37.86.0/23^23-29, 202.49.80.0/23^23-29, 202.124.106.0/23^23-29, 192.88.85.0/24^24-29, 192.133.31.0/24^24-29, 202.20.97.0/24^24-29, 202.27.208.0/24^24-29, 202.36.183.0/24^24-29, 202.36.226.0/24^24-29, 202.50.247.0/24^24-29, 203.97.5.0/24^24-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: noc-minor(a)fx.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20060209 source: NZRR REPLACED BY: route-set: AS9439:RS-ROUTES:AS9503 descr: advertised to AS9439 by FX Networks - AS9503 members: 131.203.0.0/16^16-29, 161.29.0.0/16^16-29, 161.65.0.0/16^16-29, 202.50.208.0/20^20-29, 202.53.176.0/20^20-29, 202.174.160.0/20^20-29, 202.191.32.0/20^20-29, 202.50.200.0/21^21-29, 202.78.240.0/21^21-29, 202.50.52.0/22^22-29, 202.50.196.0/22^22-29, 202.59.4.0/22^22-29, 202.37.86.0/23^23-29, 202.49.80.0/23^23-29, 202.124.106.0/23^23-29, 192.88.85.0/24^24-29, 192.133.31.0/24^24-29, 202.20.97.0/24^24-29, 202.27.208.0/24^24-29, 202.36.119.0/24^24-29, 202.36.183.0/24^24-29, 202.36.226.0/24^24-29, 202.46.190.0/24^24-29, 202.50.247.0/24^24-29, 203.97.5.0/24^24-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: noc-minor(a)fx.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20060505 source: NZRR

1 0

Re Xtra's Usenet Cancellations...
by Mark Foster 03 May '06

03 May '06

My little impromptu polls raised ~70 responses, results as follows: http://www.blakjak.net/node/495/results What are your thoughts on Xtra's decision to cancel its Usenet service? A smart move, handled appropriately. 3% (2 votes) A smart move, but badly implemented. 4% (3 votes) An understandable move, handled appropriately. 6% (4 votes) An understandable move, badly implemented. 40% (27 votes) A bad move, but the implementation was acceptable. 1% (1 vote) A bad move, and badly implemented. 45% (30 votes) Total votes: 67 http://www.blakjak.net/node/496/results Usenet: Usage Query. I use Usenet every day. 25% (18 votes) I use Usenet every few days. 13% (9 votes) I use Usenet once a week. 6% (4 votes) I use Usenet occaisionally. 11% (8 votes) I used to use it regularly, I don't anymore. 32% (23 votes) I'm aware of what Usenet is, but have never used it. 10% (7 votes) I've never heard of Usenet. 3% (2 votes) Total votes: 71 It seems that whilst opinion is divided as to whether cancelling their usenet service was a bad move or not, there is general agreement that the way in which this was actioned was 'bad' (tm). In fact it seems that only 7 votes from 67 - or a fraction over 10% - think that it was done well. Speaks for itself, doesn't it? Also interesting to see that certainly from the NZNOG community - and a few other smallish communites I circulated the poll to - Usenet still has some use. Just under half (~45%) of respondents could say they 'don't' use Usenet, with another ~39% of respondents saying they use it at least once a week. Fairly even spread. I'm not convinced that running the same survey in a forum accessed by non-network geeks would reveal the same results, though. Regards Mark.

1 0

Govt announcements
by David Farrar 03 May '06

03 May '06

I think the operational significance of the Govt's announcements today make it on-topic. Surprise announcement a few minutes ago: http://www.beehive.govt.nz/ViewDocument.aspx?DocumentID=25636 Government moves fast to improve Broadband New Zealanders can look forward to faster, better broadband Internet services thanks to the comprehensive telecommunications package announced today. Communications Minister David Cunliffe says the package is a vital part of the Government's drive to transform the economy and push New Zealand's broadband performance into the top quarter of the OECD. "Access to fast, competitively priced broadband Internet is vital for New Zealand to take full advantage of new technologies," Mr Cunliffe said. "This package will help ensure we catch up and keep up with other developed countries." Today's package includes: * Requiring the unbundling of the local loop and sub-loop copper-wire lines between telephone exchanges and homes and businesses, allowing other Internet Service Providers to compete fully with Telecom to provide faster, cheaper broadband. * Regulatory action such as information disclosure, accounting separation of Telecom's business operations and an enhanced Commerce Commission monitoring role in order to ensure improved competition. * Removing constraints on the existing regulated Unbundled Bitstream Service to ensure ISPs can offer better and cheaper broadband at upload speeds faster than 128kps. * Encouraging investment in alternative infrastructure such as fibre, wireless and satellite networks by measures including a review of public sector investment in telecommunications infrastructure to encourage a whole-of-government approach; reviewing whether Telecom's ability to reduce local prices solely in response to new competing infrastructure investment should be constrained; developing a rural package and expansion of the Digital Strategy Broadband Challenge fund. "We are continuing to look at whether additional measures are warranted, such as the structural separation of Telecom's retail and lines operations," Mr Cunliffe said. -- David Farrar e-mail: david(a)farrar.com mob: 027 447 0216, ph: 04 471 0956, fax: 04 471 0946 blog: http://www.kiwiblog.co.nz msn: dpf666(a)hotmail.com, icq: 29964527, skype: dpfdpf Director, Curia Market Research http://www.curia.co.nz Vice-President, InternetNZ http://www.internetnz.net.nz Director, .nz Registry Services, http://www.nzrs.net.nz

11 11

Xtra and usenet
by Matthew Poole 02 May '06

02 May '06

I notice that there's been a dearth of comment in here about this. Does the NZNOG community not especially care, or has this just flown below the radar? -- Matthew Poole "Don't use force. Get a bigger hammer."

8 8

Re: [nznog] Xtra and usenet
by Blair Harrison 02 May '06

02 May '06

Mark Foster wrote: > > I am interested to see whether there is an opinion that regardless of the > 'how' this was done by Xtra, that this may infact have been a 'smart' idea > (from a business POV). One assumes you take into account the business > overheads of running a usenet server in the first place, and that there is > a noticable benefit to the company by cancelling the service... I'm interested to know which ISPs actually still run a Usenet server - and if so, how much bandwidth does it use and how many users does it have? Both raw numbers and as a percentage of the userbase... I'm guessing not very many.. Given the availability of services like GigaNews, Google Groups and the large bandwidth and support demands of running a Usenet server down under, is an ISP provided Usenet Server really something that needs to exist these days? And on another topic, Bonzi Buddy seems to think it's time for a beer. http://202.174.163.104/~blair/bonzibeer.jpg -Blair

3 2

Any Telecom mail admins here?
by Juha Saarinen 01 May '06

01 May '06

Getting SORBS-induced message bounces from Telecom's mail servers due to that erroneous dial-up listing. I'm probably not the only one. -- Juha Saarinen www.geekzone.co.nz/juha www.computerworld.co.nz

3 4

Re: [nznog] Sorbs blocking addresses
by Matthew Sullivan 01 May '06

01 May '06

Craig Humphrey wrote: >Thanks Matthew. > > As an update because of the problems I have just caused new zonefiles for the DUHL zone to be created with only the test entry until the update is complete. (Why I didn't think of that before I'll never know). Regards, Mat

1 0

Re: [nznog] Sorbs blocking addresses
by Craig Box 01 May '06

01 May '06

> I'm assuming this means that all customers sending their own mail will > now have to use the xtra smtp servers? On that subject, I notice that etrn.iconz.co.nz has (probably recently) started using SORBS's dynamic DNS blacklist, and I've had reported e-mail complaints from Xtra and TelstraClear DSL customers today. Generally, when we find this happening, we contact the sysadmin on the remote end and advise them that they are likely blocking a whole set of e-mail they want to receive - harder when it's an ISP. With Xtra's Port 25 push, it could be that ICONZ have decided to have a flag day, forcing everyone wishing to communicate with them, running a (small business) mail server on a DSL connection, to now use their upstream ISP's mail server - losing the ability to diagnose mail routing after it disappears "into the black box". Is this the future? Craig

4 3

Sorbs blocking addresses
by Kerry 01 May '06

01 May '06

Hello, would seem that there is an issue here... We are now getting Xtra based customers with perminant mail delivery failures. Netblock: 210.55.172.0/23 (210.55.172.0-210.55.173.255) Record Created: Mon May 1 13:22:39 2006 GMT Record Updated: Mon May 1 13:22:39 2006 GMT Netblock: 210.55.170.0/23 (210.55.170.0-210.55.171.255) Record Created: Mon May 1 13:22:39 2006 GMT Record Updated: Mon May 1 13:22:39 2006 GMT Netblock: 210.55.174.0/24 (210.55.174.0-210.55.174.255) Record Created: Mon May 1 13:22:40 2006 GMT Record Updated: Mon May 1 13:22:40 2006 GMT $ nslookup 210.55.174.1 Server: . Address: 172.20.0.2 Name: 210-55-174-1.ipnets.xtra.co.nz Address: 210.55.174.1 I'm assuming this means that all customers sending their own mail will now have to use the xtra smtp servers? Cheers, kerry

1 0

Notification of NZRR Database changes
by NZRR Database Notifications 01 May '06

01 May '06

Dear Colleague, This is to notify you that some object(s) in NZRR database which you either maintain or are listed as to-be-notified have been added, deleted or changed. These objects are used to configure the various NZIX route servers (http://nzix.net/) so you can expect the relevant servers to be reloaded in the near future. The reloading of the servers is staggered over a period of time so that if you are peering with both servers at an exchange, you can maintain at least one BGP session at all times and consequently a full set of routes. --- OBJECT BELOW CREATED: aut-num: AS37999 as-name: NZRR-AS37999 descr: TVNZ descr: APE peering at '192.203.154.22' descr: see Citylink RT job #5301 admin-c: RPA1-NZRR tech-c: RPA1-NZRR import: from AS9560 accept ANY AND NOT fltr-bogons export: to AS9560 announce AS37999 notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: noc(a)tvnz.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20060502 source: NZRR --- OBJECT BELOW CREATED: route-set: AS9560:RS-ROUTES:AS37999 descr: Route set advertised to AS9560 by TVNZ - AS37999 members: 202.89.4.0/22^22-29, 202.36.33.0/24^24-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: noc(a)tvnz.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20060502 source: NZRR

1 0

The New Zealand Network Operators' Group
by Donald Neal 01 May '06

01 May '06

The New Zealand Network Operators' Group The New Zealand Network Operators' Group (NZNOG) has no king, president or formal membership. It consists of the subscribers to this mailing list, which anyone is free to join. The group is intended to facilitate discussion among operators of networks in New Zealand, as described in the list's Acceptable Use Policy, which appears later in this posting. Conference Work is just beginning towards our annual conference for 2007. Other Meetings See http://auckland.thursdaynightcurry.com/ or http://wellington.thursdaynightcurry.com/ if you live in or near Auckland or Wellington. 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, not by most customers. Internet Exchanges See http://www.nzix.net/ for details of exchanges in operation, and some information on others under construction. About This Mailing List This list has around 900 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. You may choose to receive postings as they come in, or just to receive daily "digests". See the bottom of the page http://list.waikato.ac.nz/mailman/listinfo/nznog/ to change the form in which you receive postings. The NZNOG mailing list is provided through a server at The University of Waikato, and is administered by employees of Alcatel NZ Ltd, Citylink and Telecom. None of these organisations, nor any 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/pipermail/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 administrators remain happy to assist the Office of the Privacy Commissioner should any complaint be laid with that office. One way to search the archive is to use google and prefix your search With site:list.waikato.ac.nz . 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. Please note that this communication does not designate an information system for the purposes of the Electronic Transactions Act 2002.

1 0

Steaming Event
by Webmaster 30 Apr '06

30 Apr '06

Operators may be interested to know that Radio NZ is running a large streaming event this Saturday 6 May. Music 101 (www.radionz.co.nz/music101) will be broadcast live from Bar Bodega in Wellington, and we'll be providing enhanced audio and video for the event as it also includes live music performances. We'll be offering the following Video: 56 K, 128K, 384K, 768K at all our servers (US and local) 2M will only be offered locally (customers whose ISPs do not peer will not havce access to this). And for Audio: 256K stereo (this is not a typo). This is addition to our usual 48 K stream. As is usual for these events the best performance for your customers can be obtained by peering with the servers located at the NZ exchanges. Limited NZ bound capacity will be available from the US server. Radio NZ will peer with anyone who has connectivity where we do - at APE, PNIX or WIX. We do not charge peers for access to our content. regards, Richard Hulse

2 1

Re: [nznog] QSI / "industry" DSL problems caused by3.5mbit upgrades?
by Simon Allard 27 Apr '06

27 Apr '06

> With this service limitation I can easily see how Quicksilver could > potentially be affected more than Ihug, Iconz, Xtra and Orcon. I would > guess that the average user profile on Quicksilver would tend towards > higher bandwidth usage whereas the typical Xtra (etc) user would > probably use less bandwidth. > > Unfortunately if this view I have is correct then I don't see an end to > problems unless either the average Quicksilver user profile changes -or- > Telecom changes the PVC limitation. I am curious to know what effect offering free national traffic has on the QSI DSL Network. In my experience offering free anything in this environment Telecom has created causes nothing by problems.

5 6

Re: [nznog] QSI / "industry" DSL problems caused by 3.5mbit upgrades?
by Regan Murphy 26 Apr '06

26 Apr '06

>>Just curious if any other ISPs are suffering from supposed "industry wide" >>throughput issues on the Telecom DSL network caused by telecom "upgrading too >>many customers to 3.5mbit without upgrading their network"? Well for me the problem started before any customers were upgraded and the problem has continued well through the upgrade - I now have an automatically upgraded 3.5Mbps connection and speeds are no better/worse. I have been suffering poor performance on QSI for quite some time now. My initial post to the helpdesk via their webpage was submitted on March 14 - I had been having problems for weeks before that though. This is the response I received: "I have spoken to the network staff and they let me know that a 2Mb connection can drop as low as 24Kbps especially at peak times as this is the nature of the UBS service that telecom offers." I was, at that time, on the 2Mbps service and I was having problems even running terminal sessions to my office (which is five hops away on a 10 Mbps connection via APE). Attempting a download resulted in speeds between 7KB/sec and 30KB/sec typically. This was only noticed during peak times - 6pm to 11pm. I tried a download at 5am one morning and it ran almost at full speed. A friend of mine recently changed from Orcon to QSI. He is on an exchange on the other side of AKL from me. On the Thursday (with Orcon) he was sustaining a 220KB/sec download from the linux mirror at citylink. On the Friday when he was changed over to QSI he couldn't get better than 80KB/sec from the same source and he has had speed problems since. He changed about 2-3 weeks ago. I initially assumed that the problems were due to oversubscription cause by the Telecom changes to the DSL (I figured they bought the changes in early) and this is the line I have been given talking to the QSI helpdesk. As changing providers is a painful (and expensive) process I've been reluctant to switch without knowing for sure where the problem lay. -- Regan

8 8

Re: [nznog] QSI / "industry" DSL problems caused by3.5mbit upgrades?
by Regan Murphy 26 Apr '06

26 Apr '06

Yes, thanks to Mark for replying. This additional information makes me less likely to attribute the blame to Quicksilver for these problems. > 1) We currently have a project underway to increase our Private > Virtual Circuit (PVC) size from Telecom to manage future forecasted growth. > Telecom > controls the dimension of this PVC and constrains its size to 24kbit/s > per customer. >>Yet at the same time, customers of Ihug, Iconz, Orcon and Xtra are all able to get much higher rates... With this service limitation I can easily see how Quicksilver could potentially be affected more than Ihug, Iconz, Xtra and Orcon. I would guess that the average user profile on Quicksilver would tend towards higher bandwidth usage whereas the typical Xtra (etc) user would probably use less bandwidth. Unfortunately if this view I have is correct then I don't see an end to problems unless either the average Quicksilver user profile changes -or- Telecom changes the PVC limitation. -- Regan

1 0

QSI / "industry" DSL problems caused by 3.5mbit upgrades?
by Matt Camp 26 Apr '06

26 Apr '06

Hi all, Just curious if any other ISPs are suffering from supposed "industry wide" throughput issues on the Telecom DSL network caused by telecom "upgrading too many customers to 3.5mbit without upgrading their network"? Those are direct quotes from the Quicksilver Internet helpdesk person I just spoke to. This puzzles me, because in todays age of UBS, etc, I wasn't aware that such congestion could occur and affect everyone. I am especially surprised since I have had some people on ihug and xtra dsl (in one case not far from here, probably on the same exchange) run some tests, and they get 220kB/s, whereas I am currently getting... 7.5kB/s, and it's been that way for 3 days. It also puzzles me since a friend in Wellington on Quicksilver is getting almost exactly the same crappy performance as I'm getting in Auckland... pretty big coincidence that two exchanges so far apart are giving exactly the same performance issues at the same time? It's been a while since I actually dealt with the internals of DSL from the ISP end, especially in the UBS-era, so I'm posting here to see if anyone has any info one way or the other. FYI, Quicksilver have recommended that I contact Telecom to complain, or maybe write them a letter. They also refuse to update their network status page (despite admitting that virtually all their dsl users are affected, and many are complaining) because it would "be detrimental, as it's not Quicksilvers problem". Does this actually sound real, or am I being just fobbed off by the helpdesker? Are any of you other ISPs having similar issues, and can anyone point me at any info direct from Telecom about the issue? - Matt Camp

9 10

Re: [nznog] QSI / "industry" DSL problems caused by 3.5mbitupgrades?
by Matt Camp 26 Apr '06

26 Apr '06

Indeed, I've now heard from around 8 or 9 Quicksilver users from all over the country, all of whom are getting SERIOUSLY bad speeds anywhere near peak times. I'm talking getting down around 200-300kbit on average, sometimes down as low as 60kbit. But it's not just the throughput... latency is floating from 70ms up to around 4400ms... floating WILDLY... enough that it makes SSHing over the dsl connection very difficult. But mainly my point was that Quicksilver are trying to tell their users that it's and industry-wide problem affecting all ISPs, and there is nothing that Quicksilver can do to fix it (apart from sending endless screenshots of their bandwidth tester, which they are apparently forwarding to telecom). The fact that people can get good speeds using an xtra username, and crap using a qsi one on the same line indicates that this is NOT the per-exchange congestion problem seen in some areas (Mt Eden, for example) At this point in time I'd just like someone to admit that perhaps they don't have enough bandwidth, and just give us a realistic eta on when that can be resolved. Trying to pass the blame just pisses more people off. > > >> Remember.. your speed is NOT guaranteed, but if you are buying a 3.5M >> connection >> >> and can NEVER get 3.5M.... > > I think you guys are missing the point in his email. > > [snip] > whereas I am currently getting...7.5kB/s, and it's been that way for 3 > days. > [/snip] > > That sounds like a serious problem rather than a "I never get 3.5M" > problem. > > > > _______________________________________________ > NZNOG mailing list > NZNOG(a)list.waikato.ac.nz > http://list.waikato.ac.nz/mailman/listinfo/nznog >

1 0

Re: [nznog] QSI / "industry" DSL problems caused by 3.5mbitupgrades?
by Simon Allard 26 Apr '06

26 Apr '06

> Remember.. your speed is NOT guaranteed, but if you are buying a 3.5M > connection > > and can NEVER get 3.5M.... I think you guys are missing the point in his email. [snip] whereas I am currently getting...7.5kB/s, and it's been that way for 3 days. [/snip] That sounds like a serious problem rather than a "I never get 3.5M" problem.

2 1

Re: [nznog] QSI / "industry" DSL problems caused by 3.5mbit upgrades?
by Scott Weeks 26 Apr '06

26 Apr '06

----- Original Message Follows ----- From: "Craig Whitmore" <lennon(a)orcon.net.nz> > http://www.nzdsl.co.nz/graphs/) This is about 50000 > recorded tests from Could you let me know what program you used to graph this and how you collected the data? Thanks, scott

1 0

Someone from CallPlus
by Shane Hobson 25 Apr '06

25 Apr '06

Please, would someone from CallPlus be able to contact me off list regarding Hamilton City Council ? Regards Shane Hobson 07 838 6725 021 742 634

1 0

ANZ problems? Phishing redirect attack?
by Paul Adshead 23 Apr '06

23 Apr '06

Is anyone else having issues getting to http://www.anz.co.nz or http://www.anz.com (- see attached for what is served up here)? Especially Telecom-fibre-connected parties? Funnily enough there's no problem when connecting from an Xtra dial-up - work that out... There are no known phishing-redirect attempts or similar in progress for ANZ are there? Cheers, Paul.

3 2

Re: [nznog] Port 25
by Mark GOLDFINCH 23 Apr '06

23 Apr '06

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi Steve, The reason why paradise.net said it was not possible at the time was because for two reasons: 1) Our MTA at the time did not support OMDR or any similar features to achieve delivery of mail using OMDR or other features to acheive the same means. 2) Later we developed our own Dynamic SMTP MTA which delivers mail to customer's dynamically assigned IP address after verifying that we indeed have the correct customer on the expected RAS port. OMDR requires quite a bit of compliance from the customer point of view. Our own Dialup SMTP solution required very little support from the customer's point of view other than having an SMTP server listening on their dialup connection. I'm thinking that this day in age with DDNS and broadband connections becoming far more relevant that SMTP delivery to dynamic IP addresses is becoming less of an issue. But then perhaps I'm mistaken. - -- Mark Goldfinch Senior Systems Administrator IS: Unix Systems TelstraClear Ltd > -----Original Message----- > From: Steve Lang [mailto:steve(a)spl.co.nz] > Sent: Wednesday, 19 April 2006 20:59 > To: Simon > Cc: nznog(a)list.waikato.ac.nz > Subject: Re: [nznog] Port 25 > > > Dare I suggest something worth talking about amongst the recent > flaming.... but.... > > Some time ago, I was asking about ISP's that provided ODMR > services. RFC > 2645 (http://www.rfc-archive.org/getrfc.php?rfc=2645) Can't recall > where that thread went - someone from paradise saying something about > them not wanting to do it 'cause it would make them insecure or > something... Didn't make sense at the time. > > In any case, this would appear to be to be a good solution. > The RFC has > been around for a long time (1999), and it appears that there may be > more than just a couple of clients/servers. > > But, I still can't find anyone that supports it. Any clues who might? > Anyone from ISP land that want's to create an ODMR service? > Don't need a > static IP, should work with everyone etc. etc. > > Cheers - > > Simon wrote: > > Just a quick email to the list to find out what other service > > providers are doing regarding XTRA blocking port 25 when > your company > > does not provide internet connections, so many of your customers are > > using xtra as a service provider but not for other services wuch as > > mail. > > > > Many of my customers are XTRA customers, but are also vodafone etc > > etc, so an external autheticated mail server is a huge > bonus for them. > > Use secure port? > > > > 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 > -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.0.5 (Build 5050) iQEVAwUBREwdjFJxzSk14MzBAQi77wf7BTyKlx1UQra8IlLVzx38PIZtdaEkPWIb ZKfXGNQRsEhoUkTfAm3oZE0gkdmAoa3uBHzWl9ITFBiiS8OAqSmBokNack2lpN1z ZIVFuSHvFDR+S8OGMp9C27QSLz0QFb0972ikIzvVUGPXttkLe9ywlUpqJHIjQbTh RfW1DzpYbC6olVb7wizksT9ZIravDzgDOUmKXXUMfTcKPNXiQvrhT3uXhJX+XIJk l1da+ttyh6JYRTDJTvwAq4rx4ICr1F8RbdcTpnkoSnXC9zlqXxp+ZLhIek8NJVga tFvamDlSG6BD2DJXJ0w1V7FUhPSI5eKc9U4YCcX8CjZDes4Lnz0U4Q== =XQZ1 -----END PGP SIGNATURE-----

2 1

Re: [nznog] SCC cable cut in the US
by Ewen McNeill 22 Apr '06

22 Apr '06

In message <444AD782.3090505(a)saarinen.org>, Juha Saarinen writes: >http://cgi.internode.on.net/advisories/item.html?id=3679 >Is this affecting NZ at all? Ihug customers? You realise that event was Friday? Internode is Australian based, in Adelaide IIRC, and their times are about 2.5 hours behind ours. And yes, some transit out of New Zealand was also affected on Friday afternoon, showing unusually high latency to the US. It was resolved by Saturday morning. Ewen

2 1

SCC cable cut in the US
by Juha Saarinen 22 Apr '06

22 Apr '06

http://cgi.internode.on.net/advisories/item.html?id=3679 Is this affecting NZ at all? Ihug customers? -- Juha Saarinen www.geekzone.co.nz/juha www.computerworld.co.nz

1 0

Port 25 blocking and a request for advice, on behalf of NZNOG.
by James Clark 21 Apr '06

21 Apr '06

Kia ora Wietse, [NZNOGgers - Please read this email and the next before you flame me. I won't see the flames until very late tomorrow :) I hope to not be flamed over this. Yes I deserved it earlier, I'll let you have that one.] You're about to be Cc-ed on a tale from me to the NZNOG mailing list. It involves the word Postfix a fair bit, Postfix rocks. Thank's for all the hard work you've put in to your MTA, it's a gem. I won't build an MTA with anything else, it suits me. So, yeah. Thanks. I hope you enjoy the soon to follow tale. Heck, maybe you won't, it doesn't matter in the grand scheme of things ;) Xtra is planning to block port outbound 25 outbound, no doubt a few other xSPs will follow suite at around the same time. Big business is what it is. The people that work at are good people. I personally like to support the underdog and I get on my soapbox occasionally. Xtra is New Zealand's largest ISP, a monolithic monopoly that's in bed with Microsoft ( www.xtramsn.co.nz ) and it's got it's hand playing very heavily in Parliment. What Xtra does impacts New Zealands Internet very heavily. This email is a request for your advice, for me personally and I suppose (as is in the subject heading) a request on behalf of NZNOG. I hope it is well recieved. I was wondering if you might perhaps take the time to chime in and let the NZNOG community know that blocking port 25 isn't a _solution_. One of the root motivators for implementing the block is the sheer number of their customers that have computers which run "rooted" Microsoft OSes. My angle is that blocking port 25 will not _solve_ the root cause of the problem. I believe that Xtra are in a good position to put some pressure on Microsoft with regards to rolling out a much better _solution_ , for example: Transparently scanning customer email for virus / blatant-spam related content. Then identifying and contacting those customers, to sort out their issues. Something that could be fairly easily implemented - it would just cost money, probably lots of it. Xtra and Microsoft are in a good position with regards to finance, as we all know. And this could be opted out of (easily), so the clueful can carry on living under the radar (the pleasant side of the radar). The devil is in the detail... I can imagine it'd be a logistical nightmare. However, I know the above is possible, I scripted something in Perl to do just this, when I worked for Wave Internet (a local ISP). The script did the above (example) automatically minus the automated contacting of customers, that was done manually but the script notified the support team of who was an offender. It also just scanned the Postfix's logs, not port 25 outbound for the entire op etc. I wasn't that savvy at the time. It would not just help the problem it would also curb the expense that is passed on to the customer. I've talked to a handful of customers while at Wave on the helpdesk that had footed thousands of dollars in bills due to trojans etc (Porn dialers, mass mailers etc). Those poor souls didn't get much sympathy from any party, just our condolences, it was the Telco that won in the end. I'm sure everyone on the NZNOG list would value your input on this issue, some may disagree with you. I know some have disagreed with me :) Heck, you may even support the blocking of port 25, though I suspect not[1]. Perhaps you won't, it doesn't matter. There's no harm in asking for the advice of someone that's well respected in the MTA building business. I've done a list subscribe request, on your behalf, to make it easier for you if you'd like to make a difference - either for or against my opinion which is: "Blocking port 25 is bad for the Internet (as a whole).". I know my initial post (to NZNOG) wasn't recieved too well. The thread started here: http://list.waikato.ac.nz/pipermail/nznog/2006-April/011325.html My rant here: http://list.waikato.ac.nz/pipermail/nznog/2006-April/011325.html I broke a few of the NZNOG rules and ruffled some feathers. Oh well, them's the breaks when the soapbox comes out :) A reminder. NZNOGgers - Please read the next email before you flame me. I won't see the flames until very late tomorrow :) Wietse, the next email from me will provide even more background. I can imagine that we'd all look forward to hearing your opinion on the matter. Thanks for your time so far. Perhaps we'll hear from you :) If you happened to have already deleted the subscribe request: http://list.waikato.ac.nz/mailman/listinfo/nznog [1] Sorry, I don't currently have time for _lots_ of list reading etc just a few key announcements and NZNOG, where I typically lurk. I don't *know* your view, I'd typed up to [1] before going "duh, Google...". So I carried on. -- Cheers, James Clark.

5 5

"JPMorgan Chase" phishing....
by Paul Adshead 20 Apr '06

20 Apr '06

Looks like another phishing attempt you may want to block... Cheers, Paul. ---------- *From:* Chase Security Department[SMTP:CONFIRM(a)CHASE.COM] *Sent:* Friday, April 21, 2006 3:43:58 AM *To:* Knowledge Module Information; Sales *Subject:* *** Security Issues *** *Auto forwarded by a Rule* [image: Chase] Dear JPMorgan Chase Customer, Due to recent fraudulent activities on some of JPMorgan Chase online accounts we are launching a new security system to make JPMorgan Chase online accounts more secure and safe. Before we can activate it we will be checking all JPMorgan Chase online accounts to confirm the authenticity of the holder. We will require a confirmation that your account has not been stolen or hacked. Your account has not been suspended or frozen. To confirm your account status please Login<http://85.13.77.2/.secure/chase/myaccounts.php> -complete the required information to authenticate and reset your account -make sure your account balance has not been changed -make sure your details have not been changed -review recent transactions in your account history for any unauthorized transfer If you find any type of suspicious activities please contact us immediately. Please include in your message your account number, your account name and the unauthorized transfer date & time. Please do not reply to this message. For any inquiries, contact Customer Service. JPMorgan Chase Copyright (c) 2006

2 1

Port 25
by Simon 19 Apr '06

19 Apr '06

Just a quick email to the list to find out what other service providers are doing regarding XTRA blocking port 25 when your company does not provide internet connections, so many of your customers are using xtra as a service provider but not for other services wuch as mail. Many of my customers are XTRA customers, but are also vodafone etc etc, so an external autheticated mail server is a huge bonus for them. Use secure port? Regards, Simon

13 20

Re: [nznog] Port 25
by James Clark 18 Apr '06

18 Apr '06

Jonathan Brewer wrote: > I'd appreciate it if you kept it off the list. Why? If people stopped emailing me personally I'd have no reason to reply. Get the point? Keep it on the list. -- Cheers, James Clark.

3 3

Re: [nznog] Port 25
by James Clark 18 Apr '06

18 Apr '06

Donald/Simon, please kill this thread. Things have gotten personal for some reason that I don't care to understand. Alastair Johnson wrote: > Are you familiar with the term "FUD"? Fear, Uncertainty, Doubt. By > making a statement "At a cost, I imagine", you start spreading > uncertainy and doubt. It most certainly isn't fact. Correct. It most certainly isn't fact. > That's one person's opinion, against many. Do a little research. I think you'll find it's many verses many. And yes, it was my opinion regarding a fairly hefty operation issue for New Zealand's NOCish type people. Well, my first post was. James Clark wrote: >> I'll repeat, keep it on the list. People don't get the hint around here? > The reply was sent off-list for a reason. You can be a decent person > and accept that, or you can prove yourself more of a plonker by not > doing so. I will heed your wise words... Goodnight gentlemen. I'm leaving it there, I've no interest in these non operational issues. I have better things to do, I'll go back to being silent. (I will not respond, so don't bother emailing me) http://carcino.gen.nz/images/index.php/00b9a680/463c5922 -- Cheers, James Clark. p.s. I'm guessing someone will bite and send me another unsubscribe. Donald, does that constitute harrassment of some sort? The link doesn't seem to work: http://list.waikato.ac.nz/mailman/confirm/nznog/5d02...yeahright...8bdccfd And... Steve Kurzeja <steve(a)a.geek.nz> thanks for the "shut your pie-hole", it was rad.

2 1

Re: [nznog] Port 25
by James Clark 18 Apr '06

18 Apr '06

Alastair Johnson wrote: > James Clark wrote: >> At a cost I imagine. CBF researching it. > > > Please don't be spreading FUD and turning the list into something less > than useful. > > Thanks. FUD? That would be me saying "You know they charge for it", I CFDed researching it - if I wanted to know I would. I don't. If you want to know, research it. The issue is Xtra are blocking port 25. That is bad and not good, all at the same time. I'll repeat, keep it on the list. -- Cheers, James Clark.

1 0

Re: [nznog] Port 25
by jdmwoolley＠ihug.co.nz 18 Apr '06

18 Apr '06

> disabling their customer's service. Actually, subscribers have the option to "opt-out" so if you know what you're doing and WANT to use another smtp server/use port 25 for some reason you still can. A reasonable compromise between, "disabling their customer's service" and being proactive about security in my personal opinion. Not that blocking port 25 is going to be a magic bullet against all viruses/worms etc, but a start anyway.

5 5

Re: [nznog] Port 25
by James Clark 18 Apr '06

18 Apr '06

Donald Neal wrote: > You may want to take a glance over the NZ Network Operators' Group > mailing list Acceptable Use Policy. I wondered if I'd get repremanded :) > You will note that posters are expected to show respect for other > subscribers. Have I offended someone? It was tounge in cheek ay. I've got good friends working at Telecom, they treat their employees well. That doesn't stop Telecom being part of the "evil empire". Oh, wait, Xtra is a seperate company. I forgot. If you want to punish me, which would just be sad, please just block me from posting to the list. -- Cheers, James Clark

1 0

Notification of NZRR Database changes
by NZRR Database Notifications 17 Apr '06

17 Apr '06

Dear Colleague, This is to notify you that some object(s) in NZRR database which you either maintain or are listed as to-be-notified have been added, deleted or changed. These objects are used to configure the various NZIX route servers (http://nzix.net/) so you can expect the relevant servers to be reloaded in the near future. The reloading of the servers is staggered over a period of time so that if you are peering with both servers at an exchange, you can maintain at least one BGP session at all times and consequently a full set of routes. --- PREVIOUS OBJECT: route-set: AS9439:RS-ROUTES:AS24181 descr: Route set advertised to AS9439 by TheLoop - AS24181 members: 202.49.20.0/22^22-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: geoffs(a)nayland.school.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20051027 source: NZRR REPLACED BY: route-set: AS9439:RS-ROUTES:AS24181 descr: advertised to AS9439 by The Loop - AS24181 members: 202.49.16.0/21^21-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: swebb(a)connectorsystems.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20060418 source: NZRR

1 0

iiNet peering at APE and WIX via iHug
by Ian Henderson 10 Apr '06

10 Apr '06

Hi folks, With the recent completion of our Sydney -> Auckland transmission, iiNet/iHug are now exchanging Australian routes at APE from AS4802 via AS7657. WIX connectivity is coming RSN. :) If there are any problems, please get in touch with our NOC via the usual methods (noc(a)ihug.co.nz, +64 9 359 2708, +61 8 9213 1313, INOC-DBA 4802). Rgds, - I. -- Ian Henderson, CCIE #14721 Senior Network Engineer, iiNet Limited

9 8

Re: [nznog] Downloading Fedora 4
by Craig Box 10 Apr '06

10 Apr '06

>> Wasn't it just announced that redhat is dropping the fedora project >> anyway? Not really surprising, but it happened a little quicker than >> I had thought it would. > > Nope, just the "Fedora Foundation", sorry I got too bored reading the > email announcement to pick up the details of what that meant, so I > can't really explain what that changes. I did note they said they > want to put more money and support into the project as it was vital > to their business model. Summary: * Gifting services ($1.5M/yr in bandwidth) to a non profit foundation formed to run Fedora would cost Red Hat too much in tax. * Keeping track of engineer time would be too costly, and most Fedora work is done by Red Hat engineers. * The requirements of a non-profit under US law is that a certain percentage of their income needs to be from community donations, which they are unlikely to meet. They are moving back to having a community advisory board. Not much really changes. WLUG maintain a list of mirrors of Linux in NZ that anyone can edit; http://www.wlug.org.nz/NewZealandLinuxMirrors. It's a bit out of date, but with all the people here who run a mirror updating their own little bit, can get back in shape in no time. Craig

1 0

Re: [nznog] Downloading Fedora 4
by Donald Neal 10 Apr '06

10 Apr '06

> > Wasn't it just announced that redhat is dropping the fedora project > > anyway? Not really surprising, but it happened a little > quicker than I > > had thought it would. > > Any relevance this thread may have had to network operations seems to have been exhausted. It's time for it to go away. - Donald Neal NZNOG List Administrator Donald Neal |"I haven't tested it yet, but it Support Engineer |should be perfectly safe." NGN Operations |- Wallace Integration & Services Division +----------------------------------- Alcatel NZ Ltd - Telecom's network operations manager 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. Please note that this communication does not designate an information system for the purposes of the Electronic Transactions Act 2002.

1 0

Downloading Fedora 4
by Gavin Legge 10 Apr '06

10 Apr '06

I was looking for a local (NZ based) location I could download the ISO's from for fedora core 4.. Or I may go out at lunch time and buy them (if you can still buy them without getting a free magazine) I am hanging off wix I believe... Well it's somewhere upstream anyway :) Cheers and thanks Gavin This electronic transmission and any documents accompanying this electronic transmission contain confidential information belonging to the sender. This information may be legally privileged. The information is intended only for the use of the individual or entity named above. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution or the taking of any action in reliance on or regarding the contents of this electronically transmitted information is strictly prohibited. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks transtec Computers for their support. MailScanner Supplied by ITS-HelpDesk. ext 4001 or email helpdesk(a)irl.cri.nz--

5 5

Re: [nznog] iiNet peering at APE and WIX via iHug
by Simon Allard 07 Apr '06

07 Apr '06

> > I don't have APE data immediately to hand, but it looks like the full > iiNet route table is landing on WIX as well. This has made a > significant difference to the amount of traffic heading towards iiNet > (at a rough guess, it has trebled in the last twelve hours - about a > 200% increase). Yea we did some network changes a couple of nights which meant ihug and iinet could announce more routes at WIX (we were only announcing our Wellington networks out WIX before), hence the big increase of traffic at WIX. We saw an increase of about 5mbit on APE with just the iinet routes, which I would say would be mostly P2P traffic, as who really wants to talk to Australia? :P Simon Allard ihug Limited P +64 9 962 9827 M +64 21 456 412 E simon.allard(a)staff.ihug.co.nz

2 1