- NZNOG - lists.nznog.org

NZRR Route Registry Update
by NZRR Database Notifications 11 Aug '08

11 Aug '08

Dear Colleague, This is to notify you that one or more objects in which you are designated for notification have been modified in the NZRR routing registry database. 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. Diagnostic output: ------------------------------------------------------------ --- PREVIOUS OBJECT: route-set: AS9560:RS-ROUTES:AS4770 descr: advertised to AS9560 by ICONZ Ltd - AS4770 members: 210.48.0.0/17^17-29, 210.185.0.0/18^18-29, 210.54.160.0/19^19-29, 114.134.160.0/20^20-29, 202.55.96.0/20^20-29, 202.174.160.0/20^20-29, 210.56.32.0/20^20-29, 114.134.176.0/21^21-29, 120.138.16.0/21^21-29, 202.12.248.0/21^21-29, 202.37.144.0/21^21-29, 202.37.224.0/21^21-29, 202.74.224.0/21^21-29, 202.78.240.0/21^21-29, 205.233.128.0/21^21-29, 202.36.36.0/22^22-29, 202.37.140.0/22^22-29, 202.37.200.0/22^22-29, 202.41.136.0/22^22-29, 203.80.60.0/22^22-29, 210.54.136.0/22^22-29, 210.55.24.0/22^22-29, 199.212.92.0/23^23-29, 202.36.76.0/23^23-29, 202.37.240.0/23^23-29, 202.37.252.0/23^23-29, 202.174.6.0/23^23-29, 205.233.136.0/23^23-29, 210.4.212.0/23^23-29, 192.88.85.0/24^24-29, 198.32.66.0/24^24-29, 202.6.84.0/24^24-29, 202.12.70.0/24^24-29, 202.14.100.0/24^24-29, 202.20.6.0/24^24-29, 202.21.130.0/24^24-29, 202.27.208.0/24^24-29, 202.36.45.0/24^24-29, 202.36.119.0/24^24-29, 202.36.183.0/24^24-29, 202.37.57.0/24^24-29, 202.37.73.0/24^24-29, 202.37.76.0/24^24-29, 202.37.85.0/24^24-29, 202.37.163.0/24^24-29, 202.46.190.0/24^24-29, 202.49.62.0/24^24-29, 202.49.89.0/24^24-29, 202.49.159.0/24^24-29, 202.50.87.0/24^24-29, 202.50.139.0/24^24-29, 205.233.243.0/24^24-29, 210.54.211.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: deon(a)iconz.net mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20080627 source: NZRR REPLACED BY: route-set: AS9560:RS-ROUTES:AS4770 descr: advertised to AS9560 by ICONZ Ltd - AS4770 members: 210.48.0.0/17^17-29, 210.185.0.0/18^18-29, 210.54.160.0/19^19-29, 114.134.160.0/20^20-29, 202.55.96.0/20^20-29, 202.174.160.0/20^20-29, 210.56.32.0/20^20-29, 114.134.176.0/21^21-29, 120.138.16.0/21^21-29, 202.12.248.0/21^21-29, 202.37.144.0/21^21-29, 202.37.224.0/21^21-29, 202.74.224.0/21^21-29, 202.78.240.0/21^21-29, 205.233.128.0/21^21-29, 210.4.208.0/21^21-29, 202.36.36.0/22^22-29, 202.37.140.0/22^22-29, 202.37.200.0/22^22-29, 202.41.136.0/22^22-29, 203.80.60.0/22^22-29, 210.54.136.0/22^22-29, 210.55.24.0/22^22-29, 199.212.92.0/23^23-29, 202.36.76.0/23^23-29, 202.37.240.0/23^23-29, 202.37.252.0/23^23-29, 202.174.6.0/23^23-29, 205.233.136.0/23^23-29, 192.88.85.0/24^24-29, 198.32.66.0/24^24-29, 202.6.84.0/24^24-29, 202.12.70.0/24^24-29, 202.14.100.0/24^24-29, 202.20.6.0/24^24-29, 202.21.130.0/24^24-29, 202.27.208.0/24^24-29, 202.36.45.0/24^24-29, 202.36.119.0/24^24-29, 202.36.183.0/24^24-29, 202.37.57.0/24^24-29, 202.37.73.0/24^24-29, 202.37.76.0/24^24-29, 202.37.85.0/24^24-29, 202.37.163.0/24^24-29, 202.46.190.0/24^24-29, 202.49.62.0/24^24-29, 202.49.89.0/24^24-29, 202.49.159.0/24^24-29, 202.50.87.0/24^24-29, 202.50.139.0/24^24-29, 205.233.243.0/24^24-29, 210.54.211.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: deon(a)iconz.net mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20080812 source: NZRR ------------------------------------------------------------

1 0

FW: Akamai streaming cluster on APE.
by Craig Spiers 09 Aug '08

09 Aug '08

So is this supposed to be still operating? Trailers.apple.com went there for about a week.. as did downloads.microsoft.com now it appears to go via an akamai cluster in Australia? Tested via traceroute from orcon.. -----Original Message----- From: Steve Kurzeja [mailto:steve(a)a.geek.nz] Sent: Thursday, 31 July 2008 3:38 p.m. To: nznog(a)list.waikato.ac.nz Subject: [nznog] Akamai streaming cluster on APE. Hi All, This is a courtesy email to let those peering at APE know that their APE traffic may start to increase today. Callplus and Akamai have worked together to deploy an Akamai streaming cluster on the APE. ISPs peered at the APE accessing Akamai streaming content (e.g. trailers.apple.com) should see this traffic shift from your transit providers to APE today or in the near future. The IP address range for this cluster is 119.224.143.0/26. To check you are reaching it correctly trailers.apple.com should resolve to an IP address within 119.224.143.0/26 and route via callplus1.ape.net.nz. Regards, Steve _______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog

4 4

Comp tickets to Digital Future Now Event - Auckland
by Thomas Rowley 07 Aug '08

07 Aug '08

Hi all, I have a couple of comps to the digital future now event ( www.digitalfuturenow.co.nz) If anyone is interested drop me an email, Cheers Thomas

1 0

dns cache poisoning and "slutty" isp recursors
by Jasper Bryant-Greene 07 Aug '08

07 Aug '08

in light of the recently-discussed vulnerability (details of which are now public) and the exploit now available, do any of the affected ISPs think it might be prudent to stop letting the whole Internet recurse through their recursive nameservers? testing from an IP in the USA, I was able to make recursive queries at six major NZ ISPs, and there are no doubt more. I won't bother naming, it's trivial for anyone to figure it out for themselves, and the affected ISPs (should) know who they are. answering recursive queries from anywhere removes the need to get a client on the ISP's network to look up names for you in order to poison the cache of the recursor... -jasper

12 14

Google Apps Issues
by Ashwin Vasanth 06 Aug '08

06 Aug '08

Hello there, Sorry if this is the wrong place to post but just wondering, anyone on this list having issues with Google Apps this morning? Been seeing issues with multiple clients especially with the Email services. Anyone else seeing any noise about this or is it just me? -- Regards Ashwin Vasanth skype: ashwin_vasanth

2 1

Importance of end-to-end IPv4 - research - please help
by Shane Alcock 05 Aug '08

05 Aug '08

As Richard mentioned earlier, WAND has recently done some work on behalf of Alcatel looking at the viability of SP-NAT. In particular, I've been investigating the number of incoming connections to DSL customers for a NZ ISP - how many customers are accepting connections and how many connections are they accepting? Long story short, over 40% of observed customer addresses accepted at least one incoming TCP connection over the time period we looked (around 4 consecutive days, including a weekend). This ratio grows to be more than 60% when UDP is also considered, although the counts for UDP aren't as reliable. Most of the incoming connections are on either well-known p2p ports or high-number ports, suggesting a lot of customers doing some form of p2p. More detailed results (plus pretty graphs!) can be found at http://www.wand.net.nz/~spa1/someisp/flow_counting/result_page.html#inbound In addition, WAND also looked into the average number of outbound sessions that those same DSL customers were using. The main aim there was to determine how many customers it would be feasible to place behind a single SP-NAT device. The results of that can be found on the same web-page (just scroll up a bit). Note that all these results are for a single ISP during a particular time period. It is very likely that other ISPs would see significantly different numbers depending on the profiles of the customers they tend to attract - warez monkeys vs Grandma, for instance. Shane Alcock WAND Network Research Group University of Waikato Nathan Ward wrote: > Hi all, > > I'm attempting to get a bead on the importance of end-to-end IPv4. > > By that I mean, home DSL user talking to another home DSL user. > > This is something that would break if we ran out of IPv4 space > tomorrow, and had to start putting customers behind service provider > NAT (SP-NAT). > > There's two ways I'm looking at doing this are: > 1) Using a vendor box on loan to do p2p packet inspection for a month > or so. This will tell us about how much "p2p[1]" traffic there is on a > network, compared to non-p2p traffic. > 2) Getting a packet capture from somewhere on a network for an hour, > or whatever is feasible in terms of storage and processing power. The > target of the capture would be traffic to/from a certain block of an > ISPs end user type customers (so, a DSL pool probably). Analyse this > and match it against dynamic address pools. > - Anything going out to another dynamic pool (as determined by > one of those dynamic pool lists) is something that would be broken by > SP-NAT. > - Any new incoming connections is something that would be broken > by SP-NAT. > > If there's anyone that's interested in the following please let me know: > a) Helping me with some research > b) Getting some free intelligence on the type of traffic on your > network (wave it in front of marketing, and drip feed them the pretty > graphs whenever you want something from them) > > My intent is to publish the results stuff freely, publicly and widely. > > I'd even like to get to the point where we can do it regularly > perhaps? Let me know if you're open to that. > > -- > Nathan Ward > > [1] By this I mean file sharing, skype, etc. Stuff commonly identified > with the "p2p" buzz word, as opposed to the technical peer-to-peer > phrase. > _______________________________________________ > NZNOG mailing list > NZNOG(a)l... <http://list.waikato.ac.nz/mailman/listinfo/nznog> > http://list.waikato.ac.nz/mailman/listinfo/nznog >

21 33

Apply for your ISIF ICT grant online
by Srinivas Chendi 04 Aug '08

04 Aug '08

Apply for your ISIF ICT grant online [Brisbane, Australia - August 4th] With the successful launch of The Information Society Innovation Fund (ISIF), many developing economies in the Asia Pacific region are expecting to benefit from grants funding later in 2008. ISIF has been widely praised for helping ICT development projects in Asia Pacific developing economies. This will now be further enhanced with the ability to apply online for ISIF grants. APNIC'S Paul Wilson is "pleased with the positive response we have received from the community so far and are happy to notify potential applicants that grant applications may now be lodged directly on our website using an online form. Most importantly, we look forward to seeing the grants come to fruition." ISIF is a joint initiative between the Canadian International Development Research Centre (IDRC), the Internet Society (ISOC), and the Asia Pacific Network Information Centre (APNIC), aimed at stimulating creative solutions to ICT development needs in the Asia Pacific region. ISIF provides grants of up to US$30,000 per project to help advance local and regional projects aimed at introducing, improving, and applying Internet and other digital communications technologies for the benefit of Asia-Pacific users and communities. Project proposals from Asia-Pacific based public or private sector organisations, university or research and development institutions, and non-government organisations will be considered. Applications must be aligned with ISIF program objectives, selection criteria and administrative guidelines. Individuals are not eligible for grants. The ISIF grant round for 2008 is now open and applications are due 1 September 2008. A total of US$375,000 is available for grants in 2008. Grants are to be made on a competitive basis and successful applicants will be required to make project details, outcomes and findings publicly available. Complete information on the program and how to apply is available on the ISIF website at http://www.isif.asia The online application for the grant can be accessed directly from http://application.isif.asia ISIF is proudly sponsored by the DotAsia Organisation, the registry operator for the .ASIA top level domain. For more information: Sylvia Cadena | ISIF Program Officer | info(a)isif.asia | http://www.isif.asia

1 0

Importance of end-to-end IPv4 - research - please help
by Nathan Ward 04 Aug '08

04 Aug '08

Hi all, I'm attempting to get a bead on the importance of end-to-end IPv4. By that I mean, home DSL user talking to another home DSL user. This is something that would break if we ran out of IPv4 space tomorrow, and had to start putting customers behind service provider NAT (SP-NAT). There's two ways I'm looking at doing this are: 1) Using a vendor box on loan to do p2p packet inspection for a month or so. This will tell us about how much "p2p[1]" traffic there is on a network, compared to non-p2p traffic. 2) Getting a packet capture from somewhere on a network for an hour, or whatever is feasible in terms of storage and processing power. The target of the capture would be traffic to/from a certain block of an ISPs end user type customers (so, a DSL pool probably). Analyse this and match it against dynamic address pools. - Anything going out to another dynamic pool (as determined by one of those dynamic pool lists) is something that would be broken by SP-NAT. - Any new incoming connections is something that would be broken by SP-NAT. If there's anyone that's interested in the following please let me know: a) Helping me with some research b) Getting some free intelligence on the type of traffic on your network (wave it in front of marketing, and drip feed them the pretty graphs whenever you want something from them) My intent is to publish the results stuff freely, publicly and widely. I'd even like to get to the point where we can do it regularly perhaps? Let me know if you're open to that. -- Nathan Ward [1] By this I mean file sharing, skype, etc. Stuff commonly identified with the "p2p" buzz word, as opposed to the technical peer-to-peer phrase.

4 4

NZRR Route Registry Update
by NZRR Database Notifications 03 Aug '08

03 Aug '08

Dear Colleague, This is to notify you that one or more objects in which you are designated for notification have been modified in the NZRR routing registry database. 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. Diagnostic output: ------------------------------------------------------------ --- PREVIOUS OBJECT: route-set: AS9560:RS-ROUTES:AS23755 descr: Route set advertised to AS9560 by MediaNET - AS23755 members: 202.7.4.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: rpsl-admin(a)nzix.net mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20060222 source: NZRR REPLACED BY: route-set: AS9560:RS-ROUTES:AS23755 descr: advertised to AS9560 by Citylink - AS23755 members: 202.7.4.0/22^22-29, 202.8.44.208/28^28-29, 202.8.47.64/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: dylan(a)citylink.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20080804 source: NZRR ------------------------------------------------------------

1 0

NZRR Route Registry Update
by NZRR Database Notifications 03 Aug '08

03 Aug '08

Dear Colleague, This is to notify you that one or more objects in which you are designated for notification have been modified in the NZRR routing registry database. 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. Diagnostic output: ------------------------------------------------------------ --- PREVIOUS OBJECT: route-set: AS9439:RS-ROUTES:AS23755 descr: Route set advertised to AS9439 by MediaNET - AS23755 members: 202.7.4.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: rpsl-admin(a)nzix.net mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20060222 source: NZRR REPLACED BY: route-set: AS9439:RS-ROUTES:AS23755 descr: advertised to AS9439 by Citylink - AS23755 members: 202.7.4.0/22^22-29, 202.8.44.208/28^28-29, 202.8.47.64/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: dylan(a)citylink.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20080804 source: NZRR ------------------------------------------------------------

1 0

Re: [nznog] Akamai streaming cluster on APE.
by Richard Naylor 03 Aug '08

03 Aug '08

At 04:08 p.m. 31/07/2008, Allard, Simon, VF-NZ wrote: >Keep in mind that Akamai Streaming != Akamai Static content Not neccessarily. I did a live streaming job just before Christmas 07 for a site in Germany that had Akamai as its back end for both Live and on-demand. We were live for about 10 days. The feed point (ingest) was Sydney (via 2 different ISPs). The closest server was also Sydney from memory. The on-demand we uploaded to Germany each night. Peering used to be a dirty word at Akamai. Their business model/architecure didn't encourage it. So it would have been a "very large customer" (tm) who got it changed. It means on-line.skytv.co.nz will work now. Good work by CallPlus.

2 1

Re: [nznog] Akamai streaming cluster on APE.
by Anton Smith 02 Aug '08

02 Aug '08

> > Message: 18 > Date: Fri, 01 Aug 2008 00:37:36 +1200 > From: Richard Naylor <richard.naylor(a)r2.co.nz> > Subject: Re: [nznog] Akamai streaming cluster on APE. > To: "Allard, Simon, VF-NZ" <Simon.Allard(a)vodafone.com>, "Bill Walker" > <Bill.Walker(a)staff.snap.net.nz>, <nznog(a)list.waikato.ac.nz> > Message-ID: <20080731123754.0F3DD7D82D3(a)angus.iconz.co.nz> > Content-Type: text/plain; charset="us-ascii"; format=flowed > > At 04:08 p.m. 31/07/2008, Allard, Simon, VF-NZ wrote: > >Keep in mind that Akamai Streaming != Akamai Static content > > Not neccessarily. I did a live streaming job just before Christmas 07 > for a site in Germany that had Akamai as its back end for both Live > and on-demand. We were live for about 10 days. The feed point > (ingest) was Sydney (via 2 different ISPs). The closest server was > also Sydney from memory. The on-demand we uploaded to Germany each night. > > Peering used to be a dirty word at Akamai. Their business > model/architecure didn't encourage it. So it would have been a "very > large customer" (tm) who got it changed. > > It means on-line.skytv.co.nz will work now. > > Good work by CallPlus. > hmm... try telling that to Patrick Gilmore, the peering coordinator for akamai - one of the most vocal peering guys in europe. how long ago was it that peering was a dirty word for akamai? Anton

3 2

APNIC 26 - Early bird registration bonus
by Srinivas Chendi 31 Jul '08

31 Jul '08

________________________________________________________________________ APNIC 26 Early bird registration bonus - but hurry! ________________________________________________________________________ Dear APNIC members and friends APNIC 26 will be held from 25 to 29 August 2008 in Christchurch, New Zealand. Early bird registration ----------------------- Register by credit card before 01 August 2008 and go into the draw for an ASUS Eee PC! Now when you register online, you will be issued with an eTicket, which will make your onsite registration quicker and easier. Register now at: http://www.apnic.net/meetings/26/register Be part of APNIC 26 - from anywhere ----------------------------------- Participating in APNIC meetings from anywhere in the region is now even easier. Access the new APNIC remote participation interface that allows you to watch and hear the sessions in real time. Members can follow the meetings through live audio and video streaming, transcripts, and Jabber chat. If you would like to ask questions, you can join our Jabber chat rooms and have your question read live. If you are not able to access the session, you can log your question to be asked on your behalf. You can also attend the APNIC policy discussion and member meeting remotely at events in Manila, Philippines and Hanoi, Vietnam. APNIC would like to thank ASTI and VNNIC for their generous support for these events. Visit the meeting website for more details http://www.apnic.net/meetings/26/remote Hostmaster consultations ------------------------ Also at APNIC 26 are the hostmaster consultations, where members can personally consult with a hostmaster in a face-to-face environment. Online bookings are now available. Please visit "Hostmaster consultation" from: http://www.apnic.net/meetings/26 Sincerely, ________________________________________________________________________ APNIC Secretariat Asia Pacific Network Information Centre (APNIC) Tel: +61 7 3858 3100 PO Box 2131 Milton, QLD 4064 Australia Fax: +61 7 3858 3199 Level 1, 33 Park Road, Milton, QLD http://www.apnic.net ________________________________________________________________________

1 0

Akamai streaming cluster on APE.
by Steve Kurzeja 30 Jul '08

30 Jul '08

Hi All, This is a courtesy email to let those peering at APE know that their APE traffic may start to increase today. Callplus and Akamai have worked together to deploy an Akamai streaming cluster on the APE. ISPs peered at the APE accessing Akamai streaming content (e.g. trailers.apple.com) should see this traffic shift from your transit providers to APE today or in the near future. The IP address range for this cluster is 119.224.143.0/26. To check you are reaching it correctly trailers.apple.com should resolve to an IP address within 119.224.143.0/26 and route via callplus1.ape.net.nz. Regards, Steve

13 13

Re: [nznog] Akamai streaming cluster on APE.
by Steve Kurzeja 30 Jul '08

30 Jul '08

That is correct, and the streaming deployment also contains the standard Akamai content too. A heads up to ISPs with standard Akamai caches, you may want to check the traffic on your deployments hasn't dropped significantly. If it has then please contact Akamai. Steve > Keep in mind that Akamai Streaming != Akamai Static content > > > >> -----Original Message----- >> From: Bill Walker [mailto:Bill.Walker(a)staff.snap.net.nz] >> Sent: Thursday, 31 July 2008 4:03 p.m. >> To: nznog(a)list.waikato.ac.nz >> Subject: Re: [nznog] Akamai streaming cluster on APE. >> >> Lots of ISP's including Inspire, WorldxChange, Snap, Telstra >> and Telecom have Akamai Caching servers. >> >> traceroute download.microsoft.com >> >> Translating "download.microsoft.com"...domain server >> (202.37.101.1) [OK] >> >> Type escape sequence to abort. >> Tracing the route to a767.ms.akamai.net (202.124.116.42) >> >> 1 snap-chc-state2-rtr01.snap.net.nz (202.37.101.94) 0 msec >> 0 msec 0 msec >> 2 a767.ms.akamai.net (202.124.116.42) 0 msec 0 msec 0 msec >> >> Cheers, >> >> Bill >> >> -----Original Message----- >> From: Jed Laundry [mailto:jlaundry(a)gmail.com] >> Sent: Thursday, 31 July 2008 3:58 p.m. >> To: Matthew Poole >> Cc: nznog(a)list.waikato.ac.nz >> Subject: Re: [nznog] Akamai streaming cluster on APE. >> >> TelstraClear has a direct connection to Akamai, or at least >> it appears to from here at Waikato uni. >> >> I believe Xtra also has a direct link as well. >> >> Jed. >> >> >> >> Matthew Poole wrote: >> > -----BEGIN PGP SIGNED MESSAGE----- >> > Hash: SHA1 >> > >> > >> > Jonathan Brewer wrote: >> > | Hi Steve, >> > | >> > | As an end user I can't begin to express how happy I am that my >> > | Akamai content will start coming from New Zealand, >> instead of from >> > | Japan via San Jose. >> > | >> > | Cheers to Callplus! >> > | >> > But only if you're not connecting through TelstraClear. And >> has Xtra >> > got its peering sorted out yet? >> > - -- >> > Matthew Poole >> > "Don't use force. Get a bigger hammer." >> > -----BEGIN PGP SIGNATURE----- >> > Version: GnuPG v1.4.8 (Darwin) >> > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org >> > >> > iD8DBQFIkTV9TdEtTmUCdpwRAkROAKCdUYHyCV0sc2Kx5Uqy5G16l2kOBACfb0j9 >> > 0513O/k0m9KSupjls/jy56w= >> > =PYqC >> > -----END PGP SIGNATURE----- >> > _______________________________________________ >> > NZNOG mailing list >> > NZNOG(a)list.waikato.ac.nz >> > http://list.waikato.ac.nz/mailman/listinfo/nznog >> >> -- >> Thanks, >> Jed. >> >> -- >> Jed Laundry >> jlaundry(a)gmail.com >> >> +64 27 612 0522 >> _______________________________________________ >> NZNOG mailing list >> NZNOG(a)list.waikato.ac.nz >> http://list.waikato.ac.nz/mailman/listinfo/nznog >> >> No virus found in this incoming message. >> Checked by AVG - http://www.avg.com >> Version: 8.0.138 / Virus Database: 270.5.8/1582 - Release >> Date: 30/07/2008 6:37 p.m. >> _______________________________________________ >> NZNOG mailing list >> NZNOG(a)list.waikato.ac.nz >> http://list.waikato.ac.nz/mailman/listinfo/nznog >> > ----------------------------------------------------------------------------------------------- > > Unless otherwise stated, any views or opinions expressed are solely those > of the author and do > not represent those of Vodafone New Zealand Limited. > _______________________________________________ > NZNOG mailing list > NZNOG(a)list.waikato.ac.nz > http://list.waikato.ac.nz/mailman/listinfo/nznog >

