- NZNOG - lists.nznog.org

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