1 0

very strange browsing issue from international after 5:XXpm
by Barry Murphy 30 Jul '08

30 Jul '08

Hey guys, I've a little problem which I've logged with Orcon but wondering if anyone on this list could possibly give some advise, or if anyone else on this list has seen this issue lately. A client of mine has developers in India, there developers have not been able to access servers hosted by us after 5:30pm in the evening, however during the day (NZST) they can view the pages fine. what happens is the page doesn't load at all, they just get a blank page and it times out, however they can ping and traceroute to our servers just fine. During the time when they get these timeouts, they're able to load Orcon.net.nz with no issues and all other sites in NZ. I will also mention that I've had people test this from windows, linux, unix, internet explorer, firefox, lynx, etc and the users are coming from South Africa, india, kenya, the odd one in Australia, etc. Most other countries can view the sites with no issues, but the whole of india cant and other select countries. I've had them run mturoute, traceroute, ping, load sites by IP address, and much more, but it doesn't work, every now and then pages will start loading for a short period. I've cut data over to our secondary circuit, checked for errors, checked mtu's, replaced juniper gear with cisco gear, had them attempt to connect to other servers etc. I've replaced every node and piece of gear in our network and used different ethernet paths from within Orcons DC and the problem still persists. Unfortunately Orcon's technical support ends at 5pm, this problem starts at 5:30pm, on-call staff don't appear to be able to help as the problem is a little over their head and network engineers only work on faults during the day. The problem started Sunday from what I can tell and 2 nights in a row I've asked for help from orcon but have received none yet, however they did mention it's funny one other person reported a similar issue. So, does anyone have any suggestions for me (off list please) and is anyone else seeing similar issues on their network in the evening through orcon or other vendor? In case this is a little off-topic (which I hope it's not), beer for the person that can fix this! Thanks Barry Murphy

3 2

NZRR Route Registry Update
by NZRR Database Notifications 28 Jul '08

28 Jul '08

Dear Colleague, This is to notify you that one or more objects in which you are designated for notification have been modified in the NZRR routing registry database. 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. Diagnostic output: ------------------------------------------------------------ --- PREVIOUS OBJECT: route-set: AS9560:RS-ROUTES:AS24324 descr: advertised to AS9560 by Kordia - AS24324 members: 118.148.0.0/15^15-29, 124.157.64.0/18^18-29, 58.84.224.0/20^20-29, 114.134.0.0/20^20-29, 116.89.224.0/20^20-29, 202.56.32.0/20^20-29, 202.68.80.0/20^20-29, 203.144.32.0/20^20-29, 116.90.128.0/21^21-29, 117.104.176.0/21^21-29, 123.108.144.0/21^21-29, 202.20.0.0/21^21-29, 202.49.16.0/21^21-29, 202.49.128.0/21^21-29, 202.56.48.0/21^21-29, 202.137.240.0/21^21-29, 218.185.224.0/21^21-29, 202.6.116.0/23^23-29, 202.27.88.0/23^23-29, 202.65.160.0/23^23-29, 202.174.190.0/23^23-29, 203.110.28.0/23^23-29, 192.173.17.0/24^24-29, 202.21.130.0/24^24-29, 202.27.34.0/24^24-29, 202.27.83.0/24^24-29, 202.27.90.0/24^24-29, 202.36.75.0/24^24-29, 202.36.137.0/24^24-29, 202.36.154.0/24^24-29, 202.36.173.0/24^24-29, 202.37.168.0/24^24-29, 202.37.197.0/24^24-29, 202.49.158.0/24^24-29, 202.49.183.0/24^24-29, 203.30.174.0/24^24-29, 203.92.25.0/24^24-29, 203.171.4.0/24^24-29, 203.174.26.0/24^24-29, 203.97.62.200/29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: smc(a)kordia.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20080630 source: NZRR REPLACED BY: route-set: AS9560:RS-ROUTES:AS24324 descr: advertised to AS9560 by Kordia Ltd - AS24324 members: 118.148.0.0/15^15-29, 124.157.64.0/18^18-29, 58.84.224.0/20^20-29, 114.134.0.0/20^20-29, 116.89.224.0/20^20-29, 202.56.32.0/20^20-29, 202.68.80.0/20^20-29, 203.144.32.0/20^20-29, 116.90.128.0/21^21-29, 117.104.176.0/21^21-29, 123.108.144.0/21^21-29, 202.20.0.0/21^21-29, 202.49.16.0/21^21-29, 202.49.128.0/21^21-29, 202.56.48.0/21^21-29, 202.137.240.0/21^21-29, 218.185.224.0/21^21-29, 202.6.116.0/23^23-29, 202.27.88.0/23^23-29, 202.49.164.0/23^23-29, 202.65.160.0/23^23-29, 202.174.190.0/23^23-29, 203.110.28.0/23^23-29, 192.173.17.0/24^24-29, 202.21.130.0/24^24-29, 202.27.34.0/24^24-29, 202.27.83.0/24^24-29, 202.27.90.0/24^24-29, 202.36.75.0/24^24-29, 202.36.137.0/24^24-29, 202.36.154.0/24^24-29, 202.36.173.0/24^24-29, 202.37.168.0/24^24-29, 202.37.197.0/24^24-29, 202.49.158.0/24^24-29, 202.49.168.0/24^24-29, 202.49.183.0/24^24-29, 203.30.174.0/24^24-29, 203.92.25.0/24^24-29, 203.171.4.0/24^24-29, 203.174.26.0/24^24-29, 203.97.62.200/29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: praneel.prasad(a)kordia.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20080729 source: NZRR ------------------------------------------------------------

1 0

Change to APNIC minimum IPv4 allocation size
by Elly Tawhai 28 Jul '08

28 Jul '08

________________________________________________________________________ Change to APNIC minimum IPv4 allocation size ________________________________________________________________________ The information in this announcement is to enable the Internet community to update network configurations, such as routing filters, where required. Dear NZNOG Community, >From 4 August 2008, the new APNIC minimum IPv4 allocation size will be /22. For information on this policy change, see: http://www.apnic.net/policy/proposals/prop-053-v003.html For information on the minimum allocation sizes within address ranges administered by APNIC, please see: http://www.apnic.net/db/min-alloc.html For more information on the resources administered by APNIC, please see: http://www.apnic.net/db/ranges.html Kind regards, Elly ________________________________________________________________________ Elly Tawhai email: hostmaster(a)apnic.net Senior Internet Resource Analyst, APNIC sip: hostmaster(a)voip.apnic.net http://www.apnic.net/helpdesk phone: +61 7 3858 3188 fax: +61 7 3858 3199 ________________________________________________________________________ Hope to see you at APNIC 26 in Christchurch, New Zealand 25 - 29 August 2008 http://www.apnic.net/meetings/26/

1 0

Re: [nznog] Digital Future Now Event - Auckland
by Stu Fleming 28 Jul '08

28 Jul '08

> > "Hon. David Cunliffe, Minister for Communication and Information Technology, > will discuss the government's final Digital Strategy for New Zealand > business." "Final". Ouch. So the election has been [bf]ought already?

1 0

Digital Future Now Event - Auckland
by Thomas Rowley 28 Jul '08

28 Jul '08

Just letting everyone know about 'Digital Future Now' 13th August 2008 - Sky city Convention Centre, Auckland "This one day business forum is a follow up to the Digital Future Summit and will look at all of the issues for businesses operating in an increasingly online environment." "Hon. David Cunliffe, Minister for Communication and Information Technology, will discuss the government's final Digital Strategy for New Zealand business." *www.digitalfuturenow.co.nz* <http://www.digitalfuturenow.co.nz> Thanks Thomas

1 0

Re: [nznog] DNS Cache Poisoning
by Spiro Harvey, Knossos Networks Ltd 28 Jul '08

28 Jul '08

> Once this had gone public CCIP should have engaged this forum. CCIP has > well defined procedures and processes in place when sharing information with > the National and International security communities and the "traditional" > critical infrastructure community. Outside of those communities the process Does "critical national infrastructure" (as quoted from your website) include all NZ ISPs, or just the big players? > Another suggestion is the > need for a closed mailing list for the NZ ISP community. Closed lists seem to serve two purposes: 1) making the members feel 1337; and 2) money spinners. And who would act as the "police" to ensure that all members are ISP representatives? Who would keep tabs on which members have changed jobs and thus require removal from the list? I see this as a way to introduce #2 as above. Then you give all members club cards or secret decoder rings and if the smaller ISPs have trouble coming up with the funds, they'll be excluded. Perhaps it's more pertinent to ask "What is the end goal?" Is it to keep the NZ ISP industry aware of all security issues? Or is it to create a secret club? It's likely that the undesirables already know of the vulnerabilities, and the media will find out anyway and put some dramatic spin on it to keep themselves employed. What about operators of private networks? Shouldn't they know about these issues to protect their networks from attack? In this scenario, one poisoned DNS cache on a company intranet could lead to an entire company's PCs being hijacked or infected, or whatever the poisoner decides will provide the maximum amusement. With your secret club proposal, these network operators would not be aware of the issues because they're not ISPs. I believe NZNOG is the perfect avenue for security vulnerability disclosure. -- Spiro Harvey Knossos Networks Ltd 021-295-1923 www.knossos.net.nz

1 0

Re: [nznog] DNS Cache Poisoning
by Nathan Ward 27 Jul '08

27 Jul '08

On 28/07/2008, at 11:28 PM, Paul McKitrick wrote: > Good Evening Everyone, > > I have to agree with Joe's post and I have also had a number of > other off > post emails reiterating the same message. > > Once this had gone public CCIP should have engaged this forum. CCIP > has > well defined procedures and processes in place when sharing > information with > the National and International security communities and the > "traditional" > critical infrastructure community. Outside of those communities the > process > is not as well defined and this event has highlighted this. What > this event > has also demonstrated is that the NZNOG community is dedicated to > protecting > New Zealand's networks and we just need to figure out how we can do > that > together, and part of that is ensuring the right information gets to > the > right people. > > One of the recent suggestions CCIP has received is the concept of > establishing an NSP-SEC group for New Zealand. Another suggestion > is the > need for a closed mailing list for the NZ ISP community. The > intention > would not be to replace the NZNOG mailing list but to have an > alternative > for when the community needed a closed and trusted mode of > communication. > CCIP would like to work with this community to investigate > establishing > something along these lines in New Zealand and to listen to your > thoughts > and suggestions on this topic as a number of you have been thinking > about > this for some time as well. I'm not sure I understand what benefit a closed list would have in this sort of scenario, to be honest. I can't imagine that CCIP, or anyone else, are going to have information about security problems like this before they are in the wild - there's just too many people involved globally for closed distribution to be truly closed. The NZ ISP community (or at least those who I imagine you'd put on such a closed list) is small enough that all those people have everyone else's contact details already, and any incident really only needs calls or emails to two or three other providers. A large benefit for most people who attend the NZNOG conferences is the ability to have a beer with their industry peers and set up those contacts[1]. The only thing I could imagine a list would be used for is discussion about technical issues where media, end users, and other generally non- technical people cannot read[2] - but that's not really a security list. -- Nathan Ward [1] This sentence doesn't really add much, but I'm bringing my post on topic :-) [2] Some have suggested that the presence of media, end users, etc. on NZNOG is a large factor in the lack of pure technical content. Some people talked about setting up an invite only list a few years ago, but it never got off the ground (or at least, if I did I wasn't invited ;-), largely because it was assumed that legal departments would have a problem with open technical discussion - even without media, end users, etc. listening in. -- Nathan Ward

2 1

DNS Cache Poisoning
by Paul McKitrick 27 Jul '08

27 Jul '08

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Good Evening All, I thought it would be good to let you know that CCIP is aware of this vulnerability and has been working on it behind the scenes with the international community since May. In early July CCIP met with NZ Registry Services to discuss this issue and determine who the most appropriate audience for this information would be. Because of the sensitivity of this it was determined that the NZNOG mailing list would not be appropriate as it is an open forum with over 800 registered participants. It was agreed that the best method would be to send this out to the ISPANZ members. CCIP also issued an embargoed release to some of the larger ISP's prior to the public release. CCIP regularly work very closely with the international CERT community to coordinate on the dissemination of information such as this and we have been working a lot over the last few weeks to coordinate on this particular release. CCIP had the release prepared to send out the morning that it was made public. This was a report that had been prepared in conjunction with the international CERT community. While it may appear that CCIP or other CERTs reporting is just simply re-badged products from another country it has often has been worked on collaboratively prior to the release. This is to ensure that clear and consistent messages are being issued by all countries. CCIP is hosting an international meeting here later in the year where a key item on the agenda is this specific event. There will be a review of this collaborative effort and where it worked well and where there is room for improvement. CCIP has identified that in New Zealand there is a need for a stronger relationship between CCIP and the NZ ISP community and developing those relationships is going to be an ongoing process. If you have any details of vulnerable DNS servers in New Zealand please do not hesitate to send these through to incidents(a)ccip.govt.nz. There have been some already sent through today from members of this list and those have been or are being addressed by the relevant ISP's and thank you for sending those through. If you would like to introduce yourself to CCIP and/or to arrange a time to come in to meet with CCIP please feel free to contact CCIP at (info(a)ccip.govt.nz). Regards, Paul. - -- Paul McKitrick Business Manager Centre for Critical Infrastructure Protection P: (+64) 4 498 7654 F: (+64) 4 498 7655 E: paul.mckitrick(a)ccip.govt.nz W: www.ccip.govt.nz -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQEVAwUBSIlzyDpQQM+EFUs7AQKLqwgAyfn/HPnxWW3MQvyt6nPHQJwkTIk8slpK 0SoclMnIoyX7HxJhjFF8z369Bfece1xg/3kUE4D2d693lVv1Aih6LUIf/BrprppF iJJmZCXbf3n3y2ZSLembf+vDj/Ff1/JYFECDKLsJNjDESTd2i2X6EgeZGMXeR41p cwKVUoyrmWbdmBcsxHkwAjy8KBwBBIBzBiwkW7tKd9Ed5RhoIlVrkmWgrJrdvMDf aF28UUUP2aYRisHrZJnTwkw1Z3ghFp12emNj2EMJons0ZLPKLhV1vt573eeyqFYH deQ6BbYNqpzvNrqVewSE07kBY2t8SDf3wFs8sI+VoPinAV8HGyvUvg== =NmEG -----END PGP SIGNATURE----- --- This e-mail contains official New Zealand Government information, which is intended for the use of addressees only. If you have received this e-mail in error, please notify the sender immediately and delete. You should not further disseminate, distribute or copy this e-mail in any way. ---

4 4

Christchurch 5756
by Stan Rivett 27 Jul '08

27 Jul '08

Hi Guys Has anyone fired up anything new or changed channels on Saturday around the Christchurch CBD? I've been running my South facing AP happilly on 5756 MHz for about 4 years and now all my clients on this AP are pretty much toast :( Cheers Stan Rivett ------------------ Netspeed Data Ltd PO Box 5691 Dunedin P: +64 3 481 7245 F: +64 3 481 7249 C: +64 21 323 841 Skype: stan-r ------------------

1 0

NZRR Route Registry Update
by NZRR Database Notifications 24 Jul '08

24 Jul '08

Dear Colleague, This is to notify you that one or more objects in which you are designated for notification have been modified in the NZRR routing registry database. 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. Diagnostic output: ------------------------------------------------------------ --- PREVIOUS OBJECT: route-set: AS9439:RS-ROUTES:AS64595 descr: Route set advertised to AS9439 by Learning Media - AS64595 members: 210.55.244.160/28^28-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: gary(a)learningmedia.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20040702 source: NZRR REPLACED BY: route-set: AS9439:RS-ROUTES:AS64595 descr: advertised to AS9439 by LearningMedia - AS64595 members: 203.167.252.112/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: terry.moore(a)learningmedia.co.nz notify: gary.jarvis(a)learningmedia.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20080725 source: NZRR ------------------------------------------------------------

1 0

Fwd: [apnic-talk] [Apnic-announce] AS number change could affect Internet routing from 1 January 2009
by Neil Fenemor 24 Jul '08

24 Jul '08

A bit of an FYI. It may be worth members approaching their respective vendors to find out what the timelines are around this. ---------- Forwarded message ---------- From: <secretariat(a)apnic.net> Date: 2008/7/25 Subject: [apnic-talk] [Apnic-announce] AS number change could affect Internet routing from 1 January 2009 To: apnic-announce(a)apnic.net ________________________________________________________________________ AS number change could affect Internet routing from 1 January 2009 ________________________________________________________________________ Manufacturers urged to upgrade routers and network management software to support the use of four-byte Autonomous System numbers by 1 January 2009. Regional Internet Registries (RIRs), including Asia Pacific Network Information Centre (APNIC), have warned that routers and network management software should be upgraded ahead of the increased distribution of four-byte (also known as 32-bit) Autonomous System (AS) numbers. AS numbers are a vital part of the Internet's core routing system, the Border Gateway Protocol (BGP). With existing two-byte AS numbers predicted to run out in early 2011, RIRs will issue four-byte AS numbers by default (unless otherwise specifically requested) beginning 1 January 2009, as the next phase of a transition from two- to four-byte numbers. Following a globally coordinated policy, RIRs began allocating four-byte AS numbers by request only in January 2007; January 2009 marks the transition to allocating four-byte AS numbers by default. Without timely support from vendors, network operators risk having routers and network administration systems that won't accept the expanded four-byte number format. As such, the RIRs urge operators to verify their vendors' routers will support four-byte AS numbers. Geoff Huston, Chief Scientist at APNIC, expressed severe concerns over failure to prepare for four-byte AS numbers: "AS numbers are often used to identify external relationships, set routing attributes, and manage traffic. Learning from our current experiences with IPv6 preparation issues, Internet engineers designed four-byte AS numbers to be backward compatible with much of the installed network infrastructure. But new entrants and networks that are expanding or merging will need new AS numbers and as of 1 January 2009 these will be, by default, four-byte AS numbers. If router software and support systems in critical parts of the Internet's infrastructure aren't upgraded by January, we'll encounter some significant network routing problems. We're extremely concerned that a lot of routers and network management software out there cannot and will not be able to recognize four-byte AS numbers". An Autonomous System (AS) is a collection of networks, or routers, administered as a group sharing a common set of routing policies, each defined with a unique number, or AS number. Massive Internet growth has depleted the existing pool of two-byte AS numbers (65,536 numbers in total). As a result, engineers have expanded the AS number space from two bytes to four-bytes, to include over 4 billion AS numbers. Some routers do not currently support the use of four-byte AS numbers. To help vendors understand what they need to do to provide four-byte AS number support and to help network operators find products that support four-byte AS numbers, APNIC has set up a special website at: http://wiki.icons.apnic.net/display/ASN/Home Yours sincerely ________________________________________________________________________ APNIC Secretariat Asia Pacific Network Information Centre (APNIC) Tel: +61 7 3858 3100 PO Box 2131 Milton, QLD 4064 Australia Fax: +61 7 3858 3199 Level 1, 33 Park Road, Milton, QLD http://www.apnic.net ________________________________________________________________________ _______________________________________________ Apnic-announce mailing list Apnic-announce(a)lists.apnic.net http://mailman.apnic.net/mailman/listinfo/apnic-announce _______________________________________________ apnic-talk mailing list apnic-talk(a)lists.apnic.net http://mailman.apnic.net/mailman/listinfo/apnic-talk

1 0

IPv6 Technical Workshops - PCH / Cisco
by Keith Davidson 24 Jul '08

24 Jul '08

All, InternetNZ, in conjunction with REANNZ, Cisco, Packet Clearing House, NZRS, auDA and FX Networks, is offering IPv6 technical workshops in Christchurch and Auckland. This follows on from having already run this workshop in Wellington in August last year. The first 5 day programme will run in Christchurch from Saturday 30 August to Wednesday 3 September, and the second in Auckland from Monday 8 September to Friday 12 September. Attendence on each course is limited to 28 participants. Registration is on a first come, first served basis. Please see the attached document for details. More details are available at http://blog.internetnz.net.nz/wp-content/uploads/2008/07/2008-augsep-ipv6-w… To register email richard at internetnz.net.nz To keep this message list-compliant, please note InternetNZ will possibly provide beer to workshop participants. Cheers Keith Davidson Executive Director - InternetNZ

1 0

NZRR Route Registry Update
by NZRR Database Notifications 23 Jul '08

23 Jul '08

Dear Colleague, This is to notify you that one or more objects in which you are designated for notification have been modified in the NZRR routing registry database. 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. Diagnostic output: ------------------------------------------------------------ --- PREVIOUS OBJECT: route-set: AS9439:RS-ROUTES:AS65531 descr: Route set advertised to AS9439 by parliament - AS65531 members: 202.22.16.0/23^23-29, 202.22.18.0/24^24-29, 202.22.23.0/24^24-29, 202.22.30.0/24^24-29, 202.49.210.0/24^24-29, 202.49.213.0/24^24-29, 203.97.200.0/24^24-29, 203.97.232.80/28^28-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: john.howell(a)parliament.govt.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20051102 source: NZRR REPLACED BY: route-set: AS9439:RS-ROUTES:AS65531 descr: advertised to AS9439 by Parliamentary Service - AS65531 members: 202.22.16.0/21^21-29, 202.49.208.0/21^21-29, 202.22.24.0/22^22-29, 202.22.28.0/23^23-29, 202.22.30.0/24^24-29, 203.97.232.80/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: John.Howell(a)parliament.govt.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20080724 source: NZRR ------------------------------------------------------------

1 0

NZRR Route Registry Update
by NZRR Database Notifications 23 Jul '08

23 Jul '08

Dear Colleague, This is to notify you that one or more objects in which you are designated for notification have been modified in the NZRR routing registry database. 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. Diagnostic output: ------------------------------------------------------------ --- PREVIOUS OBJECT: route-set: AS9560:RS-ROUTES:AS17705 descr: advertised to AS9560 by InspireNet - AS17705 members: 203.114.128.0/18^18-29, 121.79.192.0/19^19-29, 192.138.251.0/24^24-29, 203.92.25.0/24^24-29, 210.7.46.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: brenden(a)staff.inspire.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20080411 source: NZRR REPLACED BY: route-set: AS9560:RS-ROUTES:AS17705 descr: advertised to AS9560 by InspireNet - AS17705 members: 203.114.128.0/18^18-29, 121.79.192.0/19^19-29, 140.200.248.0/22^22-29, 192.138.251.0/24^24-29, 203.92.25.0/24^24-29, 203.174.26.0/24^24-29, 210.7.46.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: brenden(a)staff.inspire.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20080724 source: NZRR ------------------------------------------------------------

1 0

NZRR Route Registry Update
by NZRR Database Notifications 23 Jul '08

23 Jul '08

Dear Colleague, This is to notify you that one or more objects in which you are designated for notification have been modified in the NZRR routing registry database. 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. Diagnostic output: ------------------------------------------------------------ --- PREVIOUS OBJECT: route-set: AS9439:RS-ROUTES:AS17705 descr: advertised to AS9439 by InspireNet - AS17705 members: 203.114.128.0/18^18-29, 121.79.192.0/19^19-29, 192.138.251.0/24^24-29, 203.92.25.0/24^24-29, 210.7.46.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: brenden(a)staff.inspire.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20080410 source: NZRR REPLACED BY: route-set: AS9439:RS-ROUTES:AS17705 descr: advertised to AS9439 by InspireNet - AS17705 members: 203.114.128.0/18^18-29, 121.79.192.0/19^19-29, 140.200.248.0/22^22-29, 192.138.251.0/24^24-29, 203.92.25.0/24^24-29, 203.174.26.0/24^24-29, 210.7.46.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: brenden(a)staff.inspire.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20080724 source: NZRR ------------------------------------------------------------

1 0

NZRR Route Registry Update
by NZRR Database Notifications 23 Jul '08

23 Jul '08

Dear Colleague, This is to notify you that one or more objects in which you are designated for notification have been modified in the NZRR routing registry database. 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. Diagnostic output: ------------------------------------------------------------ --- 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, 166.65.0.0/16^16-29, 119.15.0.0/19^19-29, 202.53.176.0/20^20-29, 202.191.32.0/20^20-29, 210.48.160.0/20^20-29, 120.89.80.0/21^21-29, 192.173.16.0/21^21-29, 202.46.176.0/21^21-29, 202.49.0.0/21^21-29, 202.78.240.0/21^21-29, 203.190.208.0/21^21-29, 202.37.48.0/22^22-29, 202.89.4.0/22^22-29, 202.160.116.0/22^22-29, 202.124.106.0/23^23-29, 202.160.114.0/23^23-29, 192.88.85.0/24^24-29, 192.122.171.0/24^24-29, 192.133.31.0/24^24-29, 192.195.219.0/24^24-29, 202.20.97.0/24^24-29, 202.36.33.0/24^24-29, 202.36.119.0/24^24-29, 202.36.162.0/24^24-29, 202.36.218.0/24^24-29, 202.46.190.0/24^24-29, 202.49.106.0/24^24-29, 202.50.247.0/24^24-29, 202.55.105.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: service(a)fx.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20080619 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, 166.65.0.0/16^16-29, 119.15.0.0/19^19-29, 202.53.176.0/20^20-29, 202.191.32.0/20^20-29, 210.48.160.0/20^20-29, 120.89.80.0/21^21-29, 192.173.16.0/21^21-29, 202.46.176.0/21^21-29, 202.49.0.0/21^21-29, 202.78.240.0/21^21-29, 203.190.208.0/21^21-29, 202.37.48.0/22^22-29, 202.89.4.0/22^22-29, 202.160.116.0/22^22-29, 202.124.106.0/23^23-29, 202.160.114.0/23^23-29, 192.88.85.0/24^24-29, 192.122.171.0/24^24-29, 192.133.31.0/24^24-29, 192.195.219.0/24^24-29, 198.32.71.0/24^24-29, 202.20.97.0/24^24-29, 202.36.33.0/24^24-29, 202.36.119.0/24^24-29, 202.36.162.0/24^24-29, 202.36.218.0/24^24-29, 202.46.190.0/24^24-29, 202.49.106.0/24^24-29, 202.50.247.0/24^24-29, 202.55.105.0/24^24-29, 203.119.56.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)fx.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20080724 source: NZRR ------------------------------------------------------------

1 0

NZRR Route Registry Update
by NZRR Database Notifications 23 Jul '08

23 Jul '08

Dear Colleague, This is to notify you that one or more objects in which you are designated for notification have been modified in the NZRR routing registry database. 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. Diagnostic output: ------------------------------------------------------------ --- 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, 166.65.0.0/16^16-29, 119.15.0.0/19^19-29, 202.53.176.0/20^20-29, 202.191.32.0/20^20-29, 210.48.160.0/20^20-29, 120.89.80.0/21^21-29, 192.173.16.0/21^21-29, 202.46.176.0/21^21-29, 202.49.0.0/21^21-29, 202.78.240.0/21^21-29, 203.190.208.0/21^21-29, 202.37.48.0/22^22-29, 202.89.4.0/22^22-29, 202.160.116.0/22^22-29, 202.124.106.0/23^23-29, 202.160.114.0/23^23-29, 192.88.85.0/24^24-29, 192.122.171.0/24^24-29, 192.133.31.0/24^24-29, 192.195.219.0/24^24-29, 202.20.97.0/24^24-29, 202.36.33.0/24^24-29, 202.36.119.0/24^24-29, 202.36.162.0/24^24-29, 202.36.218.0/24^24-29, 202.46.190.0/24^24-29, 202.49.106.0/24^24-29, 202.50.247.0/24^24-29, 202.55.105.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: service(a)fx.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20080619 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, 166.65.0.0/16^16-29, 119.15.0.0/19^19-29, 202.53.176.0/20^20-29, 202.191.32.0/20^20-29, 210.48.160.0/20^20-29, 120.89.80.0/21^21-29, 192.173.16.0/21^21-29, 202.46.176.0/21^21-29, 202.49.0.0/21^21-29, 202.78.240.0/21^21-29, 203.190.208.0/21^21-29, 202.37.48.0/22^22-29, 202.89.4.0/22^22-29, 202.160.116.0/22^22-29, 202.124.106.0/23^23-29, 202.160.114.0/23^23-29, 192.88.85.0/24^24-29, 192.122.171.0/24^24-29, 192.133.31.0/24^24-29, 192.195.219.0/24^24-29, 198.32.71.0/24^24-29, 202.20.97.0/24^24-29, 202.36.33.0/24^24-29, 202.36.119.0/24^24-29, 202.36.162.0/24^24-29, 202.36.218.0/24^24-29, 202.46.190.0/24^24-29, 202.49.106.0/24^24-29, 202.50.247.0/24^24-29, 202.55.105.0/24^24-29, 203.119.56.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)fx.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20080724 source: NZRR ------------------------------------------------------------

1 0

Rule 6... part 2.
by Steve Holdoway 21 Jul '08

21 Jul '08

Apologies to those who didn't get the Monty Python reference ( there is no rule 6, after all! ), I'll take the general census as an ok, and hope this isn't too off-list. I'm working for a company down here in Christchurch who are developing a new tool aimed at catching email spam. Much simplified, it uses linear regression techniques to create a signature of the email involved, and then performs a fuzzy match on that sig against databases held on our servers ( via a local cache to improve performance ). We reckon we've got it to be pretty indestructible ( and with a pretty small footprint ), but we need to test it further. Are there any ISP's out there who could help us out by a) trialling it ( our testing up to now has been as a milter under sendmail/postfix on linux ), and/or b) sending us loads of spam to stress our backend processes?? If so, could they contact me offlist? Cheers and thanks, Steve

1 0

Re: [nznog] DNS Vulnerability
by Ewen McNeill 21 Jul '08

21 Jul '08

In message <20080708234533.B080B112872(a)wat.la.naos.co.nz>, Ewen McNeill writes: >See also, eg, http://isc.sans.org/diary.html?storyid=4687 which has some >sane discussion of the issue [...] It appears that someone guessed close enough to how the attack worked to cause one of the people "in the know" to post a confirmation, and then attempt to withdraw it -- but of course people have found traces of the confirmation description and mirrored it. So the cat seems to be out of the bag, and presumably the Bad Guys (tm) will now try to do this for real. See, eg, http://it.slashdot.org/it/08/07/21/2212227.shtml which has various cut'n'paste copies of what seems to be the confirmation description, plus a link to the guess that prompted it. >Amongst other things they suggest patching any recursive/caching DNS >servers with vendor patches at the soonest suitable patch window. If you haven't already patched your recursive/caching DNS servers used by customers, today would be a good day to do it. So says Dan Kaminsky who found the issue in the first place: http://www.doxpara.com/?p=1176 Also beware that the NAT in at least some firewalls has been reported to undo the port randomisation that the patch introduces, resulting in predictable port numbers again (and thus no increase in randomness or protection against this attack). Linux-based firewalls are reported to be okay (apparently by default they pass through the port number used by the client on outgoing UDP packets if they can), and presumably OpenBSD based ones are okay given their choice to randomise everything. But beware of running recursive DNS servers behind NAT on firewalls without checking what the outgoing packets look like -- if in doubt perhaps put your recursive DNS servers into the DMZ outside the NAT. Ewen

1 0

Rule 6.
by Steve Holdoway 20 Jul '08

20 Jul '08

... which in this case isn't 'No pommy poofters' (: Is is appropriate to post a request for partners to trial software, or is this a breach of the aforesaid rule??? Cheers, Steve

3 2

Compromised websites
by Glen Eustace 14 Jul '08

14 Jul '08

Hi, We have had only a single site compromised so far but googling around indicates that this particular hack is all over the place. On the site in question all files .htm, .html and .shtml have had code added before the </body> tag, the code is a <jscript></jscript> that loads fgg.js from http://www.usaadw.com, the script that is loaded then tries to open an iframe but the content gives a 500 server error. I can not identify the vector used to edit all the files. This is on a linux server running apache 2 but google finds plenty of .asp pages that have been attached as well. The script is also called ngg.js but has almost identical content. Has anyone else been hit and if so, has the vector been identified ? Any assistance appreciated. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Glen and Rosanne Eustace GodZone Internet Services, a division of AGRE Enterprises Ltd. P.O. Box 8020, Palmerston North, New Zealand 4446. Ph: +64 6 357 8168, Fax +64 6 357 8165, Mob: +64 21 424 015 http://www.godzone.net.nz "A Ministry specialising in providing low-cost Internet Services to NZ Christian Churches, Ministries and Organisations."

7 12

Re: [nznog] Compromised websites
by Gary T. Benner 14 Jul '08

14 Jul '08

[Reply] HI all, We use "denyhosts" as well to monitor attempts to break into SSH ports, and are getting on average 50 per day over 20 servers. Interesting that it is "real" regular! Weekends even. cheers Gary 123 Internet Ltd At 10:09 on 15/07/2008 you wrote >To : NZNOG(a)list.waikato.ac.nz >CC : >From: Steve Holdoway, steve(a)greengecko.co.nz >Content Type: text/plain >Attached: att-080715100913828-2.txt > > > > >On Tue, 15 Jul 2008 08:34:17 +1200 >Steve Holdoway <steve(a)greengecko.co.nz> wrote: > >> I don't, but I run logcheck to *tell* me ( and fcheck to tell me of any file changes, and... )! tbh my production servers have a backdoor single account ssh access to the internet, which is protected by denyhosts, and all other access is from a staging server via vpn, still using secure ( but separate ) protocols. I don't care too much about the shortcomings of denyhosts, as a) it's protecting the emergency backup service, and b) I've got enough static ip addresses whitelisted to get in from - imo it's perfect for this job. >> >> OK, you *could* break in through a distributed attack on the ssh port, but the real risk to my servers is now human, from those with the relevant knowledge of the network configuration. But to me the chances of someone looking for a starting point 9000 miles from the server, breaking in, then going through a few other hoops before hacking across the vpn to the production server is remote enough to put a long way down my list. >> >> And, of course, I'm lucky enough not to have to support 1903 vintage IBM boat anchors (: >> >> >> Steve >> >Just to follow this up from this morning... > >>From Logcheck... >Jul 15 07:16:54 server sshd[8129]: Failed password for invalid user hipcomix from 207.210.107.2 port 34553 ssh2 >Jul 15 07:16:54 server sshd[8132]: Failed password for root from 207.210.107.2 port 34566 ssh2 >Jul 15 07:16:55 server sshd[8134]: Failed password for invalid user jpeger from 207.210.107.2 port 34582 ssh2 >Jul 15 07:16:55 server sshd[8139]: Failed password for invalid user favs from 207.210.107.2 port 34606 ssh2 >and a few more... > >>From Denyhosts... >Date: Tue, 15 Jul 2008 07:17:00 +1200 > >Added the following hosts to /etc/hosts.deny: > >207.210.107.2 (unknown) > > >Steve > > >_______________________________________________ >NZNOG mailing list >NZNOG(a)list.waikato.ac.nz >http://list.waikato.ac.nz/mailman/listinfo/nznog Ref#: 41006

1 0

Re: [nznog] Compromised websites
by Scott Weeks 14 Jul '08

14 Jul '08

------- criggie(a)criggie.dyndns.org wrote: ------------ From: Criggie <criggie(a)criggie.dyndns.org> And if you're not watching/analyzing your logs, its very easy to miss someone trying passwords. <snip> Who's going to notice an extra 400 bytes/sec on a busy link, other than by monitoring logs for denied requests? -------------------------------------------------------- Depending on which program you use, you can set a max number of attempts by clients on the FTP server. scott

1 0

Kiwicon CFP 2k8 - Update
by Simon Howard 09 Jul '08

09 Jul '08

-----------------------------------------------------------------------] _.-.. __ .__ .__ ,'9 )\)`-.,.--. | | _|__|_ _ _|__| ____ ____ ____ 2k8 `-.| `. | |/ / \ \/ \/ / |/ ___\/ _ \ / \ \, , \) | <| |\ /| \ \__( <_> ) | \ `. )._\ (\ |__|_ \__| \/\_/ |__|\___ >____/|___| / |// `-,// \/ \/ \/ ]|| //" "" "" BAAAAAAaaaa!!11 [-------------------------------------------------- www.kiwicon.org----] Holy sheepshit, internets! Blanket-Man[1] has wrung out his loin cloth and is ready to fly-tackle more nerds with large egos and irc handles. Yes, it's time to open up your ~/haxing folder and get your talk together for Kiwicon 2k8! We've put out the black t-shirts, and deflated some satellite radomes, so where, as our more criminal yet fetchingly bikini clad cousins might say, the bloody hell are you? The Kiwicon Crüe is proud to announce the call for presenters for the second installment of New Zealand's very own security conference: Kiwicon 2k8. [CFP Update] Despite being a community con, Kiwicon is now pleased, if not delighted to the point of gratuitous Morris dancing to be able to offer financial support for travel to a limited number of speakers. More details are available in the Submission section below. We've already had a number of great talks submitted, and slots are filling fast. Those of you attending cons this year will already be aware of the number of Kiwis presenting - AusCERT, Shakacon, Syscan, Blackhat, Defcon, Ruxcon - you should see these guys in their natural habitat. They drop more 0day, wear tighter pants, and are 30% more likely to coyly flutter their eyelashes at you. [About] Kiwicon2k8 is intended to be an informal conference, drawing on the wider security community of Australia and New Zealand. It will be held in Wellington, New Zealand, on the weekend of the 27th and 28th of September, 2008. Kiwicon's focus is on sharing information; ideas, code, and good whisky, in a rabelaisan carnival of security, nerdery, and *nix beards. Last year, the inaugural Kiwicon ended up being kind of a big deal: highlights included tmasky's mighty Crackstation, the debut of Beau Butler as an "ethical hacker" making Microsoft "look like turkeys", and of course the Kiwicon Hax0r Quiz, with the winner taking the grand prize of An Illustrated Guide to the Commoner Skin Diseases. Hope it came in handy for the post-con diagnosis phase, dude. This year, Kiwicon's own Bogan is already making anti-virus vendors quake in their little signature-laden booties at Defcon's Race to Zero, and the cauldron of 0h-0h-0hday in Brett Moore's secret Insomnia lair is bubbling over with pernicious brew. If you missed last Kiwicon (not "professional enough"? couldn't convince your boss it wasn't a hoax?) then find one of the 230+ people who were there and ask them if they're just-not-gonna-bother this year. [Venue] Our hosts for the weekend will, once again, be Victoria University of Wellington. If you have any memory of last year's Kiwicon, then it'll look disturbingly familiar. The campus has the advantage of being close to the center of the city and its' various amenities. This includes cheap accommodation, good coffee, and, more importantly, several good pubs serving good, non-Australian, beer. [Costs] Kiwicon2k8 is a non-profit, non-commercial, non-corporate-funded event. Attendance for the entire weekend will cost $50 for employed individuals (self-employed and salaried). There is a discounted rate of $30 for students and the unemployed. GST receipts can be issued upon request. If your management can't be convinced of the value of something that only costs $50, we're happy to issue you with some kind of personalised limited edition invitation in crayon, glitter pen, and macaroni (spray-painted gold for that luxe look) for the low enterprise-only price of $500. [Topics] Suggested topics include but are not limited to: - Crowd Control Techniques and Panic Modeling - Information Warfare / Industrial Espionage - Malware (Viruses, Spam, Phishing, Botnets) - Cellular Networks (GSM,GPRS,CDMA,3G,4G) - Application Security, Testing, Fuzzing - Government Spy Networks / Surveillance - Nanotechnology / Quantum Computing - Access Control and Authentication - Wireless / Bluetooth / Infrared - Social Engineering / Trolling - Breaking EAL Certified Kit - Forensics / Antiforensics - Banking / ATMs / Carding - Exploitation Techniques - Layer 1/2/3 Nastiness - Reverse Engineering - Phreaking / VoIP - Virtualisation - Web Security - Lockpicking - Biometrics - Hypnosis - Crypto - Ohday - 23 There is no pre-determined talk length but we ask that speakers limit their presentation to an hour, including some question time. Kiwicon is a non-profit organisation, so generally funding is not available for travel and accommodation. However, we have a limited number of travel support packages available: 1 x NZ$1500 for a speaker from outside Australasia or the South Pacific 1 x NZ$750 for a speaker from Australia or the South Pacific 3 x NZ$250 for speakers from New Zealand These are available only to full length (>45min) speakers paying their own way. No speaking-in-a-corporate-capacity, no company logos on the slides and no industry weaseling. These stipends are for amateurs, crackpots, ecclesiasticals, students and other miserable doss-down-under-the-motorway-bridge-oh-my-goodness-two-cardboard-boxes-just-for-me? riff-raff. If you look too much like you should be hanging out between the pages of Men's Style magazine (and we know who you are), then we reserve the right to pick someone a trifle more threadbare. Organiser decision is final, no correspondence will be corresponded, and Sharrow has to think your existence does not constitute a putrefying abscess in the nostril of humanity. If you are a corporate sellout, however, a formal letter will be provided for employer leverage. Either way, unless you're a complete jackoff, people will try and buy you beer. To submit a presentation to Kiwicon2k8, send an email to cfp(a)kiwicon.org with the following information: Name or Handle: Country of Residence: Employer (if applicable): Presentation Title: Presentation Length: Presentation Synopsis: Brief Bio: Do Want Fat Cash: [Yes/No] ( If yes, pick one of the above support options, and explain how poor you are, and why you're worth spending our money on. Be creative. Poetry is acceptable? ) [CFP Submissions] Please submit your CFP by email to cfp(a)kiwicon.org, no later than 8:47pm NZST, Sunday 17th August 2008. There will be two rounds of selection, with the first half of the talks chosen in early August, so submit early for a better chance of acceptance. [Contacts & Further Information] Email us: kiwicon(a)kiwicon.org Check the site: http://www.kiwicon.org/ Drop by silc: silc.isig.org.nz:2706/kiwicon Join the list: kiwicon-subscribe(a)lists.isig.org.nz Greetz and thanks to all who helped make Kiwicon 2k7 the awesomeness it was, we'll see you fuckers again this year. Thick, meaty props to Pipes for stepping up and making 2k7 happen. We would miss you, but Sharrow's just as tall, and better looking. Sorry pal. -- The Kiwicon Crüe, 2k8 - Bogan, Metlstorm & Sharrow. \m/ [1] http://en.wikipedia.org/wiki/Ben_Hana

1 0

Dunedin Frequency 5735
by Dan Clark 08 Jul '08

08 Jul '08

Gidday Guys, anyone got anything new on 5735GHz in and around Dunedin CBD last 24 hours? Regards Dan Clark

10 11

DNS Vulnerability
by Jamie Baddeley 08 Jul '08

08 Jul '08

Vulnerability Summary: Deficiencies in the DNS protocol and common DNS implementations facilitate a DNS cache poisoning attack that affects BIND, Microsoft Windows DNS services and CISCO IOS. The vulnerability has been assigned the following Common Vulnerability and Exposure number: CVE-2008-1447 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1447 Note: Authorative name servers are not affected. Impact criticality: CCIP assess the impact of this vulnerability to be VERY HIGH. CCIP is unaware of any active exploit code for this vulnerability. Type of fix available: Microsoft has released a patch for this in their latest updates. More information can be found at http://www.microsoft.com/technet/security/bulletin/MS07-062.mspx. CCIP understands that other vendors will be releasing updates shortly. BIND have released a notification which is located at http://www.isc.org/index.pl?/sw/bind/index.php CISCO have also released a notification which can be accessed at http://www.cisco.com/warp/public/707/cisco-sa-20080708-dns.shtml

2 1

Re: [nznog] DNS Vulnerability
by Ewen McNeill 08 Jul '08

08 Jul '08

In message <1215550691.3987.44.camel(a)titan>, Jamie Baddeley writes: >Vulnerability Summary: >Deficiencies in the DNS protocol and common DNS implementations >facilitate a DNS cache poisoning attack that affects BIND, Microsoft >Windows DNS services and CISCO IOS. See also, eg, http://isc.sans.org/diary.html?storyid=4687 which has some sane discussion of the issue (which basically seems to boil down to insufficient randomness in queries allowing spoofed replies, given the lack of any actual properly deployed security in DNS). Amongst other things they suggest patching any recursive/caching DNS servers with vendor patches at the soonest suitable patch window. The priority for patching other things depends on their reliance on DNS and protection gained from other DNS servers -- for instance things which only rely on DNS to look up internal management network names from a DNS server which is already patched are probably a much lower priority than the recursive DNS servers for your customers. (And while, eg, Cisco have a patch out for IOS, I'd imagine most routers/switches are not configured to offer recursive DNS or otherwise using the DNS functionality in IOS in a way that puts them at much risk.) Also for recursive DNS servers for customers see the note at the end of the isc.sans.org page (link above) about a beta version of BIND9 with performance improvements for high query load recursive servers. Ewen

1 0

APRICOT 2009: Call for Papers
by Gaurab Raj Upadhaya 02 Jul '08

02 Jul '08

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Asia Pacific Regional Internet Conference on Operational Technologies (APRICOT) 18-27 February 2009, Manila, Philippines http://www.apricot2009.net Call for Papers The APRICOT 2009 Program Committee is now seeking contributions for Presentations and Tutorials for APRICOT 2009. Full CFP available at : http://www.apricot2009.net Please submit proposals online at http://submission.apricot.net/paper/user/login.php?event=13 CONFERENCE MILESTONES - --------------------- Call for Papers Opens: 1 July 2008 Deadline for Speaker Submissions: 30 September 2008 First Draft Program Published: 15 October 2008 Final Program Published: 15 December 2009 Final Slides Received: 15 January 2009 Additional Information ______________________ APRICOT Program will be organized in three parts, including workshops, tutorials and the conference. APNIC Policy SIG and Annual Members Meeting will be held subsequently. Topics for tutorials and conference would include amongst others relevant to Internet Operations and Technologies: Draft slides for both tutorials and conference sessions MUST be provided with CfP submissions. APRICOT is a TECHNICAL conference so marketing and commercial content is not allowed within the program. Speakers from developing countries may be eligible for the APRICOT Fellowship Program. More information on the APRICOT Fellowship program can be found at the APRICOT 2009 website at http://www.apricot2009.net/ Thanks. APRICOT Program Committee -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkhsZNIACgkQSo7fU26F3X21cgCgiTw0kXxmySOQwl4383LVHXID wPkAoKQMj28KautqgXUH5bkxqtmiUieZ =VSDe -----END PGP SIGNATURE-----

1 0

NZRR Route Registry Update
by NZRR Database Notifications 02 Jul '08

02 Jul '08

Dear Colleague, This is to notify you that one or more objects in which you are designated for notification have been modified in the NZRR routing registry database. 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. Diagnostic output: ------------------------------------------------------------ --- PREVIOUS OBJECT: route-set: AS9560:RS-ROUTES:AS17746 descr: advertised to AS9560 by Orcon Internet Limited - AS17746 members: 60.234.0.0/16^16-29, 121.98.0.0/16^16-29, 156.62.0.0/16^16-29, 202.150.96.0/19^19-29, 203.99.0.0/19^19-29, 203.96.192.0/20^20-29, 219.88.128.0/20^20-29, 219.88.240.0/20^20-29, 116.199.208.0/21^21-29, 120.136.48.0/21^21-29, 210.54.56.0/21^21-29, 210.79.48.0/21^21-29, 202.127.8.0/22^22-29, 210.54.148.0/22^22-29, 210.55.12.0/22^22-29, 202.37.82.0/23^23-29, 202.175.142.0/23^23-29, 203.84.134.0/23^23-29, 192.203.216.0/24^24-29, 202.27.77.0/24^24-29, 202.36.170.0/24^24-29, 202.37.19.0/24^24-29, 202.37.173.0/24^24-29, 202.37.194.0/24^24-29, 202.49.187.0/24^24-29, 202.49.233.0/24^24-29, 202.49.246.0/24^24-29, 202.50.167.0/24^24-29, 202.50.246.0/24^24-29, 202.174.160.0/24^24-29, 203.86.200.0/24^24-29, 210.54.12.0/24^24-29, 210.55.1.0/24^24-29, 210.55.8.0/24^24-29, 210.55.199.0/24^24-29, 202.27.188.128/25^25-29, 210.55.0.0/25^25-29, 210.55.180.128/26^26-29, 210.55.193.64/27^27-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: benny.treefoot(a)team.orcon.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20080516 source: NZRR REPLACED BY: route-set: AS9560:RS-ROUTES:AS17746 descr: advertised to AS9560 by Orcon Internet Limited - AS17746 members: 60.234.0.0/16^16-29, 121.98.0.0/16^16-29, 156.62.0.0/16^16-29, 202.150.96.0/19^19-29, 203.99.0.0/19^19-29, 203.96.192.0/20^20-29, 219.88.128.0/20^20-29, 219.88.240.0/20^20-29, 116.193.144.0/21^21-29, 116.199.208.0/21^21-29, 120.136.48.0/21^21-29, 210.54.56.0/21^21-29, 210.79.48.0/21^21-29, 202.127.8.0/22^22-29, 210.54.148.0/22^22-29, 210.55.12.0/22^22-29, 202.37.82.0/23^23-29, 202.175.142.0/23^23-29, 203.84.134.0/23^23-29, 192.203.216.0/24^24-29, 202.27.77.0/24^24-29, 202.36.170.0/24^24-29, 202.37.19.0/24^24-29, 202.37.173.0/24^24-29, 202.37.194.0/24^24-29, 202.49.187.0/24^24-29, 202.49.233.0/24^24-29, 202.49.246.0/24^24-29, 202.50.167.0/24^24-29, 202.50.246.0/24^24-29, 202.174.160.0/24^24-29, 203.86.200.0/24^24-29, 210.54.12.0/24^24-29, 210.55.1.0/24^24-29, 210.55.8.0/24^24-29, 210.55.199.0/24^24-29, 202.27.188.128/25^25-29, 210.55.0.0/25^25-29, 210.55.180.128/26^26-29, 210.55.193.64/27^27-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: benny.treefoot(a)team.orcon.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20080703 source: NZRR ------------------------------------------------------------

1 0

Re: [nznog] Vector, did you try turning it off and then on again
by Bill Walker 02 Jul '08

02 Jul '08

Thats the best reply so far. We have just proposed triple redundancy to a customer. Fibre wireless and satellite the ongoing costs aren't too bad it's the setup costs that are a killer. 10 mbp satellite gear isn't cheap. If you've got the money it's the way to go. .... Bill Walker Sent from my phone. -----Original Message----- From: "John Russell" <jsr(a)jsr.com> To: "NZNOG" <nznog(a)list.waikato.ac.nz> Sent: 1/07/2008 11:41 p.m. Subject: Re: [nznog] Vector, did you try turning it off and then on again On [Various Times], [Many People Wrote] wrote: > [Words] A 9 hour outage seems long, but it's hardly absurd. Though we haven't seen a cause report from Vector yet, if it was spade fade, 9 hours is pretty good. I wasn't on call when it broke, but my colleague who was tells me he was told "Hardware Failure" was the problem. If something like a 6509 plane died, I can see how you might hit 9 hrs: The thing faults, alarms go off, customers call, the on-duty tech at Vector has to do some basic diagnosis, wave his hands in the air and run around like a monkey for a bit, call the on-call call engineer. Then that engineer has to wake up and/or finish his beer and get home from the pub, then do some more diagnostics, see the dead module and then do that thing where you put your hands flat on your forehead and drag them down your face while going "Gahhhhh". Then he gets to go pull a spare from stores, or call Cisco for a part and then THEY get to kick off THEIR internal process to get the thing to you. Then there's truck time to the site, waiting for an elevator to L48 of the sky tower that isn't already full of tourists in orange jumpsuits ready to jump off and/or carts full of crab canapes, swaping out the dead unit, sanity checking the restored services and making config changes if required, etc. And all that is just if everything does go to plan, and you don't find out that your spare hardware is in the lab, and the lab is locked and the guy who has the key has gone fishing, or that Cisco have already given their only spare WS-X6516 to someone else, and so on and so on. So, anyway, thing is, 9hrs, sure. However it really shouldn't matter that much. The ISP network I am currently fussing over, for example, has vector connectivity to the Sky Tower, which carries APE and some other stuff. This all broke when Vector went down. Domestic traffic, however, simply switched over to other peering links, as it should because it is, you know, The Internet. Some Vector-only stuff broke, of course, but core services just failed over and carried on. If your network connection is absolutely critical for your business, and it's wholly dependent on one vendor, you should perhaps rethink your approach. Talk to your ISP, explain that you need redundancy in your connection. Chuck in something like a DSL connection beside that Vector link. Ask your ISP about sourcing you a router than can connect to both, and setting up BGP or MPLS-based failover to your secondary link in the event that your Vector link fails. Now your connection is vendor independent (if not ISP-independent - if they fail, you fail. Try to pick an ISP that Does Not Fail Much). If you can't get DSL, ask your ISP about Wireless or IPStar or something similar. If you can fail from optical to satellite, that's pretty good diversity. And it's not complicated to do. You may not get the same performance, of course, but you'll have _a_ connection, which is better than _no_ connection, especially if it's only for a short time. This setup won't, of course, solve the problem of a local power cut killing your Vector link. I'm not even certain why we're discussing that. Talk to Vector and your electrician to get a cable run from your generator and/or UPS-backed distribution board to wherever your building vector switch is. Plug the switch into it. And you're done. It's a one-off cost, and likely not a large one. Even without a UPS, the worst that can happen is that the switch powers down when the cut takes place, then boots back up when your generator starts. A few minutes, tops. If you _don't have_ a generator, and your building power is out, I guess you'll be sitting in the dark, looking at your blank screen, and won't care if your internet connection is down. This is a perfect opportunity to go to the pub, and have a drink with the Vector engineer. Assuming he's awake. JSR -- John S Russell Big Geek. Doing Geek Stuff. _______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog No virus found in this incoming message. Checked by AVG. Version: 8.0.101 / Virus Database: 270.4.3/1526 - Release Date: 30/06/2008 8:43 a.m.

5 5

NZRR Route Registry Update
by NZRR Database Notifications 01 Jul '08

01 Jul '08

Dear Colleague, This is to notify you that one or more objects in which you are designated for notification have been modified in the NZRR routing registry database. 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. Diagnostic output: ------------------------------------------------------------ --- PREVIOUS OBJECT: route-set: AS9439:RS-ROUTES:AS9245 descr: advertised to AS9439 by Compass Communications - AS9245 members: 203.152.96.0/19^19-29, 203.96.0.0/20^20-29, 203.96.32.0/20^20-29, 117.104.176.0/21^21-29, 123.108.144.0/21^21-29, 116.90.132.0/24^24-29, 202.36.121.0/24^24-29, 202.36.157.0/24^24-29, 202.37.112.0/24^24-29, 202.37.234.0/24^24-29, 203.30.174.0/24^24-29, 203.171.4.0/24^24-29, 203.97.62.200/29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: davey.goode(a)compass.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20080213 source: NZRR REPLACED BY: route-set: AS9439:RS-ROUTES:AS9245 descr: advertised to AS9439 by COMPASS NZ - AS9245 members: 203.152.96.0/19^19-29, 203.96.0.0/20^20-29, 203.96.32.0/20^20-29, 117.104.176.0/21^21-29, 120.136.0.0/21^21-29, 123.108.144.0/21^21-29, 116.90.128.0/23^23-29, 116.90.132.0/23^23-29, 202.174.6.0/23^23-29, 116.90.131.0/24^24-29, 202.36.157.0/24^24-29, 202.37.112.0/24^24-29, 202.37.234.0/24^24-29, 203.30.174.0/24^24-29, 203.171.4.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: davey.goode(a)compass.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20080702 source: NZRR ------------------------------------------------------------

1 0

NZRR Route Registry Update
by NZRR Database Notifications 01 Jul '08

01 Jul '08

Dear Colleague, This is to notify you that one or more objects in which you are designated for notification have been modified in the NZRR routing registry database. 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. Diagnostic output: ------------------------------------------------------------ --- PREVIOUS OBJECT: route-set: AS9560:RS-ROUTES:AS9245 descr: advertised to AS9560 by Compass Communications - AS9245 members: 203.152.96.0/19^19-29, 203.96.0.0/20^20-29, 203.96.32.0/20^20-29, 117.104.176.0/21^21-29, 123.108.144.0/21^21-29, 116.90.132.0/24^24-29, 202.36.121.0/24^24-29, 202.36.157.0/24^24-29, 202.37.112.0/24^24-29, 202.37.234.0/24^24-29, 203.30.174.0/24^24-29, 203.171.4.0/24^24-29, 203.97.62.200/29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: davey.goode(a)compass.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20080213 source: NZRR REPLACED BY: route-set: AS9560:RS-ROUTES:AS9245 descr: advertised to AS9560 by COMPASS NZ - AS9245 members: 203.152.96.0/19^19-29, 203.96.0.0/20^20-29, 203.96.32.0/20^20-29, 117.104.176.0/21^21-29, 120.136.0.0/21^21-29, 123.108.144.0/21^21-29, 202.174.6.0/23^23-29, 202.36.157.0/24^24-29, 202.37.112.0/24^24-29, 202.37.234.0/24^24-29, 203.30.174.0/24^24-29, 203.171.4.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: davey.goode(a)compass.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20080702 source: NZRR ------------------------------------------------------------

1 0

Re: [nznog] Vector, did you try turning it off and then on again
by Matthew Poole 30 Jun '08

30 Jun '08

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Richard Naylor wrote: | OK MAN CPEs are tricky. A cheap UPS is useless. The line interactive | type do let thru spikes and surges and if your CPE device has a cheap | switching PSU it will often lock up, die, or do nasty things. So to get | a decent UPS (ie rectifier followed by inverter) you need to spend over | $1k. | And given that Vector were using, at the time, Cisco 29xxG's (I think. Pretty sure they were just dumb L2 switches) for CPE, a $1k UPS would almost double the equipment cost per install. That's not inconsiderable. | Then you have batteries and maintenance. A typical power company (I used Which was really my point. Keeping a lot (and it'll number in the hundreds for Vector) of UPS's up and running isn't a trivial ask. The cost would be phenomenal, and every time batteries need to be changed it's an outage for the CPE that's on the end of it. *SNIP* | If you want to help your MAN supplier deliver a better performance and | you run a nice UPS, then offer to give them some of your 230V off your | UPS. Then you know that they have power at your end. And if you have a | diesel as well....... | | Its a nice cheap solution, and you know the performance of their backup. | Yeah, I think that was kind of what Vector were hoping for. But a lot of their terminating switches are buried in basement rooms to which only the building manager has a key. I know that we had quite a few instances of banging heads on walls trying to get access to put our kit in with Vector's, because the keys to the appropriate room were hard to locate. - -- Matthew Poole "Don't use force. Get a bigger hammer." -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIaWaWTdEtTmUCdpwRAvxSAKDIVU4tPqlHaZxpDSbZkk5s6XfwXgCeP99z rgL579ASX+9AcBjhAlgC56g= =sQy1 -----END PGP SIGNATURE-----

17 21

Re: [nznog] Vector, did you try turning it off and then on again
by Richard Naylor 30 Jun '08

30 Jun '08

At 01:15 p.m. 30/06/2008, Pshem Kowalczyk wrote: <snip> >Updates 4h into the problem saying - no ETA and about 2h later - it >will be fixed tomorrow are just not enough. The fact that it was >virtually impossible to get hold of anyone that actually had a clue is >not something that an average business is willing to accept. If a network connection is that important to the "average" business, then it should do something about it. What worries me is that people on this list think that a network operator should be infallible. If the Internet is that important to your business, then have more than one provider. If you have clue, you'll use one with a different layer 3, 2, 1, or maybe even 0 route topology. Its far simpler to have multiple providers and networks than paying a fortune to have some undeliverable level of reliability. And besides *you* have control over it. My business relies heavily on the Internet. We use 5 providers for our network and around 5 for the services. We mix dsl with wireless (3 forms), we have 4 satellite links, fiber and are known to run our own cable when we can't get what we want where we want it. A Km or two is no real issue. If a company uses a UPS for its computer, why doesn't it invest in a second link. Even crappy dsl will at least keep something going. Rich

5 7

Upcoming APNIC policy implementations
by Elly Tawhai 30 Jun '08

30 Jun '08

________________________________________________________________________ Upcoming APNIC policy implementations ________________________________________________________________________ On 4 August 2008, APNIC will implement two policy proposals that reached consensus at the APNIC 25 Policy SIG in Taipei, Taiwan in February 2008. The APNIC Executive Council (EC) endorsed the proposals during their May 2008 meeting. The two policy changes are: - Changing the minimum IPv4 allocation size to /22 This change will make it easier for small ISPs to receive direct allocations from APNIC. - Adding an alternative IPv6 initial allocation criteria This change will make it easier for more ISPs to receive IPv6 allocations from APNIC by enabling current LIRs with IPv4 allocations to receive IPv6 initial allocations without a plan for making 200 assignments. To view the history of these policy proposals, see: prop-053: Changing minimum IPv4 allocation size to /22 http://www.apnic.net/policy/proposals/prop-053-v003.html prop-057: Proposal to change IPv6 initial allocation criteria http://www.apnic.net/policy/proposals/prop-057-v002.html Kind regards, Elly ________________________________________________________________________ Elly Tawhai email: hostmaster(a)apnic.net Senior Internet Resource Analyst, APNIC sip: hostmaster(a)voip.apnic.net http://www.apnic.net/helpdesk phone: +61 7 3858 3188 fax: +61 7 3858 3199 ________________________________________________________________________ Hope to see you at APNIC 26 in Christchurch, New Zealand 25 - 29 August 2008 http://www.apnic.net/meetings/26/

1 0

ICANN New TLD's
by Chris Hodgetts 30 Jun '08

30 Jun '08

No one here has commented, (Unless my mail filter rules are a little broken at the moment) What are peoples thoughts?

3 2

The New Zealand Network Operators' Group
by Donald Neal 30 Jun '08

30 Jun '08

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. The group is intended to facilitate discussion among operators of networks in New Zealand on matters relevant to network operators as described in the list's Acceptable Use Policy. That policy appears later in this posting. Conference We hold New Zealand's only technical networking conference. See http://www.nznog.org/?page_id=4 for details of conferences from 2004 to 2008. Work is now under way in preparation for the next conference, to be held in the North Island in the last week of January 2009. Other Meetings See http://thursdaynightcurry.com/ if you live in or near Auckland or Wellington (or Hamilton?) Operators' Contact List See http://www.nznog.org/?page_id=6 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. About This Mailing List This list has between 900 and 1000 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 APN Online, Citylink, and The University of Waikato. 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 -- Donald Neal | "Careful design and strict discipline are Research Officer | necessary to prevent this sort of mess WAND | from escaping the development laboratory The University of Waikato | and infesting the production environment." | - D. Russell

1 0

Re: [nznog] Vector, did you try turning it off and then on again
by jamie baddeley 30 Jun '08

30 Jun '08

I'm with Richard here on getting in touch with reality. I always like to quote a report written by the Yankee Group. Yeah I know reports like these written by these professional 'opinionators' at are questionable at best, but one of the things they quantify which is interesting to me is a 31% attribution to human error. I'll give them the benefit of the doubt. http://www.cisco.com/warp/public/437/services/rt59/documents/yankee_report.… The reason why that is significant is the only way you'll get over that is institutional diversity. Change the associated humans and you'll avoid a 31% contributor to the cause of your potential downtime in your future. Not to mention all the other causes. I've had this argument before. http://list.waikato.ac.nz/pipermail/nznog/2005-June/010170.html Another point of reference I have is a conversation with someone involved with APNIC (previously was with Telstra) back in '99 who had the view the boils down to this: "Why does a telco waste money on making their network 5 nines, when they'll never practically realise that? Why does a customer spend money on that? Why doesn't a customer spend money of parallel sourcing 2 x '3 nines' networks and combining that together with the knowledge that they'll actually truly realise a 5 nines solution?" Now of course the customer being able to achieve that is dependent on their own internal reliability, but you're all at 5 nines availability yourselves right guys? Course you are. Silly me. That's why there's been little noise. Now, back on topic. The failure over the weekend was I presume not due to operator error. But if you've developed a strategy to deal with operator error, you've probably also dealt with an outage that is a little bit longer than normal. And in that case you're probably feeling cool right now. Otherwise you're a little hot under the collar. Nevermind, lesson learnt. Jamie -----Original Message----- From: Richard Naylor [mailto:richard.naylor(a)r2.co.nz] Sent: Monday, 30 June 2008 6:34 p.m. To: Pshem Kowalczyk; Chris Hodgetts Cc: nznog(a)list.waikato.ac.nz Subject: Re: [nznog] Vector, did you try turning it off and then on again At 01:15 p.m. 30/06/2008, Pshem Kowalczyk wrote: <snip> >Updates 4h into the problem saying - no ETA and about 2h later - it >will be fixed tomorrow are just not enough. The fact that it was >virtually impossible to get hold of anyone that actually had a clue is >not something that an average business is willing to accept. If a network connection is that important to the "average" business, then it should do something about it. What worries me is that people on this list think that a network operator should be infallible. If the Internet is that important to your business, then have more than one provider. If you have clue, you'll use one with a different layer 3, 2, 1, or maybe even 0 route topology. Its far simpler to have multiple providers and networks than paying a fortune to have some undeliverable level of reliability. And besides *you* have control over it. My business relies heavily on the Internet. We use 5 providers for our network and around 5 for the services. We mix dsl with wireless (3 forms), we have 4 satellite links, fiber and are known to run our own cable when we can't get what we want where we want it. A Km or two is no real issue. If a company uses a UPS for its computer, why doesn't it invest in a second link. Even crappy dsl will at least keep something going. Rich _______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog

3 2

streaming Olympics coverage in early August
by Simon Blake 29 Jun '08

29 Jun '08

Hi all CityLink will be assisting TVNZ with their online coverage of the Beijing games next month. The exact coverage hasn't been finalised yet, but we're expecting that TVNZ will run approximately four coverage streams - live encodings of TV1 and TVNZ sports extra (from Freeview), and two further channels that will be online only. Each will be Windows Media streams at ~90Kb/s, ~384Kb/s, and 1.5-2Mb/s, and if we can get our act together there may be an experimental HD Freeview coverage stream at 5-6Mb/s. So, a significant amount of content, much of which won't be available from traditional telly. Predicting usage for this sort of gig is difficult, particularly when access to this content by customers of some providers (Vodafone, Orcon) won't come off their data cap. We're assuming there will be heavy demand, so we're aiming to have StreamingNet (our anycast CDN) deliver aggregate 5-10Gb/s peak domestic bandwidth. Therefore, those running eyeball networks should be thinking about how best to get at this content. If your IX connections are full (or nearly full), then now may be a good time to organise an upgrade. Cheers Simon

1 0

ICANN New TLD's
by Chris Hodgetts 29 Jun '08

29 Jun '08

No one here has commented, (Unless my mail filter rules are a little broken at the moment) What are peoples thoughts?

10 9

Vector, did you try turning it off and then on again
by Chris Hodgetts 29 Jun '08

29 Jun '08

That usually fixes things.... Did anyone else find if appalling that Vector advised that the issue would be resolved on Monday .. And that it took over 9 hours to resolve? (It has not been mentioned here but I assume everyone knows what I am rambling about)

4 3

NZRR Route Registry Update
by NZRR Database Notifications 29 Jun '08

29 Jun '08

Dear Colleague, This is to notify you that one or more objects in which you are designated for notification have been modified in the NZRR routing registry database. 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. Diagnostic output: ------------------------------------------------------------ --- PREVIOUS OBJECT: route-set: AS9560:RS-ROUTES:AS24324 descr: advertised to AS9560 by Kordia - AS24324 members: 118.148.0.0/15^15-29, 124.157.64.0/19^19-29, 58.84.224.0/20^20-29, 116.89.224.0/20^20-29, 202.56.32.0/20^20-29, 202.68.80.0/20^20-29, 203.144.32.0/20^20-29, 116.90.128.0/21^21-29, 117.104.176.0/21^21-29, 123.108.144.0/21^21-29, 202.20.0.0/21^21-29, 202.49.16.0/21^21-29, 202.49.128.0/21^21-29, 202.56.48.0/21^21-29, 202.137.240.0/21^21-29, 218.185.224.0/21^21-29, 202.6.116.0/23^23-29, 202.27.88.0/23^23-29, 202.65.160.0/23^23-29, 202.174.190.0/23^23-29, 203.110.28.0/23^23-29, 192.173.17.0/24^24-29, 202.21.130.0/24^24-29, 202.27.34.0/24^24-29, 202.27.83.0/24^24-29, 202.27.90.0/24^24-29, 202.36.75.0/24^24-29, 202.36.137.0/24^24-29, 202.36.154.0/24^24-29, 202.36.173.0/24^24-29, 202.37.168.0/24^24-29, 202.37.197.0/24^24-29, 202.49.158.0/24^24-29, 202.49.183.0/24^24-29, 203.30.174.0/24^24-29, 203.92.25.0/24^24-29, 203.171.4.0/24^24-29, 203.174.26.0/24^24-29, 203.97.62.200/29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: smc(a)kordia.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20080411 source: NZRR REPLACED BY: route-set: AS9560:RS-ROUTES:AS24324 descr: advertised to AS9560 by Kordia - AS24324 members: 118.148.0.0/15^15-29, 124.157.64.0/18^18-29, 58.84.224.0/20^20-29, 114.134.0.0/20^20-29, 116.89.224.0/20^20-29, 202.56.32.0/20^20-29, 202.68.80.0/20^20-29, 203.144.32.0/20^20-29, 116.90.128.0/21^21-29, 117.104.176.0/21^21-29, 123.108.144.0/21^21-29, 202.20.0.0/21^21-29, 202.49.16.0/21^21-29, 202.49.128.0/21^21-29, 202.56.48.0/21^21-29, 202.137.240.0/21^21-29, 218.185.224.0/21^21-29, 202.6.116.0/23^23-29, 202.27.88.0/23^23-29, 202.65.160.0/23^23-29, 202.174.190.0/23^23-29, 203.110.28.0/23^23-29, 192.173.17.0/24^24-29, 202.21.130.0/24^24-29, 202.27.34.0/24^24-29, 202.27.83.0/24^24-29, 202.27.90.0/24^24-29, 202.36.75.0/24^24-29, 202.36.137.0/24^24-29, 202.36.154.0/24^24-29, 202.36.173.0/24^24-29, 202.37.168.0/24^24-29, 202.37.197.0/24^24-29, 202.49.158.0/24^24-29, 202.49.183.0/24^24-29, 203.30.174.0/24^24-29, 203.92.25.0/24^24-29, 203.171.4.0/24^24-29, 203.174.26.0/24^24-29, 203.97.62.200/29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: smc(a)kordia.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20080630 source: NZRR ------------------------------------------------------------

1 0

Test to nznog -1
by Simon Lyall 28 Jun '08

28 Jun '08

Test message in response to reports of problems with the list. Please ignore. -- Simon Lyall | Very Busy | Web: http://www.darkmere.gen.nz/ "To stay awake all night adds a day to your life" - Stilgar | eMT.

1 0

NZRR Route Registry Update
by NZRR Database Notifications 26 Jun '08

26 Jun '08

Dear Colleague, This is to notify you that one or more objects in which you are designated for notification have been modified in the NZRR routing registry database. 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. Diagnostic output: ------------------------------------------------------------ --- PREVIOUS OBJECT: route-set: AS9560:RS-ROUTES:AS4770 descr: advertised to AS9560 by ICONZ - AS4770 members: 210.48.0.0/17^17-29, 210.185.0.0/18^18-29, 210.54.160.0/19^19-29, 202.55.96.0/20^20-29, 202.174.160.0/20^20-29, 210.56.32.0/20^20-29, 117.18.80.0/21^21-29, 120.138.16.0/21^21-29, 202.12.248.0/21^21-29, 202.37.144.0/21^21-29, 202.37.224.0/21^21-29, 202.74.224.0/21^21-29, 202.78.240.0/21^21-29, 205.233.128.0/21^21-29, 202.36.36.0/22^22-29, 202.37.140.0/22^22-29, 202.37.200.0/22^22-29, 202.41.136.0/22^22-29, 203.80.60.0/22^22-29, 210.54.136.0/22^22-29, 210.55.24.0/22^22-29, 199.212.92.0/23^23-29, 202.21.136.0/23^23-29, 202.36.44.0/23^23-29, 202.36.76.0/23^23-29, 202.37.240.0/23^23-29, 202.37.252.0/23^23-29, 202.61.2.0/23^23-29, 202.174.6.0/23^23-29, 205.233.136.0/23^23-29, 192.88.85.0/24^24-29, 192.107.113.0/24^24-29, 198.32.66.0/24^24-29, 202.6.84.0/24^24-29, 202.12.70.0/24^24-29, 202.14.100.0/24^24-29, 202.20.6.0/24^24-29, 202.21.130.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.37.57.0/24^24-29, 202.37.73.0/24^24-29, 202.37.76.0/24^24-29, 202.37.85.0/24^24-29, 202.37.163.0/24^24-29, 202.46.190.0/24^24-29, 202.49.62.0/24^24-29, 202.49.89.0/24^24-29, 202.49.159.0/24^24-29, 202.49.249.0/24^24-29, 202.50.87.0/24^24-29, 202.50.139.0/24^24-29, 205.233.243.0/24^24-29, 210.54.140.0/24^24-29, 210.54.211.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: deon(a)iconz.net mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20080529 source: NZRR REPLACED BY: route-set: AS9560:RS-ROUTES:AS4770 descr: advertised to AS9560 by ICONZ Ltd - AS4770 members: 210.48.0.0/17^17-29, 210.185.0.0/18^18-29, 210.54.160.0/19^19-29, 114.134.160.0/20^20-29, 202.55.96.0/20^20-29, 202.174.160.0/20^20-29, 210.56.32.0/20^20-29, 114.134.176.0/21^21-29, 120.138.16.0/21^21-29, 202.12.248.0/21^21-29, 202.37.144.0/21^21-29, 202.37.224.0/21^21-29, 202.74.224.0/21^21-29, 202.78.240.0/21^21-29, 205.233.128.0/21^21-29, 202.36.36.0/22^22-29, 202.37.140.0/22^22-29, 202.37.200.0/22^22-29, 202.41.136.0/22^22-29, 203.80.60.0/22^22-29, 210.54.136.0/22^22-29, 210.55.24.0/22^22-29, 199.212.92.0/23^23-29, 202.36.76.0/23^23-29, 202.37.240.0/23^23-29, 202.37.252.0/23^23-29, 202.174.6.0/23^23-29, 205.233.136.0/23^23-29, 210.4.212.0/23^23-29, 192.88.85.0/24^24-29, 198.32.66.0/24^24-29, 202.6.84.0/24^24-29, 202.12.70.0/24^24-29, 202.14.100.0/24^24-29, 202.20.6.0/24^24-29, 202.21.130.0/24^24-29, 202.27.208.0/24^24-29, 202.36.45.0/24^24-29, 202.36.119.0/24^24-29, 202.36.183.0/24^24-29, 202.37.57.0/24^24-29, 202.37.73.0/24^24-29, 202.37.76.0/24^24-29, 202.37.85.0/24^24-29, 202.37.163.0/24^24-29, 202.46.190.0/24^24-29, 202.49.62.0/24^24-29, 202.49.89.0/24^24-29, 202.49.159.0/24^24-29, 202.50.87.0/24^24-29, 202.50.139.0/24^24-29, 205.233.243.0/24^24-29, 210.54.211.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: deon(a)iconz.net mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20080627 source: NZRR ------------------------------------------------------------

1 0

NZRR Route Registry Update
by NZRR Database Notifications 26 Jun '08

26 Jun '08

Dear Colleague, This is to notify you that one or more objects in which you are designated for notification have been modified in the NZRR routing registry database. 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. Diagnostic output: ------------------------------------------------------------ --- PREVIOUS OBJECT: route-set: AS9439:RS-ROUTES:AS4770 descr: advertised to AS9439 by ICONZ - AS4770 members: 210.48.0.0/17^17-29, 210.185.0.0/18^18-29, 210.54.160.0/19^19-29, 202.55.96.0/20^20-29, 202.174.160.0/20^20-29, 210.56.32.0/20^20-29, 117.18.80.0/21^21-29, 120.138.16.0/21^21-29, 202.12.248.0/21^21-29, 202.37.144.0/21^21-29, 202.37.224.0/21^21-29, 202.74.224.0/21^21-29, 202.78.240.0/21^21-29, 205.233.128.0/21^21-29, 202.36.36.0/22^22-29, 202.37.140.0/22^22-29, 202.37.200.0/22^22-29, 202.41.136.0/22^22-29, 203.80.60.0/22^22-29, 210.54.136.0/22^22-29, 210.55.24.0/22^22-29, 199.212.92.0/23^23-29, 202.21.136.0/23^23-29, 202.36.44.0/23^23-29, 202.36.76.0/23^23-29, 202.37.240.0/23^23-29, 202.37.252.0/23^23-29, 202.61.2.0/23^23-29, 202.174.6.0/23^23-29, 205.233.136.0/23^23-29, 192.88.85.0/24^24-29, 192.107.113.0/24^24-29, 198.32.66.0/24^24-29, 202.6.84.0/24^24-29, 202.12.70.0/24^24-29, 202.14.100.0/24^24-29, 202.20.6.0/24^24-29, 202.21.130.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.37.57.0/24^24-29, 202.37.73.0/24^24-29, 202.37.76.0/24^24-29, 202.37.85.0/24^24-29, 202.37.163.0/24^24-29, 202.46.190.0/24^24-29, 202.49.62.0/24^24-29, 202.49.89.0/24^24-29, 202.49.159.0/24^24-29, 202.49.249.0/24^24-29, 202.50.87.0/24^24-29, 202.50.139.0/24^24-29, 205.233.243.0/24^24-29, 210.54.140.0/24^24-29, 210.54.211.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: deon(a)iconz.net mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20080507 source: NZRR REPLACED BY: route-set: AS9439:RS-ROUTES:AS4770 descr: advertised to AS9439 by ICONZ Ltd - AS4770 members: 210.48.0.0/17^17-29, 210.185.0.0/18^18-29, 210.54.160.0/19^19-29, 114.134.160.0/20^20-29, 202.55.96.0/20^20-29, 202.174.160.0/20^20-29, 210.56.32.0/20^20-29, 114.134.176.0/21^21-29, 120.138.16.0/21^21-29, 202.12.248.0/21^21-29, 202.37.144.0/21^21-29, 202.37.224.0/21^21-29, 202.74.224.0/21^21-29, 202.78.240.0/21^21-29, 205.233.128.0/21^21-29, 202.36.36.0/22^22-29, 202.37.140.0/22^22-29, 202.37.200.0/22^22-29, 202.41.136.0/22^22-29, 203.80.60.0/22^22-29, 210.54.136.0/22^22-29, 210.55.24.0/22^22-29, 199.212.92.0/23^23-29, 202.36.76.0/23^23-29, 202.37.240.0/23^23-29, 202.37.252.0/23^23-29, 202.174.6.0/23^23-29, 205.233.136.0/23^23-29, 210.4.212.0/23^23-29, 192.88.85.0/24^24-29, 198.32.66.0/24^24-29, 202.6.84.0/24^24-29, 202.12.70.0/24^24-29, 202.14.100.0/24^24-29, 202.20.6.0/24^24-29, 202.21.130.0/24^24-29, 202.27.208.0/24^24-29, 202.36.45.0/24^24-29, 202.36.119.0/24^24-29, 202.36.183.0/24^24-29, 202.37.57.0/24^24-29, 202.37.73.0/24^24-29, 202.37.76.0/24^24-29, 202.37.85.0/24^24-29, 202.37.163.0/24^24-29, 202.46.190.0/24^24-29, 202.49.62.0/24^24-29, 202.49.89.0/24^24-29, 202.49.159.0/24^24-29, 202.50.87.0/24^24-29, 202.50.139.0/24^24-29, 205.233.243.0/24^24-29, 210.54.211.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: deon(a)iconz.net mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20080627 source: NZRR ------------------------------------------------------------

1 0

NZRR Route Registry Update
by NZRR Database Notifications 25 Jun '08

25 Jun '08

Dear Colleague, This is to notify you that one or more objects in which you are designated for notification have been modified in the NZRR routing registry database. 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. Diagnostic output: ------------------------------------------------------------ --- NEW OBJECT CREATION: route-set: AS9439:RS-ROUTES:AS9834 descr: advertised to AS9439 by Trade Me Limited - AS9834 members: 203.57.145.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)trademe.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20080626 source: NZRR ------------------------------------------------------------

1 0

NZRR Route Registry Update
by NZRR Database Notifications 25 Jun '08

25 Jun '08

Dear Colleague, This is to notify you that one or more objects in which you are designated for notification have been modified in the NZRR routing registry database. 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. Diagnostic output: ------------------------------------------------------------ --- PREVIOUS OBJECT: route-set: AS9439:RS-ROUTES:AS24078 descr: advertised to AS9439 by Trade Me Limited - AS24078 members: 202.21.128.0/24^24-29, 203.57.145.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: allister(a)trademe.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20051122 source: NZRR REPLACED BY: route-set: AS9439:RS-ROUTES:AS24078 descr: advertised to AS9439 by Trade Me Limited - AS24078 members: 202.21.128.0/24^24-29, 203.57.145.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)trademe.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20080626 source: NZRR ------------------------------------------------------------

1 0

NZRR Route Registry Update
by NZRR Database Notifications 25 Jun '08

25 Jun '08

Dear Colleague, This is to notify you that one or more objects in which you are designated for notification have been modified in the NZRR routing registry database. 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. Diagnostic output: ------------------------------------------------------------ --- PREVIOUS OBJECT: route-set: AS9439:RS-ROUTES:AS24006 descr: advertised to AS9439 by Knossos Networks Ltd - AS24006 members: 202.160.48.0/20^20-29, 161.29.254.0/23^23-29, 202.53.189.0/28^28-29, 161.29.192.160/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)knossos.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20071001 source: NZRR REPLACED BY: route-set: AS9439:RS-ROUTES:AS24006 descr: advertised to AS9439 by Knossos Networks Ltd - AS24006 members: 202.160.48.0/20^20-29, 161.29.254.0/23^23-29, 202.53.189.0/28^28-29, 161.29.126.128/29, 161.29.192.160/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)knossos.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20080626 source: NZRR ------------------------------------------------------------

1 0

another phishing scam
by Russell Sharpe 24 Jun '08

24 Jun '08

Hhis time HSBC if people click on <http://www.littleredtrain.co.uk/hssbc.co.uk/1/2/personal/internet-banking-j sessionid=0000quurGtvuPvBm9/> https://www.hsbc.co.uk they are directed to http://www.littleredtrain.co.uk/hssbc.co.uk/1/2/personal/internet-banking-js essionid=0000quurGtvuPvBm9 I only caught it because I check my 11yo daughters emails Russ

1 0

APNIC service announcement
by Elly Tawhai 23 Jun '08

23 Jun '08

Dear APNIC members and friends, Some services provided by APNIC were unavailable this morning due to a disruption to our international connectivity. This occurred between 07:00 Australian Eastern Standard Time (AEST) and approximately 11:20 AEST. Major services affected were: - www.apnic.net - MyAPNIC - email - Whois - Reverse DNS (partial) Services provided by ns3.apnic.net and sec3.apnic.net remained resolvable. Unfortunately, we were not able to announce this situation when it occurred due to the loss of connectivity. APNIC Network Operations are actively reviewing the escalation procedure of our network redundancy to ensure the continuous provision of APNIC services. We apologize for the loss of facilities and for any inconvenience caused. Should you require further assistance in dealing with any problems arising from this outage, please contact the APNIC Helpdesk. Phone: +61 7 3858 3188 (09:00 to 19:00 AEST, UTC+10) Fax: +61 7 3858 3199 Email: helpdesk(a)apnic.net Kind regards, Elly ________________________________________________________________________ Elly Tawhai email: hostmaster(a)apnic.net Senior Internet Resource Analyst, APNIC sip: hostmaster(a)voip.apnic.net http://www.apnic.net/helpdesk phone: +61 7 3858 3188 fax: +61 7 3858 3199 ________________________________________________________________________ Hope to see you at APNIC 26 in Christchurch, New Zealand 25 - 29 August 2008 http://www.apnic.net/meetings/26/

1 0

ISIF - New ICT grants program for Asia Pacific
by Elly Tawhai 19 Jun '08

19 Jun '08

ISIF channels important funding into the Asia Pacific ICT community Technological innovation is crucial in today's challenging market circumstances. Key players in the ICT world recognize this and are coming together to launch a new grants program for the Asia Pacific Information and Communication Technology (ICT) community. The Information Society Innovation Fund (ISIF) is a joint initiative between the Canadian International Development Research Centre (IDRC), the Internet Society (ISOC), and the Asia Pacific Network Information Centre (APNIC), aimed at stimulating creative solutions to ICT development needs in the Asia Pacific region. ISIF provides grants of up to US$30,000 per project to help advance local and regional projects aimed at introducing, improving, and applying Internet and other digital communications technologies for the benefit of Asia-Pacific users and communities. APNIC Director General Paul Wilson states, "Innovative projects, such as the ones funded by ISIF, are a significant driver to Internet and technology growth in our region. APNIC encourages members of the Asia Pacific ICT community to submit their projects for consideration." "ISOC believes that the Internet can contribute to a better quality of life for people all over the world," says ISOC President and CEO Lynn St. Amour. "ISIF helps ensure that local knowledge and experience is directed at tapping the potential of ICTs to address real-world problems with creative, innovative solutions." "In Asia Pacific the Internet and the Mobile phone development are on different trajectories. We hope the ISIF research fund can help illuminate and address the new 'digital divergence' in our region", says Richard Fuchs, chair of the ISIF Grants Committee and Regional Director at IDRC, Southeast and East Asia. Project proposals from Asia-Pacific based public or private sector organisations, university or research and development institutions, and non-government organisations will be considered. Applications must be aligned with ISIF program objectives, selection criteria and administrative guidelines. Individuals are not eligible for grants. The ISIF grant round for 2008 is now open and applications are due 1 September 2008. A total of US$375,000 will be available for grants in 2008. Grants will be made on a competitive basis and successful applicants will be required to make project details, outcomes and findings publicly available. Complete information on the program and how to apply is available on the ISIF website at www.isif.asia. ISIF is proudly sponsored by the DotAsia Organisation, the registry operator for the .ASIA top level domain. For more information: Sylvia Cadena | ISIF Program Officer info(a)isif.asia http://www.isif.asia

1 0

NZRR Route Registry Update
by NZRR Database Notifications 18 Jun '08

18 Jun '08

Dear Colleague, This is to notify you that one or more objects in which you are designated for notification have been modified in the NZRR routing registry database. 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. Diagnostic output: ------------------------------------------------------------ --- 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, 166.65.0.0/16^16-29, 119.15.0.0/19^19-29, 202.53.176.0/20^20-29, 202.191.32.0/20^20-29, 210.48.160.0/20^20-29, 120.89.80.0/21^21-29, 192.173.16.0/21^21-29, 202.46.176.0/21^21-29, 202.49.0.0/21^21-29, 202.78.240.0/21^21-29, 203.190.208.0/21^21-29, 202.37.48.0/22^22-29, 202.89.4.0/22^22-29, 202.124.106.0/23^23-29, 192.88.85.0/24^24-29, 192.122.171.0/24^24-29, 192.133.31.0/24^24-29, 192.195.219.0/24^24-29, 202.20.97.0/24^24-29, 202.36.33.0/24^24-29, 202.36.119.0/24^24-29, 202.36.162.0/24^24-29, 202.36.218.0/24^24-29, 202.46.190.0/24^24-29, 202.49.106.0/24^24-29, 202.50.247.0/24^24-29, 202.55.105.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 20080617 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, 166.65.0.0/16^16-29, 119.15.0.0/19^19-29, 202.53.176.0/20^20-29, 202.191.32.0/20^20-29, 210.48.160.0/20^20-29, 120.89.80.0/21^21-29, 192.173.16.0/21^21-29, 202.46.176.0/21^21-29, 202.49.0.0/21^21-29, 202.78.240.0/21^21-29, 203.190.208.0/21^21-29, 202.37.48.0/22^22-29, 202.89.4.0/22^22-29, 202.160.116.0/22^22-29, 202.124.106.0/23^23-29, 202.160.114.0/23^23-29, 192.88.85.0/24^24-29, 192.122.171.0/24^24-29, 192.133.31.0/24^24-29, 192.195.219.0/24^24-29, 202.20.97.0/24^24-29, 202.36.33.0/24^24-29, 202.36.119.0/24^24-29, 202.36.162.0/24^24-29, 202.36.218.0/24^24-29, 202.46.190.0/24^24-29, 202.49.106.0/24^24-29, 202.50.247.0/24^24-29, 202.55.105.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: service(a)fx.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20080619 source: NZRR ------------------------------------------------------------

1 0

NZRR Route Registry Update
by NZRR Database Notifications 18 Jun '08

18 Jun '08

Dear Colleague, This is to notify you that one or more objects in which you are designated for notification have been modified in the NZRR routing registry database. 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. Diagnostic output: ------------------------------------------------------------ --- 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, 166.65.0.0/16^16-29, 119.15.0.0/19^19-29, 202.53.176.0/20^20-29, 202.191.32.0/20^20-29, 210.48.160.0/20^20-29, 120.89.80.0/21^21-29, 192.173.16.0/21^21-29, 202.46.176.0/21^21-29, 202.49.0.0/21^21-29, 202.78.240.0/21^21-29, 203.190.208.0/21^21-29, 202.37.48.0/22^22-29, 202.89.4.0/22^22-29, 202.124.106.0/23^23-29, 192.88.85.0/24^24-29, 192.122.171.0/24^24-29, 192.133.31.0/24^24-29, 192.195.219.0/24^24-29, 202.20.97.0/24^24-29, 202.36.33.0/24^24-29, 202.36.119.0/24^24-29, 202.36.162.0/24^24-29, 202.36.218.0/24^24-29, 202.46.190.0/24^24-29, 202.49.106.0/24^24-29, 202.50.247.0/24^24-29, 202.55.105.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 20080617 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, 166.65.0.0/16^16-29, 119.15.0.0/19^19-29, 202.53.176.0/20^20-29, 202.191.32.0/20^20-29, 210.48.160.0/20^20-29, 120.89.80.0/21^21-29, 192.173.16.0/21^21-29, 202.46.176.0/21^21-29, 202.49.0.0/21^21-29, 202.78.240.0/21^21-29, 203.190.208.0/21^21-29, 202.37.48.0/22^22-29, 202.89.4.0/22^22-29, 202.160.116.0/22^22-29, 202.124.106.0/23^23-29, 202.160.114.0/23^23-29, 192.88.85.0/24^24-29, 192.122.171.0/24^24-29, 192.133.31.0/24^24-29, 192.195.219.0/24^24-29, 202.20.97.0/24^24-29, 202.36.33.0/24^24-29, 202.36.119.0/24^24-29, 202.36.162.0/24^24-29, 202.36.218.0/24^24-29, 202.46.190.0/24^24-29, 202.49.106.0/24^24-29, 202.50.247.0/24^24-29, 202.55.105.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: service(a)fx.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20080619 source: NZRR ------------------------------------------------------------

1 0

NZRR Route Registry Update
by NZRR Database Notifications 18 Jun '08

18 Jun '08

Dear Colleague, This is to notify you that one or more objects in which you are designated for notification have been modified in the NZRR routing registry database. 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. Diagnostic output: ------------------------------------------------------------ --- PREVIOUS OBJECT: route-set: AS9560:RS-ROUTES:AS23655 descr: advertised to AS9560 by SNAP Internet Ltd - AS23655 members: 132.181.0.0/16^16-29, 138.75.0.0/16^16-29, 153.111.0.0/16^16-29, 165.84.0.0/16^16-29, 123.255.0.0/18^18-29, 202.124.96.0/19^19-29, 203.86.192.0/20^20-29, 202.174.112.0/21^21-29, 210.5.48.0/21^21-29, 202.49.72.0/22^22-29, 202.49.92.0/22^22-29, 202.50.104.0/22^22-29, 202.50.124.0/22^22-29, 202.164.28.0/22^22-29, 202.27.186.0/23^23-29, 202.36.178.0/23^23-29, 202.36.220.0/23^23-29, 202.37.96.0/23^23-29, 202.37.100.0/23^23-29, 202.37.124.0/23^23-29, 202.49.90.0/23^23-29, 202.49.120.0/23^23-29, 210.55.30.0/23^23-29, 210.55.206.0/23^23-29, 192.148.221.0/24^24-29, 192.156.225.0/24^24-29, 202.36.163.0/24^24-29, 202.36.170.0/24^24-29, 202.36.219.0/24^24-29, 202.37.114.0/24^24-29, 202.49.115.0/24^24-29, 202.49.125.0/24^24-29, 202.49.187.0/24^24-29, 202.50.117.0/24^24-29, 202.50.169.0/24^24-29, 202.146.186.0/24^24-29, 203.96.112.0/24^24-29, 210.7.40.0/24^24-29, 210.54.15.0/24^24-29, 210.55.4.0/24^24-29, 210.55.7.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)snap.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20080618 source: NZRR REPLACED BY: route-set: AS9560:RS-ROUTES:AS23655 descr: advertised to AS9560 by SNAP Internet Ltd - AS23655 members: 132.181.0.0/16^16-29, 138.75.0.0/16^16-29, 153.111.0.0/16^16-29, 165.84.0.0/16^16-29, 123.255.0.0/18^18-29, 202.124.96.0/19^19-29, 203.86.192.0/20^20-29, 202.174.112.0/21^21-29, 210.5.48.0/21^21-29, 202.49.72.0/22^22-29, 202.49.92.0/22^22-29, 202.50.104.0/22^22-29, 202.50.124.0/22^22-29, 202.164.28.0/22^22-29, 202.27.186.0/23^23-29, 202.36.178.0/23^23-29, 202.36.220.0/23^23-29, 202.37.96.0/23^23-29, 202.37.100.0/23^23-29, 202.37.124.0/23^23-29, 202.49.90.0/23^23-29, 202.49.120.0/23^23-29, 210.55.30.0/23^23-29, 210.55.206.0/23^23-29, 192.148.221.0/24^24-29, 192.156.225.0/24^24-29, 202.36.163.0/24^24-29, 202.36.170.0/24^24-29, 202.36.219.0/24^24-29, 202.37.114.0/24^24-29, 202.49.115.0/24^24-29, 202.49.125.0/24^24-29, 202.49.187.0/24^24-29, 202.50.117.0/24^24-29, 202.50.169.0/24^24-29, 202.146.186.0/24^24-29, 203.96.112.0/24^24-29, 210.7.40.0/24^24-29, 210.54.15.0/24^24-29, 210.55.4.0/24^24-29, 210.55.7.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)snap.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20080619 source: NZRR ------------------------------------------------------------

1 0

AS Numbers registry updated
by Leo Vegoda 17 Jun '08

17 Jun '08

Hi, This is to let you know that we have updated the AS Numbers registry in cooperation with the RIRs. It now shows which RIR currently provides Whois service for an AS Number instead of the RIR to which the AS Number was originally allocated. The updated registry is now over 2000 lines long but the format has not changed. In addition to the current format, the AS Numbers registry will be made available in XML during July. The updated registry will shortly be available at: http://www.iana.org/assignments/as-numbers Kind regards, Leo Vegoda IANA

1 0

NZRR Route Registry Update
by NZRR Database Notifications 17 Jun '08

17 Jun '08

Dear Colleague, This is to notify you that one or more objects in which you are designated for notification have been modified in the NZRR routing registry database. 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. Diagnostic output: ------------------------------------------------------------ --- PREVIOUS OBJECT: route-set: AS9560:RS-ROUTES:AS23655 descr: advertised to AS9560 by SNAP Internet Ltd - AS23655 members: 132.181.0.0/16^16-29, 138.75.0.0/16^16-29, 153.111.0.0/16^16-29, 165.84.0.0/16^16-29, 123.255.0.0/18^18-29, 202.124.96.0/19^19-29, 203.86.192.0/20^20-29, 202.174.112.0/21^21-29, 210.5.48.0/21^21-29, 202.49.72.0/22^22-29, 202.49.92.0/22^22-29, 202.50.104.0/22^22-29, 202.50.124.0/22^22-29, 202.164.28.0/22^22-29, 202.27.186.0/23^23-29, 202.36.178.0/23^23-29, 202.36.218.0/23^23-29, 202.36.220.0/23^23-29, 202.37.96.0/23^23-29, 202.37.100.0/23^23-29, 202.37.124.0/23^23-29, 202.49.90.0/23^23-29, 202.49.120.0/23^23-29, 210.55.30.0/23^23-29, 210.55.206.0/23^23-29, 192.148.221.0/24^24-29, 192.156.225.0/24^24-29, 202.36.163.0/24^24-29, 202.36.170.0/24^24-29, 202.37.114.0/24^24-29, 202.49.115.0/24^24-29, 202.49.125.0/24^24-29, 202.49.187.0/24^24-29, 202.50.117.0/24^24-29, 202.50.169.0/24^24-29, 202.146.186.0/24^24-29, 203.96.112.0/24^24-29, 210.7.40.0/24^24-29, 210.54.15.0/24^24-29, 210.55.4.0/24^24-29, 210.55.7.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)snap.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20080409 source: NZRR REPLACED BY: route-set: AS9560:RS-ROUTES:AS23655 descr: advertised to AS9560 by SNAP Internet Ltd - AS23655 members: 132.181.0.0/16^16-29, 138.75.0.0/16^16-29, 153.111.0.0/16^16-29, 165.84.0.0/16^16-29, 123.255.0.0/18^18-29, 202.124.96.0/19^19-29, 203.86.192.0/20^20-29, 202.174.112.0/21^21-29, 210.5.48.0/21^21-29, 202.49.72.0/22^22-29, 202.49.92.0/22^22-29, 202.50.104.0/22^22-29, 202.50.124.0/22^22-29, 202.164.28.0/22^22-29, 202.27.186.0/23^23-29, 202.36.178.0/23^23-29, 202.36.220.0/23^23-29, 202.37.96.0/23^23-29, 202.37.100.0/23^23-29, 202.37.124.0/23^23-29, 202.49.90.0/23^23-29, 202.49.120.0/23^23-29, 210.55.30.0/23^23-29, 210.55.206.0/23^23-29, 192.148.221.0/24^24-29, 192.156.225.0/24^24-29, 202.36.163.0/24^24-29, 202.36.170.0/24^24-29, 202.36.219.0/24^24-29, 202.37.114.0/24^24-29, 202.49.115.0/24^24-29, 202.49.125.0/24^24-29, 202.49.187.0/24^24-29, 202.50.117.0/24^24-29, 202.50.169.0/24^24-29, 202.146.186.0/24^24-29, 203.96.112.0/24^24-29, 210.7.40.0/24^24-29, 210.54.15.0/24^24-29, 210.55.4.0/24^24-29, 210.55.7.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)snap.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20080618 source: NZRR ------------------------------------------------------------

1 0

NZRR Route Registry Update
by NZRR Database Notifications 17 Jun '08

17 Jun '08

Dear Colleague, This is to notify you that one or more objects in which you are designated for notification have been modified in the NZRR routing registry database. 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. Diagnostic output: ------------------------------------------------------------ --- PREVIOUS OBJECT: route-set: AS9439:RS-ROUTES:AS23655 descr: advertised to AS9439 by SNAP Internet Ltd - AS23655 members: 132.181.0.0/16^16-29, 138.75.0.0/16^16-29, 153.111.0.0/16^16-29, 165.84.0.0/16^16-29, 123.255.0.0/18^18-29, 202.124.96.0/19^19-29, 203.86.192.0/20^20-29, 202.174.112.0/21^21-29, 210.5.48.0/21^21-29, 202.49.72.0/22^22-29, 202.49.92.0/22^22-29, 202.50.104.0/22^22-29, 202.50.124.0/22^22-29, 202.164.28.0/22^22-29, 202.27.186.0/23^23-29, 202.36.178.0/23^23-29, 202.36.218.0/23^23-29, 202.36.220.0/23^23-29, 202.37.96.0/23^23-29, 202.37.100.0/23^23-29, 202.37.124.0/23^23-29, 202.49.90.0/23^23-29, 202.49.120.0/23^23-29, 210.55.30.0/23^23-29, 210.55.206.0/23^23-29, 192.148.221.0/24^24-29, 192.156.225.0/24^24-29, 202.36.163.0/24^24-29, 202.36.170.0/24^24-29, 202.37.114.0/24^24-29, 202.49.115.0/24^24-29, 202.49.125.0/24^24-29, 202.49.187.0/24^24-29, 202.50.117.0/24^24-29, 202.50.169.0/24^24-29, 202.146.186.0/24^24-29, 203.96.112.0/24^24-29, 210.7.40.0/24^24-29, 210.54.15.0/24^24-29, 210.55.4.0/24^24-29, 210.55.7.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)snap.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20080409 source: NZRR REPLACED BY: route-set: AS9439:RS-ROUTES:AS23655 descr: advertised to AS9439 by SNAP Internet Ltd - AS23655 members: 132.181.0.0/16^16-29, 138.75.0.0/16^16-29, 153.111.0.0/16^16-29, 165.84.0.0/16^16-29, 123.255.0.0/18^18-29, 202.124.96.0/19^19-29, 203.86.192.0/20^20-29, 202.174.112.0/21^21-29, 210.5.48.0/21^21-29, 202.49.72.0/22^22-29, 202.49.92.0/22^22-29, 202.50.104.0/22^22-29, 202.50.124.0/22^22-29, 202.164.28.0/22^22-29, 202.27.186.0/23^23-29, 202.36.178.0/23^23-29, 202.36.220.0/23^23-29, 202.37.96.0/23^23-29, 202.37.100.0/23^23-29, 202.37.124.0/23^23-29, 202.49.90.0/23^23-29, 202.49.120.0/23^23-29, 210.55.30.0/23^23-29, 210.55.206.0/23^23-29, 192.148.221.0/24^24-29, 192.156.225.0/24^24-29, 202.36.163.0/24^24-29, 202.36.170.0/24^24-29, 202.36.219.0/24^24-29, 202.37.114.0/24^24-29, 202.49.115.0/24^24-29, 202.49.125.0/24^24-29, 202.49.187.0/24^24-29, 202.50.117.0/24^24-29, 202.50.169.0/24^24-29, 202.146.186.0/24^24-29, 203.96.112.0/24^24-29, 210.7.40.0/24^24-29, 210.54.15.0/24^24-29, 210.55.4.0/24^24-29, 210.55.7.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)snap.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20080618 source: NZRR ------------------------------------------------------------

1 0

NZRR Route Registry Update
by NZRR Database Notifications 17 Jun '08

17 Jun '08

Dear Colleague, This is to notify you that one or more objects in which you are designated for notification have been modified in the NZRR routing registry database. 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. Diagnostic output: ------------------------------------------------------------ --- PREVIOUS OBJECT: route-set: AS24388:RS-ROUTES:AS23655 descr: advertised to AS24388 by SNAP Internet Ltd - AS23655 members: 132.181.0.0/16^16-29, 138.75.0.0/16^16-29, 153.111.0.0/16^16-29, 165.84.0.0/16^16-29, 123.255.0.0/18^18-29, 202.124.96.0/19^19-29, 203.86.192.0/20^20-29, 202.174.112.0/21^21-29, 210.5.48.0/21^21-29, 202.49.72.0/22^22-29, 202.49.92.0/22^22-29, 202.50.104.0/22^22-29, 202.50.124.0/22^22-29, 202.164.28.0/22^22-29, 202.27.186.0/23^23-29, 202.36.178.0/23^23-29, 202.36.218.0/23^23-29, 202.36.220.0/23^23-29, 202.37.96.0/23^23-29, 202.37.100.0/23^23-29, 202.37.124.0/23^23-29, 202.49.90.0/23^23-29, 202.49.120.0/23^23-29, 210.55.30.0/23^23-29, 210.55.206.0/23^23-29, 192.148.221.0/24^24-29, 192.156.225.0/24^24-29, 202.36.163.0/24^24-29, 202.36.170.0/24^24-29, 202.37.114.0/24^24-29, 202.49.115.0/24^24-29, 202.49.125.0/24^24-29, 202.49.187.0/24^24-29, 202.50.117.0/24^24-29, 202.50.169.0/24^24-29, 202.146.186.0/24^24-29, 203.96.112.0/24^24-29, 210.7.40.0/24^24-29, 210.54.15.0/24^24-29, 210.55.4.0/24^24-29, 210.55.7.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)snap.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20080409 source: NZRR REPLACED BY: route-set: AS24388:RS-ROUTES:AS23655 descr: advertised to AS24388 by SNAP Internet Ltd - AS23655 members: 132.181.0.0/16^16-29, 138.75.0.0/16^16-29, 153.111.0.0/16^16-29, 165.84.0.0/16^16-29, 123.255.0.0/18^18-29, 202.124.96.0/19^19-29, 203.86.192.0/20^20-29, 202.174.112.0/21^21-29, 210.5.48.0/21^21-29, 202.49.72.0/22^22-29, 202.49.92.0/22^22-29, 202.50.104.0/22^22-29, 202.50.124.0/22^22-29, 202.164.28.0/22^22-29, 202.27.186.0/23^23-29, 202.36.178.0/23^23-29, 202.36.220.0/23^23-29, 202.37.96.0/23^23-29, 202.37.100.0/23^23-29, 202.37.124.0/23^23-29, 202.49.90.0/23^23-29, 202.49.120.0/23^23-29, 210.55.30.0/23^23-29, 210.55.206.0/23^23-29, 192.148.221.0/24^24-29, 192.156.225.0/24^24-29, 202.36.163.0/24^24-29, 202.36.170.0/24^24-29, 202.36.219.0/24^24-29, 202.37.114.0/24^24-29, 202.49.115.0/24^24-29, 202.49.125.0/24^24-29, 202.49.187.0/24^24-29, 202.50.117.0/24^24-29, 202.50.169.0/24^24-29, 202.146.186.0/24^24-29, 203.96.112.0/24^24-29, 210.7.40.0/24^24-29, 210.54.15.0/24^24-29, 210.55.4.0/24^24-29, 210.55.7.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)snap.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20080618 source: NZRR ------------------------------------------------------------

1 0

NZRR Route Registry Update
by NZRR Database Notifications 17 Jun '08

17 Jun '08

Dear Colleague, This is to notify you that one or more objects in which you are designated for notification have been modified in the NZRR routing registry database. 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. Diagnostic output: ------------------------------------------------------------ --- PREVIOUS OBJECT: route-set: AS9560:RS-ROUTES:AS17492 descr: advertised to AS9560 by Vector Communications - AS17492 members: 202.126.192.0/20^20-29, 202.0.151.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: Patrick.Balmer(a)vector.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20060608 source: NZRR REPLACED BY: route-set: AS9560:RS-ROUTES:AS17492 descr: advertised to AS9560 by Vector Communications - AS17492 members: 202.126.192.0/20^20-29, 123.108.144.0/21^21-29, 202.0.151.0/24^24-29, 203.30.174.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: matt.oram(a)vector.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20080618 source: NZRR ------------------------------------------------------------

1 0

Issues with Woosh.
by Chris Hodgetts 16 Jun '08

16 Jun '08

Umm anyone at woosh know why at random times this week, packets are now no longer going through APE? 2 lns2.sky.woosh.net.nz (202.74.206.8) 243.850 ms 244.428 ms 244.435 ms 3 * * * 4 lnk-ww.atm-12-3-110.u12.brh.telstraclear.net (203.98.23.158) 244.511 ms 245.012 ms 245.278 ms 5 atm-12-3-110.u12.brh.telstraclear.net (203.98.23.157) 319.527 ms 319.764 ms 319.990 ms 6 ggis-gige-v906.telstraclear.net (203.98.18.67) 245.413 ms 242.277 ms 242.259 ms 7 g0-1-0-4.akcr8.global-gateway.net.nz (210.55.202.49) 242.251 ms 433.205 ms 433.255 ms 8 g0-1-0.tkcr3.global-gateway.net.nz (210.55.202.50) 433.652 ms 434.040 ms 434.509 ms 9 203.96.117.142 (203.96.117.142) 372.288 ms 372.789 ms 372.506 ms 10 60.234.9.8 (60.234.9.8) 435.538 ms 435.605 ms 380.208 ms Is woosh de-deeping, or is this just a redundant link? Must admit over 90% packet loss before it switches over to this route.

7 10

NZRR Route Registry Update
by NZRR Database Notifications 16 Jun '08

16 Jun '08

Dear Colleague, This is to notify you that one or more objects in which you are designated for notification have been modified in the NZRR routing registry database. 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. Diagnostic output: ------------------------------------------------------------ --- 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, 166.65.0.0/16^16-29, 119.15.0.0/19^19-29, 202.53.176.0/20^20-29, 202.191.32.0/20^20-29, 210.48.160.0/20^20-29, 120.89.80.0/21^21-29, 192.173.16.0/21^21-29, 202.46.176.0/21^21-29, 202.49.0.0/21^21-29, 202.78.240.0/21^21-29, 203.190.208.0/21^21-29, 202.37.48.0/22^22-29, 202.89.4.0/22^22-29, 202.124.106.0/23^23-29, 192.88.85.0/24^24-29, 192.122.171.0/24^24-29, 192.133.31.0/24^24-29, 192.195.219.0/24^24-29, 202.20.97.0/24^24-29, 202.36.33.0/24^24-29, 202.36.119.0/24^24-29, 202.36.162.0/24^24-29, 202.36.218.0/24^24-29, 202.46.190.0/24^24-29, 202.49.106.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 20080522 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, 166.65.0.0/16^16-29, 119.15.0.0/19^19-29, 202.53.176.0/20^20-29, 202.191.32.0/20^20-29, 210.48.160.0/20^20-29, 120.89.80.0/21^21-29, 192.173.16.0/21^21-29, 202.46.176.0/21^21-29, 202.49.0.0/21^21-29, 202.78.240.0/21^21-29, 203.190.208.0/21^21-29, 202.37.48.0/22^22-29, 202.89.4.0/22^22-29, 202.124.106.0/23^23-29, 192.88.85.0/24^24-29, 192.122.171.0/24^24-29, 192.133.31.0/24^24-29, 192.195.219.0/24^24-29, 202.20.97.0/24^24-29, 202.36.33.0/24^24-29, 202.36.119.0/24^24-29, 202.36.162.0/24^24-29, 202.36.218.0/24^24-29, 202.46.190.0/24^24-29, 202.49.106.0/24^24-29, 202.50.247.0/24^24-29, 202.55.105.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 20080617 source: NZRR ------------------------------------------------------------

1 0

NZRR Route Registry Update
by NZRR Database Notifications 16 Jun '08

16 Jun '08

Dear Colleague, This is to notify you that one or more objects in which you are designated for notification have been modified in the NZRR routing registry database. 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. Diagnostic output: ------------------------------------------------------------ --- 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, 166.65.0.0/16^16-29, 119.15.0.0/19^19-29, 202.53.176.0/20^20-29, 202.191.32.0/20^20-29, 210.48.160.0/20^20-29, 120.89.80.0/21^21-29, 192.173.16.0/21^21-29, 202.46.176.0/21^21-29, 202.49.0.0/21^21-29, 202.78.240.0/21^21-29, 203.190.208.0/21^21-29, 202.37.48.0/22^22-29, 202.89.4.0/22^22-29, 202.124.106.0/23^23-29, 192.88.85.0/24^24-29, 192.122.171.0/24^24-29, 192.133.31.0/24^24-29, 192.195.219.0/24^24-29, 202.20.97.0/24^24-29, 202.36.33.0/24^24-29, 202.36.119.0/24^24-29, 202.36.162.0/24^24-29, 202.36.218.0/24^24-29, 202.46.190.0/24^24-29, 202.49.106.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 20080522 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, 166.65.0.0/16^16-29, 119.15.0.0/19^19-29, 202.53.176.0/20^20-29, 202.191.32.0/20^20-29, 210.48.160.0/20^20-29, 120.89.80.0/21^21-29, 192.173.16.0/21^21-29, 202.46.176.0/21^21-29, 202.49.0.0/21^21-29, 202.78.240.0/21^21-29, 203.190.208.0/21^21-29, 202.37.48.0/22^22-29, 202.89.4.0/22^22-29, 202.124.106.0/23^23-29, 192.88.85.0/24^24-29, 192.122.171.0/24^24-29, 192.133.31.0/24^24-29, 192.195.219.0/24^24-29, 202.20.97.0/24^24-29, 202.36.33.0/24^24-29, 202.36.119.0/24^24-29, 202.36.162.0/24^24-29, 202.36.218.0/24^24-29, 202.46.190.0/24^24-29, 202.49.106.0/24^24-29, 202.50.247.0/24^24-29, 202.55.105.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 20080617 source: NZRR ------------------------------------------------------------

1 0

027 / Telecom Mobile
by Chris Hodgetts 11 Jun '08

11 Jun '08

Telecom Mobile seems to having some issues at the moment: With one test: Call 027 number - rings and rings , and never goes to answerphone Call same number - messages says the number is no longer valid, or they customer has put the account on hold Call same number - call gets placed and goes through. Messages to 027 and 026 also seems to be playing up. They are looking into it, just thought I would let people know here.

2 1

Reminder about APNIC 26 in Christchurch
by Philip Smith 11 Jun '08

11 Jun '08

Hi everyone, Just a reminder that APNIC 26 is taking place in Christchurch at the end of August. Included in APNIC 26 is the APOPS plenary - as with APRICOT, this is the main technical and operations plenary of APNIC 26, and it is where you all have an opportunity to talk about the latest exciting operational, technical or research activities you are involved in. If you are interested, please drop me an e-mail, or send an e-mail to policy(a)apnic.net. Please include the title of the proposed presentation, a short abstract, and how many minutes you require. The deadline for presentation submissions is 14th July, but we will operate a first submitted, first approved, first on the agenda policy, so the sooner you can submit your ideas, the greater the chances. Many thanks and hope to see you in Christchurch! philip -- (Original APNIC 26 announcement below) ________________________________________________________________________ APNIC 26 - Call for informational presentations ________________________________________________________________________ Dear colleagues Have you worked on some really interesting aspect of network operations that would help the larger Internet community? If so, why not give an informational presentation at APNIC 26? We are looking for informational presentations for both APOPS and SIG sessions: APOPS APOPS (Asia Pacific OperatorS Forum) showcases Internet operational content of wide interest to the Internet operations community. SIGs SIGs (Special Interest Groups) focus on a particular subject and provide an open public forum to discuss topics of interest to APNIC and the Internet community in the Asia Pacific region. How to submit your proposal --------------------------- Send a brief summary of your proposed presentation (two to four paragraphs) or set of presentation slides to: <policy(a)apnic.net> Deadlines --------- Submissions for presentation ideas close: 14 July 2008 Presentation slides due: 11 August 2008 More information ---------------- SIG archives and guidelines are available at: http://www.apnic.net/sigs Learn more about APNIC 26 at: http://www.apnic.net/meetings/26 We look forward to seeing you in Christchurch! Kind regards, Philip Smith, Hideo Ishii APOPS Chairs --

1 0

Telecom Looking Glass / Traceroute
by Dan Clark 08 Jun '08

08 Jun '08

Gidday, anyone got a web traceroute available on a Telecom domestic connection please? Regards Dan

1 0

OT - Fiji Broadband
by Nick 'Zaf' Clifford 06 Jun '08

06 Jun '08

Wrong country I know, but.... If anyone on the list has any experience/knowledge with broadband/ADSL in Fiji, please contact me off-list. <background> I have a client with a remote office in Fiji, its time to upgrade them from 2 tin cups and a piece of string to something faster. I will be heading over there in the next few weeks to configure up a VPN+Broadband router. </background> Thanks, Nick Clifford

1 0

Outage Notice for .nz International Name servers (NS5.DNS.NET.NZ and NS6.DNS.NET.NZ)
by DNS 04 Jun '08

04 Jun '08

Outage Notice for .nz International Name servers (NS5.DNS.NET.NZ and NS6.DNS.NET.NZ) Please note our supplier of the international .nz DNS service, NeuStar, will be doing some system upgrades starting at 09:00 NZST on Sunday June 8, ending at 21:00 NZST on Sunday June 8. (A total of 12 hours) During this maintenance window, zone transfers will not be processed by NS5.DNS.NET.NZ or NS6.DNS.NET.NZ. NeuStar do not anticipate utilizing the full maintenance window. DNS resolution from these servers will not be interrupted and they will serve data from the most recent zone file just prior to the beginning of the maintenance window. (The zone transferred to them at 08:00 NZST on Sunday June 8). If any emergency changes need to be made for your zones during this period, please contact NZRS using the out of hours number on our website. PLEASE NOTE The New Zealand based name servers (NS1,2,3,4 and 7) will not be affected by this outage and will continue to be updated hourly. Dave Baker .nz Registry Services support <at> nzrs.net.n

1 0

New IPv4 allocation for APNIC (112/8 and 113/8)
by Elly Tawhai 03 Jun '08

03 Jun '08

________________________________________________________________________ New IPv4 allocation for APNIC (112/8 and 113/8) ________________________________________________________________________ Dear colleagues The information in this announcement is to enable the Internet community to update network configurations, such as routing filters, where required. APNIC received the following IPv4 address blocks from IANA in May 2008 and will be making allocations from these ranges in the near future: 112/8 113/8 Reachability and routability testing of the new prefixes will commence soon. The daily report will be published at the usual URL: http://www.ris.ripe.net/debogon For more information on the resources administered by APNIC, please see: http://www.apnic.net/db/ranges.html For information on the minimum allocation sizes within address ranges administered by APNIC, please see: http://www.apnic.net/db/min-alloc.html Kind regards, ________________________________________________________________________ APNIC Secretariat Asia Pacific Network Information Centre (APNIC) Tel: +61-7-3858-3100 PO Box 2131 Milton, QLD 4064 Australia Fax: +61-7-3858-3199 Level 1, 33 Park Road, Milton, QLD http://www.apnic.net ________________________________________________________________________

1 0

www.nznog.org broken?
by Chris Hodgetts 03 Jun '08

03 Jun '08

Error establishing a database connection This either means that the username and password information in your wp-config.php file is incorrect or we can't contact the database server at localhost. This could mean your host's database server is down. * Are you sure you have the correct username and password? * Are you sure that you have typed the correct hostname? * Are you sure that the database server is running?

2 2

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

03 Jun '08

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. The group is intended to facilitate discussion among operators of networks in New Zealand on matters relevant to network operators as described in the list's Acceptable Use Policy. That policy appears later in this posting. Conference We hold New Zealand's only technical networking conference. See http://www.nznog.org/?page_id=4 (er, once it's been fixed) for details of conferences from 2004 to 2008. Work is now under way in preparation for the next conference, to be held in the North Island in late January 2009. Other Meetings See http://thursdaynightcurry.com/ if you live in or near Auckland, Hamilton or Wellington. Operators' Contact List See http://www.nznog.org/?page_id=6 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. About This Mailing List This list has between 900 and 1000 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 APN Online, Citylink, and The University of Waikato. 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 -- Donald Neal | "Careful design and strict discipline are Research Officer | necessary to prevent this sort of mess WAND | from escaping the development laboratory The University of Waikato | and infesting the production environment." | - D. Russell

1 0

NZRR Route Registry Update
by NZRR Database Notifications 02 Jun '08

02 Jun '08

Dear Colleague, This is to notify you that one or more objects in which you are designated for notification have been modified in the NZRR routing registry database. 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. Diagnostic output: ------------------------------------------------------------ --- PREVIOUS OBJECT: filter-set: fltr-unallocated descr: Unallocated (by IANA) IPv4 prefixes filter: {1.0.0.0/8^+, 2.0.0.0/8^+, 5.0.0.0/8^+, 14.0.0.0/8^+, 23.0.0.0/8^+, 27.0.0.0/8^+, 31.0.0.0/8^+, 36.0.0.0/8^+, 37.0.0.0/8^+, 39.0.0.0/8^+, 42.0.0.0/8^+, 46.0.0.0/8^+, 49.0.0.0/8^+, 50.0.0.0/8^+, 100.0.0.0/8^+, 101.0.0.0/8^+, 102.0.0.0/8^+, 103.0.0.0/8^+, 104.0.0.0/8^+, 105.0.0.0/8^+, 106.0.0.0/8^+, 107.0.0.0/8^+, 108.0.0.0/8^+, 109.0.0.0/8^+, 110.0.0.0/8^+, 111.0.0.0/8^+, 112.0.0.0/8^+, 113.0.0.0/8^+, 175.0.0.0/8^+, 176.0.0.0/8^+, 177.0.0.0/8^+, 178.0.0.0/8^+, 179.0.0.0/8^+, 180.0.0.0/8^+, 181.0.0.0/8^+, 182.0.0.0/8^+, 183.0.0.0/8^+, 184.0.0.0/8^+, 185.0.0.0/8^+, 197.0.0.0/8^+, 223.0.0.0/8^+} remarks: For the complete set of bogons, please see: fltr-martians - special use and reserved prefixes fltr-bogons - fltr-unallocated + fltr-martian Based on the work done at Team Cymru http://www.team-cymru.org/?sec=8&opt=25 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: radb(a)cymru.com notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz mnt-by: MAINT-BOGON-FILTERS changed: rpsl-admin(a)nzix.net 20040819 changed: rpsl-admin(a)nzix.net 20060113 changed: rpsl-admin(a)nzix.net 20060914 changed: rpsl-admin(a)nzix.net 20070716 changed: rpsl-admin(a)nzix.net 20080215 source: NZRR REPLACED BY: filter-set: fltr-unallocated descr: Unallocated (by IANA) IPv4 prefixes. filter: {1.0.0.0/8^+, 2.0.0.0/8^+, 5.0.0.0/8^+, 14.0.0.0/8^+, 23.0.0.0/8^+, 27.0.0.0/8^+, 31.0.0.0/8^+, 36.0.0.0/8^+, 37.0.0.0/8^+, 39.0.0.0/8^+, 42.0.0.0/8^+, 46.0.0.0/8^+, 49.0.0.0/8^+, 50.0.0.0/8^+, 100.0.0.0/8^+, 101.0.0.0/8^+, 102.0.0.0/8^+, 103.0.0.0/8^+, 104.0.0.0/8^+, 105.0.0.0/8^+, 106.0.0.0/8^+, 107.0.0.0/8^+, 108.0.0.0/8^+, 109.0.0.0/8^+, 110.0.0.0/8^+, 111.0.0.0/8^+, 175.0.0.0/8^+, 176.0.0.0/8^+, 177.0.0.0/8^+, 178.0.0.0/8^+, 179.0.0.0/8^+, 180.0.0.0/8^+, 181.0.0.0/8^+, 182.0.0.0/8^+, 183.0.0.0/8^+, 184.0.0.0/8^+, 185.0.0.0/8^+, 197.0.0.0/8^+, 223.0.0.0/8^+} admin-c: Rob Thomas RT624 tech-c: Rob Thomas RT624 remarks: For the complete set of bogons, please see:
fltr-martian - special use and reserved prefixes.
fltr-bogons - fltr-unallocated + fltr-martian.
http://www.cymru.com/Documents/bogon-list.html notify: noc(a)cymru.com mnt-by: MAINT-BOGON-FILTERS changed: radb(a)cymru.com 20021229 changed: radb(a)cymru.com 20021230 changed: radb(a)cymru.com 20030213 changed: radb(a)cymru.com 20030404 changed: radb(a)cymru.com 20030406 changed: radb(a)cymru.com 20030408 changed: radb(a)cymru.com 20030606 changed: radb(a)cymru.com 20031117 #16:08:32(UTC) changed: radb(a)cymru.com 20040116 #07:17:57(UTC) changed: radb(a)cymru.com 20040401 #22:29:46(UTC) changed: radb(a)cymru.com 20040428 #18:27:34(UTC) changed: radb(a)cymru.com 20040803 #05:43:18(UTC) changed: radb(a)cymru.com 20050129 #11:48:46(UTC) changed: radb(a)cymru.com 20050330 #23:14:55(UTC) changed: radb(a)cymru.com 20050413 #06:12:46(UTC) changed: radb(a)cymru.com 20050618 #04:07:01(UTC) changed: radb(a)cymru.com 20050701 #06:18:28(UTC) changed: radb(a)cymru.com 20060105 #20:45:57(UTC) changed: radb(a)cymru.com 20061013 #18:41:19(UTC) changed: radb(a)cymru.com 20061122 #14:51:27(UTC) changed: radb(a)cymru.com 20061227 #03:31:18(UTC) changed: radb(a)cymru.com 20070128 #22:04:23(UTC) changed: radb(a)cymru.com 20070411 #18:20:12(UTC) changed: radb(a)cymru.com 20070603 #04:48:23(UTC) changed: radb(a)cymru.com 20070726 #15:53:57(UTC) changed: radb(a)cymru.com 20071002 #15:48:55(UTC) changed: radb(a)cymru.com 20071002 #16:45:21(UTC) changed: radb(a)cymru.com 20071029 #16:50:49(UTC) changed: radb(a)cymru.com 20071105 #23:37:09(UTC) changed: radb(a)cymru.com 20071105 #23:44:41(UTC) changed: radb(a)cymru.com 20080125 #18:37:51(UTC) changed: radb(a)cymru.com 20080214 #20:21:40(UTC) changed: radb(a)cymru.com 20080527 #23:12:28Z changed: noc(a)cymru.com 20080529 #15:52:05Z changed: rpsl-admin(a)nzix.net 20080603 source: NZRR ------------------------------------------------------------

1 0

ReArch'08 and ACM CoNext 2008 CFPs
by Brian E Carpenter 29 May '08

29 May '08

Please excuse duplicates, and apologies if this seems too much like spam. Regards Brian Carpenter University of Auckland -------- Original Message -------- Subject: [Re-Arch'08] ReArch'08 Call For Papers Date: Thu, 29 May 2008 12:30:10 -0400 From: EDAS <help(a)edas-help.com> To: Brian Carpenter <brian.e.carpenter(a)gmail.com> ReArch’08 - Re-Architecting the Internet “Exploring what is broken with the Internet architecture and how to fix it.” Madrid, Spain 9 December, 2008 co-located with ACM CoNEXT'2008 sponsored by ACM Sigcomm http://www.sigcomm.org/co-next2008/rearch.html Motivation The Internet architecture has been remarkably successful in allowing a planet-scale internetwork to form. However, this architecture is losing its original simplicity and transparency as new classes of applications, operational and management requirements, business models, security mechanisms and scalability enablers give rise to point solutions that extend the architecture without regard to the original design principles. While these mechanisms are necessary for Internet operation under current economical, technical and social conditions, their combination has significantly reduced the potential for incremental evolution of the Internet architecture. This loss of flexibility is already being felt as the number of Internet nodes grows by another order of magnitude. Several substantial Future Internet initiatives have started in Europe, the US and Asia, and the vendor and network operator communities are also actively discussing the limitations of the current Internet architecture as well as its potential evolution. This workshop will discuss what the real underlying problems are with the Internet and how we might fix them so that the Internet architecture re-gains its simplicity and transparency and is fit for another 30+ years, so that the architectural simplicity and clarity of the Internet can be regained and retained for another 30+ years. This workshop solicits original, high-quality papers that analyze, and discuss ideas for a new Internet architecture, including specific improvements to current Internet protocols, especially at the internetworking, transport and application layers, new internetworking components that integrate into the existing architecture and ideas for clean-slate internetworking architectures. Topics ReArch'08 covers all aspects related to the current and future Internet architecture including, but not limited to, how the following impact on that architecture: New networking paradigms New business models New routing architectures New traffic engineering and congestion control mechanisms Measurements and analysis that characterize the real architectural limitations New architecture proposals and their implications for research New protocols that address the limitations Studies of interactions between stakeholders of the Internet and the architecture itself Design principles and interfaces to accommodate the conflicting interests of stakeholders in the architecture Principles of evolving future architectures Requirements for interworking with the existing Internet, and for deployability. Papers that present interesting, fresh ideas at an early stage are more suitable for this workshop than highly polished results or incremental refinements of previous work. Submissions may include position papers that point out new directions and stimulate discussion; position papers should be clearly marked. Submissions must be original and not already published in any other conference proceedings or journal. Proceedings of the workshop will be published in the ACM Digital Library. Submissions Submitted papers must be at most 6 pages long (including figures, tables, references, etc.) in the standard ACM double column format. All text must use font sizes of 10 points or larger. Longer submissions will not be reviewed. The review process is single-blind. Submissions will be done via EDAS. Submission Deadline: 15 August 2008 Notification: 10 October 2008 Workshop Co-Chairs Olivier Bonaventure - UCLouvain Marcelo Bagnulo - UC3M Joe Touch - USC/ISI Technical Program Committee Mark Allman ICIR Jari Arkko Ericsson Bob Briscoe BT Group Ken Calvert University of Kentucky Brian Carpenter University of Auckland Maoke Chen Tsinghua University Kenjiro Cho IIJ Jon Crowcroft University of Cambridge Philip Eardley BT Group Lars Eggert Nokia Research Center Kevin Fall Intel Research Pierre Francois UCLouvain Robert Hancock Roke Manor Research Mark Handley University College London Christian Huitema Microsoft Daniel Massey Colorado State University Martin May ETH Zurich Pekka Nikander Ericsson Research Nomadiclab Craig Partridge BBN Technologies Peter Steenkiste Carnegie Mellon University Iljitsch van Beijnum IMDEA Metworks Tilman Wolf University of Massachusetts -------- Original Message -------- Subject: [ACM CoNext 2008] ACM CoNext 2008 CFP Date: Thu, 29 May 2008 04:56:53 -0400 From: EDAS <help(a)edas-help.com> To: Brian Carpenter <brian.e.carpenter(a)gmail.com> [We apologize in advance if you receive multiple copies of this message] [Please distribute it where you feel appropriate] ========================================================================== ACM CoNEXT 2008: Call for Papers The 4th ACM International Conference on emerging Networking EXperiments and Technologies (ACM CoNEXT 2008) Organized by IMDEA Networks and University Carlos III of Madrid, sponsored by ACM SIGCOMM 9-12 December 2008 Leganes, Madrid, SPAIN http://www.co-next.net CALL FOR PAPERS The 4th ACM International Conference on emerging Networking EXperiments and Technologies (ACM CoNEXT), to be held in Madrid, will have the primary goal of promoting stimulating exchanges between various international research communities. The main conference will be preceded by a one-day workshop, and will be a major forum for presentations and discussions of novel networking technologies that will shape the future of Internetworking. The conference is single-track and will feature a high-quality technical program with significant opportunities for individual and small-group technical and social interactions. ACM CoNEXT seeks to foster open discussions on technology alternatives and to be a forum accommodating multiple viewpoints, and is committed to a fair, timely, and thorough review process providing authors of submitted papers with sound and detailed feedback. As its name suggests, ACM CoNEXT 2008 solicits papers on emerging networking experiments, measurements, paradigms, with particular emphasis on creative, out-of-the-box thinking. Additionally, papers reporting on the deployment and performance of services or exploring network functionality aimed at better supporting new services are also welcome. We welcome submissions based on implementation and experimentation, as well as simulation and analytical approaches. Relevant topics for the conference include, but are not limited to the following: o Internet measurement and modeling o Wireless and mobile networks o Ad hoc and sensors networks o Economic aspects of the Internet o Network security issues o Multimedia networking o Peer-to-peer and overlay networks o Routing and traffic engineering o Delay and disruption tolerant networks o New networking protocols and architectures o Autonomic and dependable communications o Networked systems applications and services SUBMISSION INSTRUCTIONS Submissions must be original, unpublished work, and not under consideration at another conference or journal. Conformance to the 12 pages, 10pts ACM SIGCOMM format will be strictly enforced. Electronic proceedings will be published by ACM, and the best papers forwarded to the IEEE/ACM Transactions on Networking for possible fast-track publication. Travel grants will be available to support student attendance at the conference. IMPORTANT DATES Abstract submission deadline: 30th June 2008 Submission Deadline: 7th July 2008 Notification: 25th September 2008 Conference Chairs Arturo Azcorra, U. Carlos III and IMDEA Networks, Spain Gustavo de Veciana, U. Texas at Austin, USA Program Chairs Keith W. Ross, Polytechnic University, USA Leandros Tassiulas, University of Thessaly, Greece Steering Committee Arturo Azcorra, U. Carlos III and IMDEA Networks, Spain Kenjiro Cho, IIJ Research Labs, Japan Serge Fdida, Universiy Pierre and Marie Curie, France Roch Guιrin, University of Pennsylvania, USA Jim Kurose, University of Massachusetts, USA Laurent Mathy, Lancaster University, UK Publications Chair Hassnaa Moustafa, France Telecom R&D (Orange Labs), France Local Arrangements Chairs Maria Calderon, U. Carlos III, Spain Carlos J. Bernardos, U. Carlos III, Spain ===========================================================================

1 0

112/8 and 113/8 allocated to APNIC
by Leo Vegoda 28 May '08

28 May '08

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, The IANA IPv4 registry has been updated to reflect the allocation of two /8 IPv4 blocks to APNIC in May 2008: 112/8 and 113/8. You can find the IANA IPv4 registry at: http://www.iana.org/assignments/ipv4-address-space We have also updated the Sample XML Registry for IPv4 Address Space, which can be found at: http://www.iana.org/reports/2008/xml-registry-sample.html Please update your filters as appropriate. Regards, Leo Vegoda Manager, Number Resources - IANA -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) iD8DBQFIPpkqvBLymJnAzRwRAgsYAJ9b7EumlIisvK2HvYuIpcnACzYr/wCgwS1s Km3F9ujlFdL9VbXPVTghWsU= =FcpK -----END PGP SIGNATURE-----

1 0

Email issues from users of the global-gateway
by Chris Hodgetts 28 May '08

28 May '08

Hello We have reports today (starting at about 3am this morning) that mail is being rejected by us. Postfix errors out: May 29 14:15:22 app02 postfix/smtpd[22437]: lost connection after DATA from [host here] I can only see 4 companies so far today that have been having issues, but the common factor is they all are connected to global-gateway.net.nz Is anyone else seeing similar issues, am I being too simplistic in saying they are all connected there, but at the moment that's the common thread. Many[1] other uses who are successfully sending are not going through them. [1] Many because I have not checked all obviously

2 3

DROA
by Tim John - Domainz 28 May '08

28 May '08

To Registrars and domain name agents. Heads up ... Domain Registry of America (DROA) appear to be sending out bogus renewal notices again. We've had several queries from customers today and had one or two 'renewal invoices' ourselves. It seems they are targeting people with .nz names but offering the same third level with a gTLD extension. FYI, Domain Registry of America operate out of Melbourne, AU. Funny that ! Regards, Tim

1 0

XTRA(yahoo) automatically tagging legitimate mail as Spam
by Michael Hutchinson 28 May '08

28 May '08

Hi All, We are currently having an issue with one of our Exchange servers sending email to user mailboxes on Xtra. We have tracked the email leaving the server, and have EventID's from logs on the Exchange server telling us that delivery is successful. However, when we log into any of the Xtra mail accounts, we can see the emails are automatically being put into the Spam folder of those accounts. There is nothing about the emails to suggest they are spam, and the final received headers say nothing about Spam, let alone even that it has been checked for Spam. As far as I can see it is only affecting one of our domains. We have several other domains with exchange servers that deliver to Xtra mailboxes just fine. I have contacted support at Xtra about this, as well as Ted Grenfell (who got back to me straight away) and we're trying to collate enough data to attack the problem. Is anyone else having this issue? (It would be nice to know that we're not the only ones being picked on by Yahoo.) Cheers, Michael Hutchinson Manux Solutions Ltd

18 26

NZRR Route Registry Update
by NZRR Database Notifications 28 May '08

28 May '08

Dear Colleague, This is to notify you that one or more objects in which you are designated for notification have been modified in the NZRR routing registry database. 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. Diagnostic output: ------------------------------------------------------------ --- PREVIOUS OBJECT: route-set: AS9560:RS-ROUTES:AS4770 descr: advertised to AS9560 by ICONZ - AS4770 members: 210.48.0.0/17^17-29, 210.185.0.0/18^18-29, 210.54.160.0/19^19-29, 202.55.96.0/20^20-29, 202.174.160.0/20^20-29, 210.56.32.0/20^20-29, 117.18.80.0/21^21-29, 202.12.248.0/21^21-29, 202.37.144.0/21^21-29, 202.37.224.0/21^21-29, 202.74.224.0/21^21-29, 202.78.240.0/21^21-29, 205.233.128.0/21^21-29, 202.36.36.0/22^22-29, 202.37.140.0/22^22-29, 202.37.200.0/22^22-29, 202.41.136.0/22^22-29, 203.80.60.0/22^22-29, 210.54.136.0/22^22-29, 210.55.24.0/22^22-29, 199.212.92.0/23^23-29, 202.21.136.0/23^23-29, 202.36.44.0/23^23-29, 202.36.76.0/23^23-29, 202.37.240.0/23^23-29, 202.37.252.0/23^23-29, 202.61.2.0/23^23-29, 202.174.6.0/23^23-29, 205.233.136.0/23^23-29, 192.88.85.0/24^24-29, 192.107.113.0/24^24-29, 198.32.66.0/24^24-29, 202.6.84.0/24^24-29, 202.12.70.0/24^24-29, 202.14.100.0/24^24-29, 202.20.6.0/24^24-29, 202.21.130.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.37.57.0/24^24-29, 202.37.73.0/24^24-29, 202.37.76.0/24^24-29, 202.37.85.0/24^24-29, 202.37.163.0/24^24-29, 202.37.232.0/24^24-29, 202.46.190.0/24^24-29, 202.49.62.0/24^24-29, 202.49.89.0/24^24-29, 202.49.159.0/24^24-29, 202.49.249.0/24^24-29, 202.50.87.0/24^24-29, 202.50.139.0/24^24-29, 205.233.243.0/24^24-29, 210.54.140.0/24^24-29, 210.54.211.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: deon(a)iconz.net mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20080318 source: NZRR REPLACED BY: route-set: AS9560:RS-ROUTES:AS4770 descr: advertised to AS9560 by ICONZ - AS4770 members: 210.48.0.0/17^17-29, 210.185.0.0/18^18-29, 210.54.160.0/19^19-29, 202.55.96.0/20^20-29, 202.174.160.0/20^20-29, 210.56.32.0/20^20-29, 117.18.80.0/21^21-29, 120.138.16.0/21^21-29, 202.12.248.0/21^21-29, 202.37.144.0/21^21-29, 202.37.224.0/21^21-29, 202.74.224.0/21^21-29, 202.78.240.0/21^21-29, 205.233.128.0/21^21-29, 202.36.36.0/22^22-29, 202.37.140.0/22^22-29, 202.37.200.0/22^22-29, 202.41.136.0/22^22-29, 203.80.60.0/22^22-29, 210.54.136.0/22^22-29, 210.55.24.0/22^22-29, 199.212.92.0/23^23-29, 202.21.136.0/23^23-29, 202.36.44.0/23^23-29, 202.36.76.0/23^23-29, 202.37.240.0/23^23-29, 202.37.252.0/23^23-29, 202.61.2.0/23^23-29, 202.174.6.0/23^23-29, 205.233.136.0/23^23-29, 192.88.85.0/24^24-29, 192.107.113.0/24^24-29, 198.32.66.0/24^24-29, 202.6.84.0/24^24-29, 202.12.70.0/24^24-29, 202.14.100.0/24^24-29, 202.20.6.0/24^24-29, 202.21.130.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.37.57.0/24^24-29, 202.37.73.0/24^24-29, 202.37.76.0/24^24-29, 202.37.85.0/24^24-29, 202.37.163.0/24^24-29, 202.46.190.0/24^24-29, 202.49.62.0/24^24-29, 202.49.89.0/24^24-29, 202.49.159.0/24^24-29, 202.49.249.0/24^24-29, 202.50.87.0/24^24-29, 202.50.139.0/24^24-29, 205.233.243.0/24^24-29, 210.54.140.0/24^24-29, 210.54.211.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: deon(a)iconz.net mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20080529 source: NZRR ------------------------------------------------------------

1 0

NZRR Route Registry Update
by NZRR Database Notifications 22 May '08

22 May '08

Dear Colleague, This is to notify you that one or more objects in which you are designated for notification have been modified in the NZRR routing registry database. 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. Diagnostic output: ------------------------------------------------------------ --- PREVIOUS OBJECT: route-set: AS9560:RS-ROUTES:AS18119 descr: advertised to AS9560 by ACSData - AS18119 members: 202.46.160.0/20^20-29, 117.18.80.0/21^21-29, 202.126.80.0/21^21-29, 202.21.136.0/23^23-29, 202.61.2.0/23^23-29, 192.107.113.0/24^24-29, 202.36.44.0/24^24-29, 202.49.144.0/24^24-29, 202.49.249.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: lincoln(a)acsdata.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20070706 source: NZRR REPLACED BY: route-set: AS9560:RS-ROUTES:AS18119 descr: advertised to AS9560 by ACSData - AS18119 members: 202.46.160.0/20^20-29, 114.110.32.0/21^21-29, 117.18.80.0/21^21-29, 202.126.80.0/21^21-29, 202.21.136.0/23^23-29, 202.61.2.0/23^23-29, 192.107.113.0/24^24-29, 202.36.44.0/24^24-29, 202.49.144.0/24^24-29, 202.49.249.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: lincoln(a)acsdata.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20080523 source: NZRR ------------------------------------------------------------

1 0

NZRR Route Registry Update
by NZRR Database Notifications 22 May '08

22 May '08

Dear Colleague, This is to notify you that one or more objects in which you are designated for notification have been modified in the NZRR routing registry database. 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. Diagnostic output: ------------------------------------------------------------ --- PREVIOUS OBJECT: route-set: AS9439:RS-ROUTES:AS18119 descr: advertised to AS9439 by ACSData - AS18119 members: 202.46.160.0/20^20-29, 117.18.80.0/21^21-29, 202.126.80.0/21^21-29, 202.21.136.0/23^23-29, 202.61.2.0/23^23-29, 192.107.113.0/24^24-29, 202.36.44.0/24^24-29, 202.49.144.0/24^24-29, 202.49.249.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: lincoln(a)acsdata.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20070706 source: NZRR REPLACED BY: route-set: AS9439:RS-ROUTES:AS18119 descr: advertised to AS9439 by ACSData - AS18119 members: 202.46.160.0/20^20-29, 114.110.32.0/21^21-29, 117.18.80.0/21^21-29, 202.126.80.0/21^21-29, 202.21.136.0/23^23-29, 202.61.2.0/23^23-29, 192.107.113.0/24^24-29, 202.36.44.0/24^24-29, 202.49.144.0/24^24-29, 202.49.249.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: lincoln(a)acsdata.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20080523 source: NZRR ------------------------------------------------------------

1 0

2mbps symmetric VSAT for Disaster Recovery
by Jonathan Brewer 22 May '08

22 May '08

Hi Folks, We're looking for anyone out there with 2mbps symmetric VSAT (or even an asymmetric service with minimum 2mbps up) that could be used for disaster recovery purposes. The link will sit idle until something major happens, and then will need to be turned up and used immediately. After checking with all the usual suspects, I was disappointed by all. None of the quotes I have received to date have had more than 1mbps contested upload. Anyone out there know something I don't? Thanks, Jon

1 0

NZRR Route Registry Update
by NZRR Database Notifications 21 May '08

21 May '08

Dear Colleague, This is to notify you that one or more objects in which you are designated for notification have been modified in the NZRR routing registry database. 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. Diagnostic output: ------------------------------------------------------------ --- 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, 166.65.0.0/16^16-29, 119.15.0.0/19^19-29, 202.53.176.0/20^20-29, 202.191.32.0/20^20-29, 210.48.160.0/20^20-29, 116.90.128.0/21^21-29, 120.89.80.0/21^21-29, 192.173.16.0/21^21-29, 202.46.176.0/21^21-29, 202.49.0.0/21^21-29, 202.78.240.0/21^21-29, 203.190.208.0/21^21-29, 202.37.48.0/22^22-29, 202.89.4.0/22^22-29, 202.6.116.0/23^23-29, 202.124.106.0/23^23-29, 192.88.85.0/24^24-29, 192.122.171.0/24^24-29, 192.133.31.0/24^24-29, 192.195.219.0/24^24-29, 202.20.97.0/24^24-29, 202.36.33.0/24^24-29, 202.36.119.0/24^24-29, 202.36.162.0/24^24-29, 202.36.218.0/24^24-29, 202.46.190.0/24^24-29, 202.49.106.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 20080407 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, 166.65.0.0/16^16-29, 119.15.0.0/19^19-29, 202.53.176.0/20^20-29, 202.191.32.0/20^20-29, 210.48.160.0/20^20-29, 120.89.80.0/21^21-29, 192.173.16.0/21^21-29, 202.46.176.0/21^21-29, 202.49.0.0/21^21-29, 202.78.240.0/21^21-29, 203.190.208.0/21^21-29, 202.37.48.0/22^22-29, 202.89.4.0/22^22-29, 202.124.106.0/23^23-29, 192.88.85.0/24^24-29, 192.122.171.0/24^24-29, 192.133.31.0/24^24-29, 192.195.219.0/24^24-29, 202.20.97.0/24^24-29, 202.36.33.0/24^24-29, 202.36.119.0/24^24-29, 202.36.162.0/24^24-29, 202.36.218.0/24^24-29, 202.46.190.0/24^24-29, 202.49.106.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 20080522 source: NZRR ------------------------------------------------------------

1 0

NZRR Route Registry Update
by NZRR Database Notifications 21 May '08

21 May '08

Dear Colleague, This is to notify you that one or more objects in which you are designated for notification have been modified in the NZRR routing registry database. 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. Diagnostic output: ------------------------------------------------------------ --- 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, 166.65.0.0/16^16-29, 119.15.0.0/19^19-29, 202.53.176.0/20^20-29, 202.191.32.0/20^20-29, 210.48.160.0/20^20-29, 116.90.128.0/21^21-29, 120.89.80.0/21^21-29, 192.173.16.0/21^21-29, 202.46.176.0/21^21-29, 202.49.0.0/21^21-29, 202.78.240.0/21^21-29, 203.190.208.0/21^21-29, 202.37.48.0/22^22-29, 202.89.4.0/22^22-29, 202.6.116.0/23^23-29, 202.124.106.0/23^23-29, 192.88.85.0/24^24-29, 192.122.171.0/24^24-29, 192.133.31.0/24^24-29, 192.195.219.0/24^24-29, 202.20.97.0/24^24-29, 202.36.33.0/24^24-29, 202.36.119.0/24^24-29, 202.36.162.0/24^24-29, 202.36.218.0/24^24-29, 202.46.190.0/24^24-29, 202.49.106.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 20080407 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, 166.65.0.0/16^16-29, 119.15.0.0/19^19-29, 202.53.176.0/20^20-29, 202.191.32.0/20^20-29, 210.48.160.0/20^20-29, 120.89.80.0/21^21-29, 192.173.16.0/21^21-29, 202.46.176.0/21^21-29, 202.49.0.0/21^21-29, 202.78.240.0/21^21-29, 203.190.208.0/21^21-29, 202.37.48.0/22^22-29, 202.89.4.0/22^22-29, 202.124.106.0/23^23-29, 192.88.85.0/24^24-29, 192.122.171.0/24^24-29, 192.133.31.0/24^24-29, 192.195.219.0/24^24-29, 202.20.97.0/24^24-29, 202.36.33.0/24^24-29, 202.36.119.0/24^24-29, 202.36.162.0/24^24-29, 202.36.218.0/24^24-29, 202.46.190.0/24^24-29, 202.49.106.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 20080522 source: NZRR ------------------------------------------------------------

1 0

Asia-Pacific Advanced Networking Conference
by Donald Neal 20 May '08

20 May '08

1 0

NZRR Route Registry Update
by NZRR Database Notifications 15 May '08

15 May '08

Dear Colleague, This is to notify you that one or more objects in which you are designated for notification have been modified in the NZRR routing registry database. 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. Diagnostic output: ------------------------------------------------------------ --- PREVIOUS OBJECT: route-set: AS9560:RS-ROUTES:AS17746 descr: advertised to AS9560 by Orcon Internet Ltd - AS17746 members: 60.234.0.0/16^16-29, 121.98.0.0/16^16-29, 156.62.0.0/16^16-29, 202.150.96.0/19^19-29, 203.99.0.0/19^19-29, 203.96.192.0/20^20-29, 219.88.128.0/20^20-29, 219.88.240.0/20^20-29, 116.199.208.0/21^21-29, 210.54.56.0/21^21-29, 210.79.48.0/21^21-29, 202.127.8.0/22^22-29, 210.54.148.0/22^22-29, 210.55.12.0/22^22-29, 202.37.82.0/23^23-29, 202.175.142.0/23^23-29, 203.84.134.0/23^23-29, 192.203.216.0/24^24-29, 202.27.77.0/24^24-29, 202.36.170.0/24^24-29, 202.37.19.0/24^24-29, 202.37.173.0/24^24-29, 202.37.194.0/24^24-29, 202.49.187.0/24^24-29, 202.49.233.0/24^24-29, 202.49.246.0/24^24-29, 202.50.167.0/24^24-29, 202.50.246.0/24^24-29, 202.174.160.0/24^24-29, 203.86.200.0/24^24-29, 210.54.12.0/24^24-29, 210.55.1.0/24^24-29, 210.55.8.0/24^24-29, 210.55.199.0/24^24-29, 202.27.188.128/25^25-29, 210.55.0.0/25^25-29, 210.55.180.128/26^26-29, 210.55.193.64/27^27-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: ricky.tipper(a)team.orcon.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20080227 source: NZRR REPLACED BY: route-set: AS9560:RS-ROUTES:AS17746 descr: advertised to AS9560 by Orcon Internet Limited - AS17746 members: 60.234.0.0/16^16-29, 121.98.0.0/16^16-29, 156.62.0.0/16^16-29, 202.150.96.0/19^19-29, 203.99.0.0/19^19-29, 203.96.192.0/20^20-29, 219.88.128.0/20^20-29, 219.88.240.0/20^20-29, 116.199.208.0/21^21-29, 120.136.48.0/21^21-29, 210.54.56.0/21^21-29, 210.79.48.0/21^21-29, 202.127.8.0/22^22-29, 210.54.148.0/22^22-29, 210.55.12.0/22^22-29, 202.37.82.0/23^23-29, 202.175.142.0/23^23-29, 203.84.134.0/23^23-29, 192.203.216.0/24^24-29, 202.27.77.0/24^24-29, 202.36.170.0/24^24-29, 202.37.19.0/24^24-29, 202.37.173.0/24^24-29, 202.37.194.0/24^24-29, 202.49.187.0/24^24-29, 202.49.233.0/24^24-29, 202.49.246.0/24^24-29, 202.50.167.0/24^24-29, 202.50.246.0/24^24-29, 202.174.160.0/24^24-29, 203.86.200.0/24^24-29, 210.54.12.0/24^24-29, 210.55.1.0/24^24-29, 210.55.8.0/24^24-29, 210.55.199.0/24^24-29, 202.27.188.128/25^25-29, 210.55.0.0/25^25-29, 210.55.180.128/26^26-29, 210.55.193.64/27^27-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: benny.treefoot(a)team.orcon.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20080516 source: NZRR ------------------------------------------------------------

1 0

Re: [nznog] ip ranges
by Anton Smith 15 May '08

15 May '08

> > From: Nathan Ward <nznog(a)daork.net> > Subject: Re: [nznog] ip ranges > To: nznog <NZNOG(a)list.waikato.ac.nz> > Message-ID: <D35CD246-4629-40DB-B460-171B46B9B877(a)daork.net> > Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes > > On 14/05/2008, at 4:49 PM, Vaafuti Alauni (Vaa) wrote: > > > Thanks guys for your fast responses, > > > > some sites some of our customers are having troubles with are : > > sites within tv3.co.nz (doubleclick.net) > > sites within tvone.co.nz (tvoneondemand.co.nz) > > some links in yellow.co.nz and white pages. > > > > the specific ranges that our customers sourcing from is the > > 202.68.86.0/23 > > > Your customers are complaining about not being able to see > advertisements on the TV3 website? :-) > > Looks to me like your BGP advertisements are a bit wierd, but it's > hard to be sure from where I'm sitting. > For example, WIX has 202.68.86/24, and 202.68.87/24. Why are you not > advertising that as a /23? > > APE doesn't have either prefix, or the /23. It does seem to have > 202.68.94/23 though, which is in your /19. > > Both appear internationally as /24s, no /23 - this means that those > other NZ networks /should/ see your traffic, unless you have some kind > of filtering in place. You don't have strict RPF or anything do you? > > Do you have routes to reach those networks? I assume so, if you're > able to reach them from some of your prefixes. > > I also notice that subnets of 202.68.87/24 appear on WIX - a /27 and > a /28. Are these the customers that are having problems? > > Aggregation would be good while we're at it: > http://www.cidr-report.org/cgi-bin/as-report?as=AS24183&view=2.0 I wonder if those sites are with (or transited by) telstraclear, I remember their transparent proxy causes problems similar to this in our network at times. I think it might even have been you (Nathan) that pointed out its existence to me :). I ran into problems with it by advertising more specific prefixes at WIX. Since we got rid of that it seems to be okay. Regards, Anton

2 1