- NZNOG - lists.nznog.org

I-Root available on WIX
by Dylan Hall 19 Jan '09

19 Jan '09

Citylink is pleased to announce that the i-root name servers are now being anycast on the WIX. They are announcing the ranges to the route servers at present. Anyone interested in a private peering session can contact Autonomica directly (please provide the following information): AS: 8674 WEL IP's: 202.7.0.209 AND 202.7.0.210 Macro: AS-NETNOD-ANYCAST Contact: peering(a)netnod.se

1 0

Re: [nznog] enum
by Michael Sutton 15 Jan '09

15 Jan '09

FYI. So now who will be the next who dares to request our Country's delegation and be denied and how many more years will New Zealand wait before those that decide policy realize that there is a national opportunity cost to their inaction. Sincerely Michael Sutton -----Original Message----- From: enum-announce-admin(a)ripe.net [mailto:enum-announce-admin(a)ripe.net] On Behalf Of RIPE NCC Staff Sent: Wednesday, 14 January 2009 11:58 p.m. To: james(a)freedomnet.co.nz Cc: enum-announce(a)ripe.net Subject: [enum-announce] Fw: NCC#2008124814 [RE: [Re: enum request for 4.6.e164.arpa - correction]] Dear James, the RIPE NCC has received the following answer from ITU-T TSB and therefore will not delegate the zone as you have requested. Kind regards, Marco Schmidt RIPE NCC ----- Begin forwarded message ----- Date: Wed, 14 Jan 2009 11:36:46 +0100 From: <richard.hill(a)itu.int> To: <enum-request(a)ripe.net> Subject: RE: NCC#2008124814 [Re: enum request for 4.6.e164.arpa - correction] Message-Id: <334A4109C6BEA14ABB48EBCF274A6C8A03D79119(a)MAILBOX1.blue.itu.ch> The ITU Telecommunications Standardization Bureau (TSB) objects to this request because no approval for delegation of the code 64 has been received from the concerned country, New Zealand. Until formal approval is given in writing by the Director of TSB, no delegation should take place for this code. Richard Hill ----------------------------------------- Richard Hill Counsellor, ITU-T SG2 and SG3 International Telecommunication Union Place des Nations CH-1211 Geneva 20 Switzerland > -----Original Message----- > From: RIPE NCC Staff [mailto:enum-request(a)ripe.net] > Sent: Wednesday, December 24, 2008 8:56 AM > To: enum-announce(a)ripe.net; Hill, Richard > Subject: Fw: NCC#2008124814 [Re: enum request for 4.6.e164.arpa - > correction] > > ----- Begin forwarded message ----- > > Date: Wed, 24 Dec 2008 09:26:34 +1300 > From: "James Jones" <james(a)freedomnet.co.nz> > To: enum(a)ripe.net, enum-request(a)ripe.net > Subject: Re: NCC#2008124814 enum request for 4.6.e164.arpa - correction > Message-Id: <6104c3e30812231226h190be2b0p15f4fa71fa744983(a)mail.gmail.com> > > > % ENUM Request Form > > % You can use this form to request ENUM delegation of an E.164 country > code. % Submit the completed form to <enum-request(a)ripe.net>. > % Please see ripe-385 for instructions on how to complete this form. > > #[GENERAL INFORMATION]# > % > % Please do not change the value of the two fields below. > > request-type: enum > form-version: 1.0 > > #[REQUESTER DETAILS]# > % > % Please add your contact details. > > name: James Jones > phone: +6421763939 > fax-no: > e-mail: james(a)freedomnet.co.nz > > #[ORGANISATION DETAILS]# > % > % Which organisation is requesting the delegation? > > legal-organisation-name: Freedom Networks Limited > organisation-location: Levin, New Zealand > website: http://www.freedomnet.co.nz > > #[DATABASE TEMPLATE]# > % > % Please complete all of the fields below. > > domain: 4.6.e164.arpa > descr: Freedom Networks Limited > org: ORG-FNL5-RIPE > admin-c: JJN15-RIPE > tech-c: JJN15-RIPE > zone-c: JJN15-RIPE > nserver: enum1.freedomnet.co.nz > nserver: enum2.freedomnet.co.nz > mnt-by: Freedom_Networks > changed: james(a)freedomnet.co.nz 20081223 > source: RIPE > > #[SUPPLEMENTAL COMMENTS]# > % > % Please add more information if you think it will help us understand > % this request. > > We would like to be the registrar for enum lookup for New Zealand. We > believe this is right direction for VoIP and terminations services. > Please let us know if you have any further questions. > > #[END of REQUEST]# > ------ End forwarded message ------ ------ End forwarded message ------

10 15

NZNOG09 Update
by Jonny Martin 15 Jan '09

15 Jan '09

Hi All, The complete program for NZNOG09 is now up. Thanks to Neil and the program committee for their efforts in putting the program together. http://2009.nznog.org/ For all those of you who missed out on accommodation at the venue itself we have an unofficial second hotel - Five Forty on Great South - which is 1 km away. Rooms are currently $110/night single, $135/night twin. Note that NZNOG does NOT have a block booking or any particular arrangement in place with the hotel. It is up to you to book directly with the hotel. http://www.540.co.nz/ There are already a number of conference attendees booked into this hotel so you will not be alone if you decide to stay there. Cheers, Jonny. (for the NZNOG 09 Org team)

1 0

NZNOG'09 Lightning Talks
by Neil Fenemor 14 Jan '09

14 Jan '09

Hi, NZNOG'09 is fast approaching. This year it is being held in Auckland, but as I am sure you have all registered by now (and if you haven't, head over to http://2009.nznog.org/register ), I'm now seeking interest for lightning talks. Lightning talks are very short 5-10 minute talks on a wide range of topics. It is a good opportunity to get your pet topic out there or perhaps to get some experience with presenting without having to do a full talk. This year we are aiming to have two separate sessions, one for general lightning talks, and one for IPv6 related talks while we run the IPv6 hour. If you are interested in speaking, please send a brief description to talks(a)nznog.org Kind Regards, Neil Fenemor NZNOG'09

2 1

NZNOG streaming as per previous years?
by Neil Gardner 14 Jan '09

14 Jan '09

I've browsed the site but can't find mention of live streams of the presentations. Is this going to happen again this year? I haven't been able to organise time to attend in person but there look like some very interesting presentations I can make time for at my desk. Cheers - N

2 1

NZRR Route Registry Update
by NZRR Database Notifications 13 Jan '09

13 Jan '09

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:AS4826 descr: advertised to AS9560 by Vocus - AS4826 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, 115.187.128.0/17^17-29, 113.192.0.0/18^18-29, 118.127.0.0/18^18-29, 125.253.0.0/18^18-29, 203.114.128.0/18^18-29, 58.96.128.0/19^19-29, 114.129.128.0/19^19-29, 118.127.160.0/19^19-29, 119.15.0.0/19^19-29, 119.77.64.0/19^19-29, 119.161.64.0/19^19-29, 120.88.64.0/19^19-29, 121.79.192.0/19^19-29, 122.129.128.0/19^19-29, 123.100.32.0/19^19-29, 123.100.128.0/19^19-29, 125.213.160.0/19^19-29, 202.14.32.0/19^19-29, 202.60.64.0/19^19-29, 202.62.128.0/19^19-29, 202.154.128.0/19^19-29, 202.171.160.0/19^19-29, 202.182.96.0/19^19-29, 203.89.64.0/19^19-29, 203.145.32.0/19^19-29, 203.201.128.0/19^19-29, 210.56.224.0/19^19-29, 113.20.0.0/20^20-29, 114.31.192.0/20^20-29, 116.213.32.0/20^20-29, 117.55.224.0/20^20-29, 119.15.96.0/20^20-29, 122.201.80.0/20^20-29, 123.50.128.0/20^20-29, 125.253.96.0/20^20-29, 125.254.64.0/20^20-29, 202.3.96.0/20^20-29, 202.4.224.0/20^20-29, 202.53.176.0/20^20-29, 202.144.160.0/20^20-29, 202.153.64.0/20^20-29, 202.191.32.0/20^20-29, 203.88.112.0/20^20-29, 203.96.16.0/20^20-29, 203.96.48.0/20^20-29, 203.96.128.0/20^20-29, 203.149.64.0/20^20-29, 210.48.160.0/20^20-29, 114.31.96.0/21^21-29, 115.124.32.0/21^21-29, 115.178.16.0/21^21-29, 116.193.176.0/21^21-29, 116.212.64.0/21^21-29, 119.31.232.0/21^21-29, 119.63.200.0/21^21-29, 120.89.80.0/21^21-29, 121.0.0.0/21^21-29, 123.108.144.0/21^21-29, 125.214.64.0/21^21-29, 125.254.88.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.49.152.0/21^21-29, 202.78.240.0/21^21-29, 202.146.208.0/21^21-29, 202.160.112.0/21^21-29, 203.169.16.0/21^21-29, 203.174.16.0/21^21-29, 203.190.208.0/21^21-29, 203.212.16.0/21^21-29, 63.217.120.0/22^22-29, 113.29.240.0/22^22-29, 122.100.0.0/22^22-29, 124.108.96.0/22^22-29, 125.254.80.0/22^22-29, 125.254.100.0/22^22-29, 125.254.112.0/22^22-29, 140.200.248.0/22^22-29, 202.37.48.0/22^22-29, 202.89.4.0/22^22-29, 202.129.244.0/22^22-29, 202.169.20.0/22^22-29, 202.177.220.0/22^22-29, 203.11.104.0/22^22-29, 203.12.48.0/22^22-29, 203.16.200.0/22^22-29, 203.17.208.0/22^22-29, 203.33.116.0/22^22-29, 203.62.184.0/22^22-29, 203.79.16.0/22^22-29, 203.92.28.0/22^22-29, 203.161.128.0/22^22-29, 203.161.140.0/22^22-29, 203.161.160.0/22^22-29, 203.175.120.0/22^22-29, 203.176.184.0/22^22-29, 203.185.228.0/22^22-29, 203.185.232.0/22^22-29, 203.190.232.0/22^22-29, 203.211.56.0/22^22-29, 59.86.160.0/23^23-29, 63.218.156.0/23^23-29, 74.80.126.0/23^23-29, 114.111.132.0/23^23-29, 119.31.248.0/23^23-29, 119.160.224.0/23^23-29, 119.160.230.0/23^23-29, 122.100.6.0/23^23-29, 122.100.8.0/23^23-29, 122.201.64.0/23^23-29, 125.254.84.0/23^23-29, 125.254.96.0/23^23-29, 125.254.104.0/23^23-29, 202.6.42.0/23^23-29, 202.12.90.0/23^23-29, 202.36.204.0/23^23-29, 202.92.94.0/23^23-29, 202.124.106.0/23^23-29, 202.150.60.0/23^23-29, 202.167.230.0/23^23-29, 202.167.244.0/23^23-29, 202.167.252.0/23^23-29, 202.172.156.0/23^23-29, 202.177.196.0/23^23-29, 202.177.214.0/23^23-29, 202.181.28.0/23^23-29, 203.4.182.0/23^23-29, 203.16.60.0/23^23-29, 203.22.70.0/23^23-29, 203.25.170.0/23^23-29, 203.28.202.0/23^23-29, 203.29.208.0/23^23-29, 203.33.60.0/23^23-29, 203.33.228.0/23^23-29, 203.34.8.0/23^23-29, 203.34.90.0/23^23-29, 203.34.122.0/23^23-29, 203.55.174.0/23^23-29, 203.62.210.0/23^23-29, 203.79.88.0/23^23-29, 203.84.134.0/23^23-29, 203.84.216.0/23^23-29, 203.98.64.0/23^23-29, 203.98.76.0/23^23-29, 203.99.146.0/23^23-29, 203.161.134.0/23^23-29, 203.161.136.0/23^23-29, 203.161.158.0/23^23-29, 203.185.194.0/23^23-29, 203.185.226.0/23^23-29, 206.222.230.0/23^23-29, 210.87.34.0/23^23-29, 58.181.65.0/24^24-29, 64.38.214.0/24^24-29, 86.111.216.0/24^24-29, 114.111.128.0/24^24-29, 116.50.58.0/24^24-29, 122.100.15.0/24^24-29, 122.200.59.0/24^24-29, 122.200.128.0/24^24-29, 122.252.4.0/24^24-29, 124.248.128.0/24^24-29, 124.248.132.0/24^24-29, 124.248.136.0/24^24-29, 124.248.140.0/24^24-29, 168.134.2.0/24^24-29, 192.88.85.0/24^24-29, 192.100.53.0/24^24-29, 192.122.171.0/24^24-29, 192.133.31.0/24^24-29, 192.138.251.0/24^24-29, 192.195.219.0/24^24-29, 193.108.151.0/24^24-29, 202.20.97.0/24^24-29, 202.22.175.0/24^24-29, 202.27.12.0/24^24-29, 202.27.83.0/24^24-29, 202.36.33.0/24^24-29, 202.36.75.0/24^24-29, 202.36.119.0/24^24-29, 202.36.154.0/24^24-29, 202.36.162.0/24^24-29, 202.36.218.0/24^24-29, 202.37.93.0/24^24-29, 202.37.168.0/24^24-29, 202.37.205.0/24^24-29, 202.41.194.0/24^24-29, 202.44.75.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.99.0/24^24-29, 202.55.105.0/24^24-29, 202.55.107.0/24^24-29, 202.65.13.0/24^24-29, 202.69.216.0/24^24-29, 202.69.219.0/24^24-29, 202.77.136.0/24^24-29, 202.122.132.0/24^24-29, 202.167.229.0/24^24-29, 202.177.207.0/24^24-29, 202.177.212.0/24^24-29, 202.177.217.0/24^24-29, 202.177.218.0/24^24-29, 203.0.155.0/24^24-29, 203.2.210.0/24^24-29, 203.3.124.0/24^24-29, 203.4.154.0/24^24-29, 203.5.45.0/24^24-29, 203.10.77.0/24^24-29, 203.10.78.0/24^24-29, 203.14.211.0/24^24-29, 203.14.230.0/24^24-29, 203.16.25.0/24^24-29, 203.16.26.0/24^24-29, 203.16.243.0/24^24-29, 203.17.4.0/24^24-29, 203.17.95.0/24^24-29, 203.17.183.0/24^24-29, 203.18.94.0/24^24-29, 203.18.235.0/24^24-29, 203.19.66.0/24^24-29, 203.19.212.0/24^24-29, 203.21.17.0/24^24-29, 203.23.105.0/24^24-29, 203.23.191.0/24^24-29, 203.23.194.0/24^24-29, 203.24.22.0/24^24-29, 203.27.100.0/24^24-29, 203.27.248.0/24^24-29, 203.28.14.0/24^24-29, 203.29.0.0/24^24-29, 203.29.176.0/24^24-29, 203.29.180.0/24^24-29, 203.30.33.0/24^24-29, 203.30.138.0/24^24-29, 203.32.82.0/24^24-29, 203.33.70.0/24^24-29, 203.33.113.0/24^24-29, 203.33.254.0/24^24-29, 203.34.110.0/24^24-29, 203.34.202.0/24^24-29, 203.34.235.0/24^24-29, 203.55.38.0/24^24-29, 203.55.115.0/24^24-29, 203.55.158.0/24^24-29, 203.55.254.0/24^24-29, 203.56.230.0/24^24-29, 203.63.3.0/24^24-29, 203.63.67.0/24^24-29, 203.79.20.0/24^24-29, 203.92.25.0/24^24-29, 203.96.157.0/24^24-29, 203.98.81.0/24^24-29, 203.111.63.0/24^24-29, 203.111.105.0/24^24-29, 203.161.132.0/24^24-29, 203.161.144.0/24^24-29, 203.166.89.0/24^24-29, 203.185.225.0/24^24-29, 203.190.217.0/24^24-29, 209.160.82.0/24^24-29, 210.7.46.0/24^24-29, 210.9.34.0/24^24-29, 210.9.134.0/24^24-29, 210.56.153.0/24^24-29, 4.53.16.144/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: tech(a)vocus.com.au mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20081215 source: NZRR REPLACED BY: route-set: AS9560:RS-ROUTES:AS4826 descr: advertised to AS9560 by Vocus - AS4826 members: 118.92.0.0/15^15-29, 130.216.0.0/15^15-29, 121.90.0.0/16^16-29, 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, 115.187.128.0/17^17-29, 203.109.128.0/17^17-29, 203.173.128.0/17^17-29, 118.127.0.0/18^18-29, 125.253.0.0/18^18-29, 203.114.128.0/18^18-29, 203.118.128.0/18^18-29, 58.96.128.0/19^19-29, 114.129.128.0/19^19-29, 118.127.160.0/19^19-29, 119.15.0.0/19^19-29, 119.77.64.0/19^19-29, 119.161.64.0/19^19-29, 120.88.64.0/19^19-29, 121.79.192.0/19^19-29, 122.129.128.0/19^19-29, 123.100.32.0/19^19-29, 124.6.192.0/19^19-29, 125.213.160.0/19^19-29, 202.14.32.0/19^19-29, 202.60.64.0/19^19-29, 202.62.128.0/19^19-29, 202.154.128.0/19^19-29, 202.171.160.0/19^19-29, 202.182.96.0/19^19-29, 203.89.64.0/19^19-29, 203.96.192.0/19^19-29, 203.145.32.0/19^19-29, 203.201.128.0/19^19-29, 210.56.224.0/19^19-29, 113.20.0.0/20^20-29, 113.192.0.0/20^20-29, 114.31.192.0/20^20-29, 114.141.96.0/20^20-29, 115.146.64.0/20^20-29, 116.66.160.0/20^20-29, 116.213.32.0/20^20-29, 117.55.224.0/20^20-29, 119.15.96.0/20^20-29, 122.201.80.0/20^20-29, 123.50.128.0/20^20-29, 125.253.96.0/20^20-29, 125.254.64.0/20^20-29, 174.128.16.0/20^20-29, 202.3.96.0/20^20-29, 202.4.224.0/20^20-29, 202.53.176.0/20^20-29, 202.73.192.0/20^20-29, 202.78.32.0/20^20-29, 202.144.160.0/20^20-29, 202.153.64.0/20^20-29, 202.191.32.0/20^20-29, 203.88.112.0/20^20-29, 203.96.16.0/20^20-29, 203.96.48.0/20^20-29, 203.96.128.0/20^20-29, 203.130.160.0/20^20-29, 203.149.64.0/20^20-29, 210.48.160.0/20^20-29, 114.31.72.0/21^21-29, 114.31.96.0/21^21-29, 115.124.32.0/21^21-29, 115.178.16.0/21^21-29, 116.90.128.0/21^21-29, 116.193.176.0/21^21-29, 116.212.64.0/21^21-29, 119.31.232.0/21^21-29, 119.63.200.0/21^21-29, 119.63.216.0/21^21-29, 120.89.80.0/21^21-29, 121.0.0.0/21^21-29, 123.108.144.0/21^21-29, 125.214.64.0/21^21-29, 125.254.88.0/21^21-29, 192.173.16.0/21^21-29, 202.36.16.0/21^21-29, 202.46.176.0/21^21-29, 202.49.0.0/21^21-29, 202.49.64.0/21^21-29, 202.49.152.0/21^21-29, 202.78.240.0/21^21-29, 202.92.240.0/21^21-29, 202.146.208.0/21^21-29, 202.160.112.0/21^21-29, 203.160.8.0/21^21-29, 203.161.136.0/21^21-29, 203.169.16.0/21^21-29, 203.174.16.0/21^21-29, 203.185.224.0/21^21-29, 203.190.208.0/21^21-29, 203.212.16.0/21^21-29, 210.4.208.0/21^21-29, 210.9.136.0/21^21-29, 61.69.0.0/22^22-29, 61.69.24.0/22^22-29, 63.217.120.0/22^22-29, 113.29.240.0/22^22-29, 113.197.64.0/22^22-29, 122.100.0.0/22^22-29, 124.108.96.0/22^22-29, 125.214.72.0/22^22-29, 125.254.80.0/22^22-29, 125.254.100.0/22^22-29, 125.254.112.0/22^22-29, 140.200.248.0/22^22-29, 198.48.0.0/22^22-29, 202.8.44.0/22^22-29, 202.36.24.0/22^22-29, 202.37.48.0/22^22-29, 202.45.152.0/22^22-29, 202.50.188.0/22^22-29, 202.89.4.0/22^22-29, 202.129.244.0/22^22-29, 202.169.20.0/22^22-29, 202.177.220.0/22^22-29, 203.11.104.0/22^22-29, 203.12.48.0/22^22-29, 203.16.200.0/22^22-29, 203.17.208.0/22^22-29, 203.22.236.0/22^22-29, 203.33.116.0/22^22-29, 203.62.184.0/22^22-29, 203.79.16.0/22^22-29, 203.92.28.0/22^22-29, 203.161.128.0/22^22-29, 203.161.160.0/22^22-29, 203.175.120.0/22^22-29, 203.176.124.0/22^22-29, 203.176.184.0/22^22-29, 203.185.232.0/22^22-29, 203.190.232.0/22^22-29, 203.209.192.0/22^22-29, 203.211.56.0/22^22-29, 210.11.144.0/22^22-29, 59.86.160.0/23^23-29, 63.218.156.0/23^23-29, 74.80.126.0/23^23-29, 114.111.132.0/23^23-29, 119.31.248.0/23^23-29, 119.160.224.0/23^23-29, 119.160.230.0/23^23-29, 122.100.6.0/23^23-29, 122.100.8.0/23^23-29, 122.200.58.0/23^23-29, 122.201.64.0/23^23-29, 125.254.84.0/23^23-29, 125.254.96.0/23^23-29, 125.254.104.0/23^23-29, 202.6.42.0/23^23-29, 202.6.116.0/23^23-29, 202.12.90.0/23^23-29, 202.36.204.0/23^23-29, 202.36.230.0/23^23-29, 202.49.46.0/23^23-29, 202.49.148.0/23^23-29, 202.92.94.0/23^23-29, 202.93.4.0/23^23-29, 202.124.106.0/23^23-29, 202.150.60.0/23^23-29, 202.160.48.0/23^23-29, 202.167.230.0/23^23-29, 202.167.244.0/23^23-29, 202.167.252.0/23^23-29, 202.172.156.0/23^23-29, 202.177.196.0/23^23-29, 202.177.214.0/23^23-29, 202.181.28.0/23^23-29, 203.3.124.0/23^23-29, 203.4.182.0/23^23-29, 203.16.60.0/23^23-29, 203.18.102.0/23^23-29, 203.22.70.0/23^23-29, 203.24.88.0/23^23-29, 203.25.170.0/23^23-29, 203.28.202.0/23^23-29, 203.29.208.0/23^23-29, 203.33.60.0/23^23-29, 203.33.228.0/23^23-29, 203.34.8.0/23^23-29, 203.34.90.0/23^23-29, 203.34.122.0/23^23-29, 203.55.174.0/23^23-29, 203.62.210.0/23^23-29, 203.79.88.0/23^23-29, 203.82.216.0/23^23-29, 203.84.134.0/23^23-29, 203.84.216.0/23^23-29, 203.98.64.0/23^23-29, 203.98.76.0/23^23-29, 203.99.146.0/23^23-29, 203.147.108.0/23^23-29, 203.161.134.0/23^23-29, 203.161.158.0/23^23-29, 203.185.194.0/23^23-29, 206.222.230.0/23^23-29, 210.9.230.0/23^23-29, 210.87.34.0/23^23-29, 58.181.65.0/24^24-29, 64.38.214.0/24^24-29, 86.111.216.0/24^24-29, 97.64.46.0/24^24-29, 113.212.98.0/24^24-29, 114.111.128.0/24^24-29, 116.50.58.0/24^24-29, 122.100.15.0/24^24-29, 122.200.128.0/24^24-29, 122.252.4.0/24^24-29, 124.248.128.0/24^24-29, 124.248.132.0/24^24-29, 124.248.136.0/24^24-29, 124.248.140.0/24^24-29, 168.134.2.0/24^24-29, 192.88.85.0/24^24-29, 192.100.53.0/24^24-29, 192.122.171.0/24^24-29, 192.133.31.0/24^24-29, 192.138.251.0/24^24-29, 192.195.219.0/24^24-29, 193.108.151.0/24^24-29, 198.32.71.0/24^24-29, 202.20.97.0/24^24-29, 202.22.175.0/24^24-29, 202.27.12.0/24^24-29, 202.27.83.0/24^24-29, 202.36.33.0/24^24-29, 202.36.75.0/24^24-29, 202.36.119.0/24^24-29, 202.36.154.0/24^24-29, 202.36.162.0/24^24-29, 202.36.174.0/24^24-29, 202.36.218.0/24^24-29, 202.37.93.0/24^24-29, 202.37.136.0/24^24-29, 202.37.168.0/24^24-29, 202.37.182.0/24^24-29, 202.37.205.0/24^24-29, 202.41.194.0/24^24-29, 202.44.75.0/24^24-29, 202.46.190.0/24^24-29, 202.49.33.0/24^24-29, 202.49.63.0/24^24-29, 202.49.106.0/24^24-29, 202.49.140.0/24^24-29, 202.49.178.0/24^24-29, 202.50.84.0/24^24-29, 202.50.247.0/24^24-29, 202.55.99.0/24^24-29, 202.55.105.0/24^24-29, 202.55.107.0/24^24-29, 202.65.13.0/24^24-29, 202.69.216.0/24^24-29, 202.69.219.0/24^24-29, 202.77.136.0/24^24-29, 202.122.132.0/24^24-29, 202.160.50.0/24^24-29, 202.167.229.0/24^24-29, 202.177.207.0/24^24-29, 202.177.212.0/24^24-29, 202.177.217.0/24^24-29, 202.177.218.0/24^24-29, 203.0.155.0/24^24-29, 203.2.210.0/24^24-29, 203.3.126.0/24^24-29, 203.4.154.0/24^24-29, 203.5.45.0/24^24-29, 203.10.77.0/24^24-29, 203.10.78.0/24^24-29, 203.14.211.0/24^24-29, 203.14.230.0/24^24-29, 203.16.25.0/24^24-29, 203.16.26.0/24^24-29, 203.16.243.0/24^24-29, 203.17.4.0/24^24-29, 203.17.68.0/24^24-29, 203.17.95.0/24^24-29, 203.17.183.0/24^24-29, 203.18.94.0/24^24-29, 203.18.136.0/24^24-29, 203.18.235.0/24^24-29, 203.19.66.0/24^24-29, 203.19.212.0/24^24-29, 203.20.18.0/24^24-29, 203.20.113.0/24^24-29, 203.21.17.0/24^24-29, 203.23.105.0/24^24-29, 203.23.191.0/24^24-29, 203.23.194.0/24^24-29, 203.24.22.0/24^24-29, 203.24.61.0/24^24-29, 203.26.204.0/24^24-29, 203.27.100.0/24^24-29, 203.27.248.0/24^24-29, 203.28.14.0/24^24-29, 203.29.0.0/24^24-29, 203.29.77.0/24^24-29, 203.29.176.0/24^24-29, 203.29.180.0/24^24-29, 203.30.33.0/24^24-29, 203.30.138.0/24^24-29, 203.31.48.0/24^24-29, 203.32.82.0/24^24-29, 203.33.70.0/24^24-29, 203.33.113.0/24^24-29, 203.33.171.0/24^24-29, 203.33.254.0/24^24-29, 203.34.110.0/24^24-29, 203.34.140.0/24^24-29, 203.34.200.0/24^24-29, 203.34.202.0/24^24-29, 203.34.235.0/24^24-29, 203.55.38.0/24^24-29, 203.55.115.0/24^24-29, 203.55.139.0/24^24-29, 203.55.158.0/24^24-29, 203.55.254.0/24^24-29, 203.56.27.0/24^24-29, 203.56.186.0/24^24-29, 203.56.230.0/24^24-29, 203.57.93.0/24^24-29, 203.63.3.0/24^24-29, 203.63.67.0/24^24-29, 203.79.20.0/24^24-29, 203.92.25.0/24^24-29, 203.96.157.0/24^24-29, 203.98.81.0/24^24-29, 203.111.63.0/24^24-29, 203.111.105.0/24^24-29, 203.119.56.0/24^24-29, 203.161.132.0/24^24-29, 203.161.144.0/24^24-29, 203.166.89.0/24^24-29, 203.171.4.0/24^24-29, 203.190.217.0/24^24-29, 203.221.207.0/24^24-29, 205.233.128.0/24^24-29, 209.160.82.0/24^24-29, 210.7.46.0/24^24-29, 210.9.34.0/24^24-29, 210.9.134.0/24^24-29, 210.55.110.0/24^24-29, 210.56.153.0/24^24-29, [snip... Object abbreviated for readability] changed: rpsl-admin(a)nzix.net 20090114 source: NZRR ------------------------------------------------------------

1 0

Announcing Dragon Research Group; sponsored by Team Cymru
by Marcel van den Berg 13 Jan '09

13 Jan '09

Hi All, Below is the announcement of the Dragon Research Group. Forwarding this message to the NZNOG list in case anyone is interested. :::: In close cooperation with Team Cymru, Dragon Research Group is announcing the launch of a new volunteer research organization dedicated to further understanding online criminality and providing actionable intelligence for the benefit of us all. The Dragon Research Group is a 'not for profit' entity and as envisioned will be comprised of a geographically dispersed set of trusted volunteers who are passionate about making the Internet more secure. Start up resources will be donated by Team Cymru but DRG will rely on donations from other organizations in the future. To meet its intended purpose, there will be a rigorous vetting procedure but selected applicants will become part of a group that will have access to the data and tools to really make a difference in the fight against online crime. The secure infrastructure is already in place and we're currently finalizing some of the procedural details. Please expect a formal launch announcement in the near future. Meanwhile, if you would like to express an interest in becoming part of or making a donation to this exciting new group, please contact dragon(a)cymru.com. ::::: Cheers! Marcel van den Berg, Team Cymru. marcel(a)cymru.com | desk: +1 312 924 4045 | CellNZ: +64 210 69 2203 PGP Key at http://www.cymru.com/teamcymrukey.txt

1 0

NZRR Route Registry Update
by NZRR Database Notifications 12 Jan '09

12 Jan '09

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-ROUTES6:AS17705 descr: Route set advertised to AS9439 by Inspire Net Ltd - AS17705 mp-members: 2404:1800:0:0:0:0:0:0/33^33-64 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: dave(a)staff.inspire.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20090113 source: NZRR REPLACED BY: route-set: AS9439:RS-ROUTES6:AS17705 descr: Route set advertised to AS9439 by Inspire - AS17705 mp-members: 2404:1800:0:0:0:0:0:0/32^32-64 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 20090113 source: NZRR ------------------------------------------------------------

1 0

Re: [nznog] FW: The Cidr Report
by Mark Davies 12 Jan '09

12 Jan '09

On Sunday 11 January 2009 03:41:26 Joe Abley wrote: > On 10 Jan 2009, at 00:42, jamie baddeley wrote: > >> 151.135.0.0/16 AS4768 CLIX-NZ TelstraClear Ltd > > > > Any reason why our friends at TCL are announcing (what appears to > > be) an > > unallocated block? > > An old CAIDA report included the following line": > > 595 151.135.248.1 gateb.opus.co.nz 151.135.248.0/22 8366 as4763np1at2 [...] > 4763 sounds right for an ex-Netlink block. I don't know who Opus are, > but their domain is still registered and has a Wellington address on > it, which also sounds right for an ex-Netlink block. Opus is an International Civil Engineering Consultancy firm (ex Works Consultancy). 151.135.0.0/16 is their old class B. They "gave it back" a couple of years ago as they were basically only using it behind a firewall and they wanted to be good net citizens (My wife contracts to them). cheers mark

2 1

Appointment of NZRS Chief Executive
by Andy Linton 12 Jan '09

12 Jan '09

This extract is from an NZRS press release went out earlier today - I'm posting it to the list given the recent discussion on this list regarding Enum and the reference to it here. .nz Registry Services is delighted to announce the appointment of Jay Daley to the position of Chief Executive of NZRS. Jay was formerly Director of IT at Nominet UK, one of the world’s leading domain name registries, and brings to his new role a wealth of experience in registry management, leadership and strategic management, and critical technology systems management. He combines a passion for technical excellence with a desire to foster a culture of consensus decision‐ making, lifelong learning, knowledge sharing and excellent customer service. One of Jay’s notable recent successes has been heading the implementation of Enum in the UK, the first diversification undertaken by Nominet UK.

1 0

A very rough overview of current state of NZ IPv6 deployment.
by Dean Pemberton 11 Jan '09

11 Jan '09

I'm not cross-posting I swear =) The following information was just posted to the IPv6 Steering Group TechSIG list and as it's got network operational content I'm posting it here as well. http://www.geek.nz/ipv6/ It's a quick stab (not complete by any means at all) at a survey of the state of IPv6 deployment within New Zealand. Discussion around this is in full flight on the TechSIG list. For those of you who missed what list I'm talking about. Here is the the invitation again. Dean ---------------------------- A workshop at held at InternetNZ on the 28 November in Wellington saw the formation of a New Zealand IPv6 Steering Group. This group includes representatives from telecommunications carriers, internet service providers, ICT vendors, and industry and user associations. The members of this steering group consist of invited senior representatives from the following organisations: InternetNZ TUANZ ISPANZ Telecommunications Carriers Forum Digital Development Forum Telecom TelstraClear WorldXChange Orcon FX Networks REANNZ Canterbury Development Corporation Kordia Cisco Vodafone Juniper Networks Alcatel Lucent Braintrust Prophecy Networks This steering group will primarily be concerned with high level discussion regarding the deployment of IPv6 within New Zealand. The steering group will not necessarily be a place where technical discussion takes place. As with so many things these days, a combination of business and technical expertise must be bought together to solve a given problem. To this end at the same workshop a Technical Special Interest Group (TechSIG) was also established. The goals of this group are: . To act as a central point for IPv6 technical discussion within the New Zealand Internet community. . To identify to the IPv6 Steering Group any business related barriers to IPv6 deployment which have been identified by the SIG's technical contributors. . To comment and provide potential solutions to technical related barriers identified by members of the IPv6 Steering Group. . To stimulate the production of relevant technical documentation. The co-conveners of this group are Andy Linton Nathan Ward Brian Carpenter Dean Pemberton A mailing list has been created and membership is open to all interested parties. Subscription details can be found at the link below; http://listserver.internetnz.net.nz/mailman/listinfo/ipv6-techsig I would encourage anyone who has an interest in the deployment and growth of IPv6 to join and contribute to the list. Please do not feel that this is a 'Networking Specialist Only' list. The deployment of IPv6 (and depletion of IPv4) has just as significant an impact on system administrators and content/application providers as it does on network administrators. I welcome all technical viewpoints onto the list. Thank you for your time. Dean Pemberton (Co-convener, IPv6 Steering Group Technical SIG)

2 2

Re: [nznog] NZNOG 2009 Network Management Miniconf
by Ewen McNeill 11 Jan '09

11 Jan '09

In message <20081220012229.F382C112733(a)wat.la.naos.co.nz>, Ewen McNeill writes: >If you've registered for NZNOG 2009 (http://2009.nznog.org/register) >you will have seen that we are holding another network administrators >miniconf on the Wednesday tutorial day. One more reminder to send us (a) topics you'd like to see discussed, and (b) offers to introduce a specific topic. This is your chance to talk with your peers about layer 7 issues which are of relevance to you. To date we have had suggested: - configuration automation (puppet, cfengine, and friends) - scaling network monitoring (eg, distributed nagios) - virtualisation (VMWare ESX, etc) No one showed any interest in talking about ENUM (either having it as a topic, or giving an intro talk), so perhaps that topic is too last week. We'd be happy to host it if there is still interest, particularly if those trying to get the 4.6.e164 delegation are willing to turn up and talk about it. Please send additional topics (and ideally offers to present for 5-15 minutes as an intro to the topic) to: <talks09(a)nznog.miniconf.org> Simon Lyall and Ewen McNeill Network Administrators Miniconf

1 0

[Fwd: Re: NZNOG list as NZNOC list.....]
by Gerard Creamer 11 Jan '09

11 Jan '09

On 12/01/2009 2:27 p.m., Andy Linton wrote: > > > And of course that page is already there. Doh! > > It's at http://www.nznog.org/?page_id=6 And this thread has prompted quite a few updates to the NOC list, which is fantastic. If there are any more changes or alterations please send them to info (at) nznog.org and I'll do them all at the same time. Cheers, Gerard

1 0

Compass Networks Email Servers IP addresses on RBL List again
by Robert Cotter 11 Jan '09

11 Jan '09

It looks like Compass have got one of their email servers IP addresses on a RBL IP list . 203.152.112.39 The tester i am using is http://www.fortiguardcenter.com/antispam/antispam.html#spamlookup Could some body let them know please, so I stop getting complaints from my partner about the stupid anti-spam system flagging legitimate emails wrong. Regards Robert Cotter ________________________________ This email is for the intended recipient(s) only. Be advised that if you have received this email in error that any use, dissemination, forwarding, printing or copying of this email is strictly prohibited. The sender cannot guarantee that this email or any attachment to it is free of computer viruses or other conditions which may damage or interfere with data, hardware or software with which it might be used. If you have received this email in error, please notify Distribution Central on +61 2 8986 5000 or notify sender.

8 12

Re: [nznog] FW: The Cidr Report
by jamie baddeley 10 Jan '09

10 Jan '09

> -----Original Message----- > From: cidr-report(a)potaroo.net [mailto:cidr-report(a)potaroo.net] > Sent: Saturday, 10 January 2009 12:00 a.m. > To: cidr-report(a)potaroo.net > Cc: apops(a)apops.net; afnog(a)afnog.org; nanog(a)merit.edu; eof-list(a)ripe.net; routing-wg(a)ripe.net > Subject: The Cidr Report > > This report has been generated at Fri Jan 9 21:13:41 2009 AEST. > The report analyses the BGP Routing Table of AS2.0 router and generates a report on aggregation potential within the table. > > Check http://www.cidr-report.org for a current version of this report. > 8<---SNIP--------------- > > Possible Bogus Routes > > 151.135.0.0/16 AS4768 CLIX-NZ TelstraClear Ltd Folks, Any reason why our friends at TCL are announcing (what appears to be) an unallocated block? Jamie

3 2

Informational - Vocus Outage at APE - 12/01/2009
by McDonald Richards 08 Jan '09

08 Jan '09

Date: 12/1/2009 2:00 AM AEDT to 12/1/2009 4:00 AM AEDT Advisory Type: Informational Services: Data Service Affecting: APE Connectivity Advisory Notes: Due to planned works on Monday the 12th of January commencing at 2:00AM AEDT the Vocus ASN 4826 peering session at APE will be down for a brief period. Please address any questions or concerns to noc(a)vocus.com.au. Regards, Vocus NOC

1 0

NZNOG09 not too far away now...
by Jonny Martin 07 Jan '09

07 Jan '09

Hi All, NZNOG09 is now less than three weeks away. Please register now if you haven't already! Please don't leave it until the last week as so many of you tend to do :). http://2009.nznog.org/ The NZNOG block booking at the Mount Richmond Hotel for NZNOG09 has now completely sold out. Given that we block booked virtually the entire hotel you'll find it hard to get accommodation there for the duration of the conference if you haven't already booked it. We have a great list of speakers again this year, as well as not one, but two social functions which are at no additional cost thanks to our generous sponsors. Thanks, and look forward to seeing you in Auckland, City of Sales... Jonny. For the NZNOG09 org team.

1 0

Re: [nznog] enum
by Michael Sutton 06 Jan '09

06 Jan '09

This is my third email on the subject of ENUM. (on a diet) Firstly; I would appreciate and hope that experts including members of NZNOG do not argue to justify why USER ENUM should NOT be implemented in New Zealand. It is not up to individuals to quantify how it will be used or the value of it to end users and application developers in the fullness of time. It is instead up to our community to actively promote and facilitate the use of any reasonable protocol on the Internet. The truly unique fact about 4.6.e164.arpa is that it is an officially sanctioned/moderated top level domain using the stable DNS ENUM services. ENUM (the protocol) is operational around the world and also in New Zealand via DNS client USER ENUM enquiries made both to countries already actively using e164.arpa as well as other registries such as e164.org TLD's. For myself I see this as a real issue of my personal Internet usage rights in New Zealand. Imagine if we were still considering whether New Zealand should have its own CC TLD. That is the situation we are in with respect to USER ENUM 4.6.e164.arpa. I cannot opt-in to register my New Zealand telephone number and all my associated communication services while ~50 countries can. Imagine if each internet protocol had to be approved by local entities such as the MED, TCF and InternetNZ. Eg. email or http/https web or skype or h323 - such a scenario is impossible to countenance. Yet User ENUM 4.6.e164.arpa delegation has been "frozen" for years by agreements between the MED (TCF and InternetNZ). 4.6.e164.arpa delegation must be approved by the MED and as such I recommend that the MED delegate it to themselves and fast track operation and policy implementation. New Zealand Telco companies who are members of the TCF already use PROVIDER ENUM as a backroom routing protocol. There is nothing they need from USER ENUM 4.6.e164.arpa but they do need to co-operate with the authentication process for establishing USER ENUM registrations. The political issue here of USER ENUM is why New Zealanders are being 'prevented' from using this service. We need a least cost, least capture USER ENUM Registry to be established which puts ENUM client users as well as application developers interests as the prime consideration. Issues concerning +1 delegation: Previous emails suggested that the United States +1 delegation was lapsed as there was no demand - This is not the situation. It is useful to appreciate that +1 represents a number of Caribbean countries as well as Canada and the United States and the complications that this fact originally had. +1 had been registered delegated for trial to "CC1 ENUM LLC" (a private company Country Code 1 ENUM Limited Liability Company). This Company's shareholders include AT&T, Sprint-Nextel, and Verizon etc - Board Papers show the stake-holder were/are not in themselves interested in supporting USER ENUM instead their primary goal was PROVIDER ENUM with delegation of 1.e164.arpa to the Company. The US State Department however "refused" to renew the +1 registration to CC1 ENUM LLC in February 2008 as the Company does not need the delegation to operate PROVIDER ENUM. Indeed the Company is proceeding with PROVIDER ENUM using 1.e164.us. (which is not a sanctioned ITU ENUM). Then in May of 2008, positively supported by United States Representatives, the ITU SG adopted "new" guidelines to cover delegation of numbers such as +1 which represent multiple countries. Therefore Canada and the other Caribbean countries are also supporting this guideline. What appears to have happened is that because CC1 ENUM LLC was only really interested in routing optimization, the US Government has pulled the plug on it because it was making no plan for USER ENUM and rather than letting the LLC remain as the Delegee the U.S.G. decided to prevent capture by this entity. This situation closely mirrors that in New Zealand - the networks want PROVIDER ENUM but eschew USER ENUM. The actions of the US Government in May 2008 (Geneva) show that they are very keen for USER ENUM to be enabled for the 1.e164.arpa countries. My advice to the Minister: On the 19th December 2008 I wrote to Ministers of the NZ Government requesting (in one part) that implementation of USER ENUM be expedited and set as a KPI of the relevant Ministry. I was completely unaware at the time of the application that was to be made on the 23rd of December by Mr. Jones for delegation of 4.6.e164.arpra. Unless the ITU receives a letter from the MED within 60 days of Mr. Jones' application the ITU will refuse the application. This notice of refusal will then be communicated by the email list to every international subscriber to the list (private/corporate/government) and will show New Zealand, I suggest, in a disorganized and poor light. (No criticism of Mr. Jones) Should this ENUM 4.6.e164.arpa registration situation then be repeated again and again and again then Kiwis will look like Thanksgiving turkeys. Best regards Michael Sutton ( Previously InternetNZ's ENUM Task Force Chairperson.) http://www.awacs.co.nz (NZNOG conference timing provides conflicts with my current schedule :( ) I suggest Andrew Ruthven and Don Christie from Catalyst be invited to attend any panel session NZNOG has)

3 2

108/8 and 184/8 allocated to ARIN
by Leo Vegoda 04 Jan '09

04 Jan '09

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, The IANA IPv4 registry has been updated to reflect the allocation of two /8 IPv4 blocks to ARIN in December 2008: 108/8 and 184/8. You can find the IANA IPv4 registry at: http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xml http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xml http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.txt Please update your filters as appropriate. Regards, Leo Vegoda Number Resources Manager, IANA -----BEGIN PGP SIGNATURE----- Version: 9.9.0.397 wj8DBQFJYcuzvBLymJnAzRwRAiHoAJ9ElxHBdXiQEYcWTE+QMKIA4+0rpwCgmbTy w5fYf3la3xtY5SjT5w+dS/w= =xUKB -----END PGP SIGNATURE-----

1 0

Call for Nominations to the APNIC Executive Council
by Sunny 04 Jan '09

04 Jan '09

_______________________________________________________________________ Call for Nominations to the APNIC Executive Council _______________________________________________________________________ Four positions on the APNIC Executive Council (EC) will be opened for election at APNIC 27 in Manila on Friday, 27 February 2009. The members whose positions are up for reelection are Kuo Wei Wu, Kusumba Sridhar, Mao Wei, and Ming-Cheng Liang, who were all elected at APNIC 24 in Bali on 2 March 2007. Nominations are due by the close of business on Tuesday, 13 February 2009 at the latest (17:30 UTC+10 Brisbane time). Nominees do not have to be representatives of members, but only APNIC members may nominate and vote for candidates. Nominations must be made using the online nomination form which will be available from 5 January 2009: http://meetings.apnic.net/elections/nominate.html If you are unable to vote online or attend APNIC 27, you can still make your vote count by appointing a proxy to represent you at the meeting. Proxy forms are available at: http://www.apnic.net/meetings/proxy.html For more information on nominations received, proxy registration, current EC members, and the role of the EC, please refer to: http://meetings.apnic.net/elections/about/index.html Online voting will be available for this election via the MyAPNIC web site and will open soon after the nomination period closes. Nominees should note that positions on the APNIC EC are currently voluntary and that APNIC may not be able to reimburse EC members all expenses associated with EC duties. Where possible, however, APNIC will reimburse actual expenses for attendance at APNIC meetings, providing that these fall within budget and cash flow constraints. If you have any questions, please contact the APNIC Secretariat at: secretariat(a)apnic.net. Regards, _______________________________________________________________________ APNIC Secretariat email: secretariat(a)apnic.net http://www.apnic.net sip: info(a)voip.apnic.net phone: +61 7 3858 3100 _______________________________________________________________________

1 0

NRO NC appointments
by Sunny 04 Jan '09

04 Jan '09

______________________________________________________________________ NRO NC appointments _______________________________________________________________________ Dear NZNOG members, The APNIC Executive Council is pleased to announce the appointment of Tomohiro Fujisaki as a representative on the Number Resource Organization (NRO) Number Council (NC) for another year. His term of appointment runs from 1 January 2009 to 31 December 2009. Please note that NRO NC representatives now fulfil the role of ICANN's ASO Address Council. Responsibilities of NRO NC representatives are outlined in the ASO Memorandum of Understanding (MoU) at: http://www.nro.net/documents/aso-mou.html More information on the roles and functions of the NRO and ASO is available at: http://www.apnic.net/community/aso/aso_ac.html _______________________________________________________________________ APNIC Secretariat secretariat(a)apnic.net Asia Pacific Network Information Centre (APNIC) Tel: +61 7 3858 3100 PO Box 2131 Milton, QLD 4064 Australia Fax: +61 7 3858 3199 Level 1, 33 Park Road, Milton, QLD http://www.apnic.net _______________________________________________________________________

1 0

The New Zealand Network Operators' Group
by Donald Neal 04 Jan '09

04 Jan '09

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 Our next conference is to be hosted by FX Networks in Auckland on 28-30 January 2009. See http://2009.nznog.org/ for more information and to register. 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 around 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

Any Juniper heads out there?
by Nick Larsen 04 Jan '09

04 Jan '09

Hi All, I have a Juniper J2320 running JunOS 9.0 R2.10 Enhanced Services, on which I'm trying to configure as an IKE gateway in hopes that I can connect using NetScreen-Remote or some other IPsec software from various DSL links (Dynamic IKE endpoints and NAT traversal). Is anyone familiar with Juniper and IPsec/IKE? Any tips welcome. Regards, Nick Larsen PS: I have looked at many pieces of documentation, but they're either for static endpoints, or using X-Auth with RADIUS. Or perhaps I'm just being blind.

1 0

Re: [nznog] enum
by James Jones 04 Jan '09

04 Jan '09

On Mon, Jan 5, 2009 at 7:09 AM, James Jones <james(a)freedomnet.co.nz> wrote: > Due to a funds shortage I will not be attending NZNOG09. I really wish > I could go!!! If some how you still wanted to do it I could make > myself available by phone if you guys could find a speaker phone....:) > > On Mon, Jan 5, 2009 at 7:07 AM, Dean Pemberton <nznog(a)deanpemberton.com> wrote: >> Don Gould wrote: >>> >>> How about outlining how you'd like to see the system used in NZ? I would like to see like to see the system being used by providers first. Also I would like to see used by end users, with no restrictions. If you put you number in the registery you need to be able to accept the call from anyone. >>> >>> How about putting a shout out for support for your ideas? It needs to operate like an open source project where we have volenteers that help keep the servers running. It would need take donations for providers and end users possible to help offset server and colo costs. On ther surface I would like to see run like e164.org, but have it a little more robust and production worthy. >>> >>> >>> >>> >> /me puts on his Org Committee hat >> >> I'm sure even at this late stage we could find space for an enum talk or >> panel discussion. >> Is this something that people are interested in? Anyone want to volunteer? >> James are you registered for the conference? >> >> >> Dean >> _______________________________________________ >> NZNOG mailing list >> NZNOG(a)list.waikato.ac.nz >> http://list.waikato.ac.nz/mailman/listinfo/nznog >> > > > > -- > James Jones > Managing Director > Freedom Networks > +64 6 3678300 > +1 413 771 1402 > james(a)freedomnet.co.nz > -- James Jones Managing Director Freedom Networks +64 6 3678300 +1 413 771 1402 james(a)freedomnet.co.nz

2 1

Re: [nznog] enum presentation: was: enum
by Ewen McNeill 04 Jan '09

04 Jan '09

In message <4960FAF6.1070202(a)deanpemberton.com>, Dean Pemberton writes: >Don Gould wrote: >> How about outlining how you'd like to see the system used in NZ? >> How about putting a shout out for support for your ideas? > >/me puts on his Org Committee hat >I'm sure even at this late stage we could find space for an enum talk or >panel discussion. The Network Systems Miniconf (one of the tutorials on Wednesday) would be happy to provide time for a enum talk and/or panel discussion if someone would volunteer to lead it off. (The topic seems very relevant to the "layer 7" approach of the miniconf, schedule we are planning is very flexible so we can allow time to discuss the issue in detail.) An offer to lead a session about enum and/or indications that this would be a useful topic welcomed. Details below (as per earlier post); suggestions of other topics also still welcomed. Ewen -=- cut here -=- From: Ewen McNeill <ewen(a)naos.co.nz> To: nznog(a)list.waikato.ac.nz Date: Sat, 20 Dec 2008 14:22:29 +1300 Subject: [nznog] NZNOG 2009 Network Management Miniconf If you've registered for NZNOG 2009 (http://2009.nznog.org/register) you will have seen that we are holding another network administrators miniconf on the Wednesday tutorial day. We'd like to try a different format this year and have a few BoF-style sessions on various ISP systems/network management topics, each with a brief introductory talk followed by an extended discussion period (10-30 minutes depending on interest in the topic). We would like suggestions for topics of interest to anyone planning on coming to the miniconf. We would also welcome any offers to speak for a few minutes (5-15 minutes) on a topic as a lead into discussion. This is your opportunity to find out what your peers at other ISPs have found does or does not work. Some topics that have been mentioned in informal discussion, or happened in previous years: - system configuration automation (puppet, bcfg, cfengine, etc) - system/network monitoring (nagios, etc, especially scalability) - mail systems/spam filtering/webmail But there are plenty of other possible topics so let us know what is relevant to you at present. Please send topic suggestions and offers to talk to: <talks09(a)nznog.miniconf.org> Simon Lyall and Ewen McNeill Network Administrators Miniconf -=- cut here -=-

1 0

Re: [nznog] enum
by James Jones 04 Jan '09

04 Jan '09

oops..sent correction On 2008-12-23, at 09:16, Leo Vegoda wrote: > On 23/12/2008 5:34, "David Farrar" <dpf(a)ihug.co.nz> wrote: > >> There's been some discussions and trials in the past between >> InternetNZ and the Telco Carrier Forum. As far as I know there are no >> current plans to delegate the domain. >> >> It is worth noting that the ITU will only delegate the domain if >> instructed to by the MED, so the MED would need to be satisfied with >> whomever is proposed to operate it. > > I suppose we'll find out soon enough: > > http://www.ripe.net/maillists/ncc-archives/enum-announce/2008/msg00011 > .html Impressive nameserver diversity in that proposal: nserver: enum1.freedomnet.co.nz nserver: enum1.freedomnet.co.nz Joe _______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog -- James Jones Managing Director Freedom Networks +64 6 3678300 +1 413 771 1402 james(a)freedomnet.co.nz

24 47

Re: [nznog] enum
by James Jones 04 Jan '09

04 Jan '09

I am trying as much info as posibble. I would like to see open enum system, in which anyone can register their numbers. I would like to see it back by providers as well. I really don't want anything in return, execcpt to able to have cheaper call routing for everyone. Steve I can understand your dubiousness in regards to the application. I am not trying to hide anything. Also to clarify, I am a contractor for ALU, but I am not tied Telecom. -----Original Message----- From: "Steve Phillips" <steve(a)focb.co.nz> To: "nznog" <nznog(a)list.waikato.ac.nz> Sent: 1/5/09 1:45 AM Subject: Re: [nznog] enum Don Gould wrote: > I'm sorry but I really feel a call to order is required here! Certainly. > I've read over half the posts in this thread and see no reason for false > accusations. False accusations ? the thing I'm finding is that people are asking for more information and we are getting 'yes yes, we will give you the information if you ask for it !' which isn't actually giving anyone anything about the intentions behind the application. This is very typical of commercial entities (and infact, anyone trying to divert attention away from something) when they are about to do something that will not necessarily be in the publics best interest. This has been an exceedingly common tactic in the NZ Internet industry since it started. The lack of any positive from JONES JAMES F and the ability to silently sidestep any real questions on his companies intentions for the enum allocation raise warning bells in my mind. I guess you've got a different outlook. Good for you, at least you're still smiling as you get shafted. > How about outlining how you'd like to see the system used in NZ? I really don't think it will ever get used, which is probably for the best. I also think allocating/activating it with no set plan as to how this is going to be implemented is dangerous. All it would take is a reasonably large carrier (verizon ? etc..) to perform a lookup, get a response and incorrectly route a call and you'd end up with chaos (keeping in mind that this is _supposed_ to be an official way route PSTN allocated numbers via IP). How are number allocations going to be handled ? how about coping with number portability ? do we sub delegate based on the NAD ? if the NAD has control then why is a private/commercial entity looking after the allocation ? is this entity going to charge to gain access to this system (even tho its open ! yay for word games) and if so, how much and will any charges slow adoption ? oh, and answering Craigs questions would also be nice. > How about putting a shout out for support for your ideas? I dont have any ideas other than 'it should be allocated to the MED/DNC/Peter Mott in order to stop this sort of thing from happening. > Seems to me that there are people here who are just jealous that > someone's trying to do something with this enum stuff. Yup, what a wonderful conclusion you've come to. I'd just like to make sure that a system such as enum, that is seen as a standard (with a low uptake, granted) does not fall in to the hands of some crowd that will in all likely-hood exploit it to make $$, prove to me that this is NOT the case and i'll happily shut up. (and yeah, I know there are checks around the allocations and I would _hope_ that they all work swimmingly, but call be a skeptic - especially when there are names such as Alcatel-Lucent and Telecom NZ behind the application based on the original e-mail sent to the list) > How about getting this thread moving back in a positive direction rather > than a pointless flame?! I find anything questioning why a public standard falls under the control of an unknown commercial entity, in order to line someones pockets, to have a reasonably valid point. If you see this as being pointless, then feel free to use your delete button or ignore the thread. I know, doom and gloom - but I have yet to meet anyone that can predict the future and looking back after the fact and saying 'oops, we maybe shouldn't have done that' doesn't really help things move forward. The NZ Internet industry has done that too often in the past, why are we doing it again now ? -- Steve.

1 0

Report on IPv4 address list
by Ian McDonald 02 Jan '09

02 Jan '09

Thought this might interest a few people: http://arstechnica.com/news.ars/post/20090102-the-year-in-ipv4-addresses-al… -- Web: http://wand.net.nz/~iam4/, http://www.jandi.co.nz Blog: http://iansblog.jandi.co.nz

2 1

VoIP Peering - was Re: enum
by Richard Naylor 30 Dec '08

30 Dec '08

At 08:52 a.m. 31/12/2008, Scott Howard wrote: >Eventually something is going to be needed to allow for optimal >routing between the multitude of VOIP providers - be that enum or >something else... OK lets cut to the guts of the problem. How do we get VoIP peering sooner rather than later ? Tomorrow, yet another year will have passed. Progress starts today. Assumption 1 - The big T(s) make about 50% of revenue off the PSTN equivalent to about $2.5B, so don't expect any co-operation. Assumption 2 - it has to be neutral - the Govt should NOT be involved. Of course they are welcome to peer, in fact its a surprise that Govt depts don't have inter-Dept peering already, its a bit of a no brainer for them. Maybe GSN was going to get there...... Assumption 3 - it has to be simple, so that VoIP providers and end users can get involved. (besides I'm on holiday and my horizons are sleep, food and beer) Assumption 4 - It should be distributed and scaleable.. (are you peering with your city, your region, your country or the World ?) So we need something NOW, that can be migrated if required. But we shouldn't be waiting on committees or politicians. Richard

4 3

Re: [nznog] enum
by Michael Sutton 29 Dec '08

29 Dec '08

I would suggest that NZNOG community read InternetNZ's ENUM archive there are two major ENUM related reports as well as an Open Source Software that InternetNZ released. I enclose some links to downloads and documents I refer to (see below). ENUM should be activated for New Zealand as it is an enabler which permits systems and network developers to utilize ENUM in a transparent way to the end user but which enhances the phone address lookup and uses the DNS which is already globally implemented. Note The ENUM system also enables PSTN numbers to be entered and used (subject to the rules of the Registry). Here's some points: 1. While an InternetNZ Councilor from 2003 - July 2007* and as Chair of the ENUM Task force I advocated for ENUM to be fast tracked and activated with a Personal User Agent software (UCI PUA service). ENUM has however been frozen since 2006 by agreements between MED, TCF and InternetNZ to delay ENUM which IMHO does not support our interest's of choice through ENUM operation and access. 2. In my opinion the MED should be required by Government to request delegation of 4.6.e164.arpa (ENUM) unto itself. MED should host ENUM on trial servers on their own ip address space which should be used for boot-strap testing and which can then be transitioned with technical delegation, operation and policy being determined on a fast track basis. The Government should include in the MED's key performance indicators measurements to incentivise their role in the implementation of ENUM for New Zealand. 3. There were discussions resulting in the current situation but there has been no ENUM Trial between InternetNZ, the TCF, NAD and MED. 4. In 2005 InternetNZ as part of the then ENUM initiative and research - INZ funded a UCI, PUA, ENUM (ETSI EG 284 004) software prototype which was developed by CatalystIT (extreme programming - shouts to AndrewR) which used the ENUM directory system, but the trial did not activate the 4.6.e164.arpa delegation, which it would in practice, or trial an ENUM authorization and registration process. In connection with this work: The final version ETSI EG 284 004 in September 2007 recommendations stated that UCI & PUA will use the public ENUM e164.arpa as a global directory. The work of InternetNZ and CatalystIT in New Zealand was recognized in reports on this matter to the European Commission and was used during the development of the final ETSI Guide/Standard which was approved in Europe by vote in 2007. The APEC Business Advisory Council's Report to the APEC Leaders in Bussan also included direct reference to this work. Note PUA is a Personal User Agent routing firewall system for client of isp telco services and UCI is an opt-in Universal Communications Identifier. Recently an Italian company undertaking a research and development contract for communication services for blind people (was contracted by the Italian Ministry of Science to implement a system using UCI PUA ENUM) communicated and requested access to InternetNZ's reports and the open source program code that InternetNZ released. 5. InternetNZ has $20,000 allocated for ENUM in the current place holder budget. 6. The ITU will not approve the ENUM delegation application of James Jones as the MED will not send a letter of endorsement to the ITU in support of this application - or will they. Regards Michael Sutton http://www.awacs.co.nz http://www.internetnz.net.nz/proceedings/tf/archive/enum http://www.internetnz.net.nz/proceedings/tf/archive/enum/pua-uci-feasibility -1-1-4-smaller.pdf http://www.internetnz.net.nz/proceedings/tf/archive/enum/Complete%20Enum%20T rial%20Report%20040705.pdf http://www.internetnz.net.nz/proceedings/tf/archive/enum/enumback.html * resigned.

3 3

Alternative Accommodation for NZNOG09
by Skeeve Stevens 25 Dec '08

25 Dec '08

Hey all, Just tried to book a room at Mount Richmond Hotel & Conference Centre (did people realise they only had 44 guest rooms?) and they are fully booked out on 29/1/09 to 30/1/09. I don't know the geography well, but I am wondering if anyone knows anywhere that is close to the venue? ...Skeeve -- Skeeve Stevens, CEO eintellego Pty Ltd - The Networking Specialists skeeve(a)eintellego.net / www.eintellego.net Phone: 1300 753 383, Fax: (+612) 8572 9954 Cell +61 (0)414 753 383 / skype://skeeve -- NOC, NOC, who's there?

2 3

enum
by JONES JAMES F 23 Dec '08

23 Dec '08

Is anyone doing anything with 4.6.e164.arpa domain? James Jones

6 6

Re: [nznog] enum
by lenz 22 Dec '08

22 Dec '08

from what i've seen in europe the registries love it and the users don't really take it. the main problem i've seen there is that the validation process is way too complicated for the normal domain registrar and the customer. the registration numbers in germany and austria are not too impressive either. the swiss guys killed their enum project afaik. cheers lenz > > On Tue, Dec 23, 2008 at 12:56 PM, Nathan Ward <nznog(a)daork.net> wrote: > >> On 23/12/2008, at 12:44 PM, JONES JAMES F wrote: >> > Is anyone doing anything with 4.6.e164.arpa domain? >> > >> http://www.internetnz.net.nz/projects/enum/index.html >> >> Seems to me that it could tie in to TUANZ/INZ stuff. >> >> I'd question whether it's worthwhile going through all the >> bureaucratic nightmare to get a limited lifetime bridge between the >> PSTN and the Internet. >> Why not just use SIP URIs? >> >> -- >> Nathan Ward >> >> >> >> >> _______________________________________________ >> NZNOG mailing list >> NZNOG(a)list.waikato.ac.nz >> http://list.waikato.ac.nz/mailman/listinfo/nznog >> > >

1 0

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

22 Dec '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:AS64526 descr: Route set for Infometrics - AS64526 members: 210.48.109.80/28 admin-c: RPA1-NZRR tech-c: RPA1-NZRR mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20030717 source: NZRR REPLACED BY: route-set: AS9439:RS-ROUTES:AS64526 descr: advertised to AS9439 by Infometrics Ltd / Gareth Morgan Investments - AS64526 members: 210.48.110.0/26^26-29, 210.48.109.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: mike(a)gmi.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20081223 source: NZRR ------------------------------------------------------------

1 0

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

22 Dec '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:AS38294 descr: Route set advertised to AS24388 by ServerWorks Ltd - AS38294 members: 202.124.127.0/24^24-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: russell(a)serverworks.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20070608 source: NZRR REPLACED BY: route-set: AS24388:RS-ROUTES:AS38294 descr: advertised to AS24388 by Serverworks Ltd - AS38294 members: 113.130.120.0/22^22-29, 202.124.127.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: russell(a)serverworks.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20081223 source: NZRR ------------------------------------------------------------

1 0

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

22 Dec '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:AS38451 descr: Route set advertised to AS9560 by SMX - AS38451 members: 203.84.134.0/23^23-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: leon.strong(a)smx.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20081203 source: NZRR REPLACED BY: route-set: AS9560:RS-ROUTES:AS38451 descr: advertised to AS9560 by SMX Ltd - AS38451 members: 113.197.64.0/22^22-29, 203.84.134.0/23^23-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: leon.strong(a)smx.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20081223 source: NZRR ------------------------------------------------------------

1 0

APE content on GigE
by Barry Murphy 21 Dec '08

21 Dec '08

Afternoon to those still at work this week... Is anyone aware of content off APE that's on GigE? Are the ftp.citylink.co.nz servers on GigE? I'm just trying to gauge what the quickest theoretical speed one could get of APE if connected at gigE. Cheers Barry Murphy P.s. for those on holiday, enjoy your beer and time off.

2 1

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

21 Dec '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: AS45279:RS-ROUTES:AS9503 descr: advertised to AS45279 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.14.32.0/19^19-29, 202.53.176.0/20^20-29, 202.160.48.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, 202.160.112.0/21^21-29, 203.190.208.0/21^21-29, 113.197.64.0/22^22-29, 202.37.48.0/22^22-29, 202.89.4.0/22^22-29, 203.84.134.0/23^23-29, 124.248.128.0/24^24-29, 124.248.132.0/24^24-29, 124.248.136.0/24^24-29, 124.248.140.0/24^24-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.12.91.0/24^24-29, 202.20.97.0/24^24-29, 202.27.83.0/24^24-29, 202.36.33.0/24^24-29, 202.36.75.0/24^24-29, 202.36.119.0/24^24-29, 202.36.154.0/24^24-29, 202.36.162.0/24^24-29, 202.36.218.0/24^24-29, 202.37.93.0/24^24-29, 202.37.168.0/24^24-29, 202.37.205.0/24^24-29, 202.46.188.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.99.0/24^24-29, 202.55.105.0/24^24-29, 202.55.107.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: peering(a)fx.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20081212 source: NZRR REPLACED BY: route-set: AS45279:RS-ROUTES:AS9503 descr: advertised to AS45279 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.14.32.0/19^19-29, 202.53.176.0/20^20-29, 202.86.96.0/20^20-29, 202.160.48.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, 202.160.112.0/21^21-29, 203.190.208.0/21^21-29, 113.197.64.0/22^22-29, 202.37.48.0/22^22-29, 202.89.4.0/22^22-29, 203.84.134.0/23^23-29, 124.248.128.0/24^24-29, 124.248.132.0/24^24-29, 124.248.136.0/24^24-29, 124.248.140.0/24^24-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.8.13.0/24^24-29, 202.12.0.0/24^24-29, 202.12.91.0/24^24-29, 202.20.97.0/24^24-29, 202.27.83.0/24^24-29, 202.36.33.0/24^24-29, 202.36.75.0/24^24-29, 202.36.119.0/24^24-29, 202.36.154.0/24^24-29, 202.36.162.0/24^24-29, 202.36.218.0/24^24-29, 202.37.93.0/24^24-29, 202.37.168.0/24^24-29, 202.37.205.0/24^24-29, 202.46.188.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.99.0/24^24-29, 202.55.105.0/24^24-29, 202.55.107.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: peering(a)fx.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20081222 source: NZRR ------------------------------------------------------------

1 0

Very funny xtra bound mail (yahoo) goes via another provider
by Barry Murphy 19 Dec '08

19 Dec '08

Heya, While drinking beer and playing with the routing table, i notice that mail destined for Xtra: xtra.co.nz. 799 IN MX 20 mx2.tnz.mail.yahoo.com. xtra.co.nz. 799 IN MX 10 mx1.tnz.mail.yahoo.com. Now goes via Vocus, a new operator selling international bandwidth in NZ: root(a)accounting:/home/icepick# traceroute mx1.tnz.mail.yahoo.com traceroute to mx1.tnz.mail.yahoo.com (124.108.96.67), 64 hops max, 40 byte packets 1 FIREWALL (60.234.66.130) 0.433 ms 0.630 ms 0.389 ms 2 * * * 3 * * * 4 vocus.ape.net.nz (192.203.154.123) 2.029 ms 1.840 ms 3.055 ms 5 ip-42.192.31.114.vocusconnect.net.au (114.31.192.42) 25.294 ms 25.707 ms 26.766 ms 6 as17457-1.bdr02.syd01.nsw.vocusconnect.net.au (114.31.200.38) 26.161 ms 26.152 ms 26.022 ms 7 gi1-2.bas2.aue.yahoo.com (203.84.216.202) 26.164 ms gi1-1.bas1.aue.yahoo.com (203.84.216.198) 26.283 ms 26.306 ms I find it great that xtra bound MX traffic is now "Local" again as it transits APE, but I find it funny that it's another operator supplying the bandwidth rather than telecom. I know this may not be news to everyone yet, and yes, it's not the first time I've mentioned (1) vocus in the last week, but from what I can tell they seem to be doing a good job for the NZ internet so far. (1) I'm in no way affiliated to vocus. Cheers Barry P.S. my views are mine only and not those of my employer, * insert rest of disclaimer here *...

5 7

xtra tedium.
by Steve Holdoway 19 Dec '08

19 Dec '08

Is there anyone from xtra/yahoo who reads this list? I've run out of things that I can do to get your servers to accept my mail. This is what I get, and trying to follow up using the case number supplied just leads to another copy of the FAQ automatically sending to me. It's *always* mx2.tnz.mail.yahoo.com that does this to me, mx1 seems quite happy. Dec 20 16:10:06 server sendmail[15781]: mBK3A4JE015618: to=<recipient(a)xtra.co.nz>, ctladdr=<steve(a)greengecko.co.nz> (1018/1018), delay=00:00:02, xdelay=00:00:01, mailer=esmtp, pri=128042, relay=mx2.tnz.mail.yahoo.com. [124.108.96.67], dsn=4.0.0, stat=Deferred: 421 Message from (210.5.53.81) temporarily deferred - 4.16.50. Please refer to http://help.yahoo.com/help/us/mail/defer/defer-06.html All the recommendations - PTR, SPF, DKIM, no html, etc have been followed. I'm starting to believe that it's this server that is plain misconfigured. Steve -- Steve Holdoway <steve(a)greengecko.co.nz>

2 1

NZNOG 2009 Network Management Miniconf
by Ewen McNeill 19 Dec '08

19 Dec '08

If you've registered for NZNOG 2009 (http://2009.nznog.org/register) you will have seen that we are holding another network administrators miniconf on the Wednesday tutorial day. We'd like to try a different format this year and have a few BoF-style sessions on various ISP systems/network management topics, each with a brief introductory talk followed by an extended discussion period (10-30 minutes depending on interest in the topic). We would like suggestions for topics of interest to anyone planning on coming to the miniconf. We would also welcome any offers to speak for a few minutes (5-15 minutes) on a topic as a lead into discussion. This is your opportunity to find out what your peers at other ISPs have found does or does not work. Some topics that have been mentioned in informal discussion, or happened in previous years: - system configuration automation (puppet, bcfg, cfengine, etc) - system/network monitoring (nagios, etc, especially scalability) - mail systems/spam filtering/webmail But there are plenty of other possible topics so let us know what is relevant to you at present. Please send topic suggestions and offers to talk to: <talks09(a)nznog.miniconf.org> Simon Lyall and Ewen McNeill Network Administrators Miniconf

1 0

Do you grok DNSSEC?
by Sam Sargeant 19 Dec '08

19 Dec '08

Hi all. There are two conferences coming up early next year that have a track on DNSSEC. Both NZNOG and APRICOT are looking to find people who have experience and would be happy to share their thoughts. My feeling is that actual use in .nz is small however I'd love to hear from you if there's something you've done with DNSSEC. Ideally we'd like people who are willing to talk in Manilla or Auckland but even just a few shared thoughts are appreciated. http://2009.nznog.org/ http://apricot2009.net/ BTW, registrations are open for both. Register now! :) Sam.

6 5

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

18 Dec '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: AS9281:RS-ROUTES:AS9503 descr: advertised to AS9281 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.14.32.0/19^19-29, 202.53.176.0/20^20-29, 202.160.48.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, 202.160.112.0/21^21-29, 203.190.208.0/21^21-29, 113.197.64.0/22^22-29, 202.37.48.0/22^22-29, 202.89.4.0/22^22-29, 203.84.134.0/23^23-29, 124.248.128.0/24^24-29, 124.248.132.0/24^24-29, 124.248.136.0/24^24-29, 124.248.140.0/24^24-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.12.91.0/24^24-29, 202.20.97.0/24^24-29, 202.27.83.0/24^24-29, 202.36.33.0/24^24-29, 202.36.75.0/24^24-29, 202.36.119.0/24^24-29, 202.36.154.0/24^24-29, 202.36.162.0/24^24-29, 202.36.218.0/24^24-29, 202.37.93.0/24^24-29, 202.37.168.0/24^24-29, 202.37.205.0/24^24-29, 202.46.188.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.99.0/24^24-29, 202.55.105.0/24^24-29, 202.55.107.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: peering(a)fx.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20081212 source: NZRR REPLACED BY: route-set: AS9281:RS-ROUTES:AS9503 descr: advertised to AS9281 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.14.32.0/19^19-29, 202.53.176.0/20^20-29, 202.86.96.0/20^20-29, 202.160.48.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, 202.160.112.0/21^21-29, 203.190.208.0/21^21-29, 113.197.64.0/22^22-29, 202.37.48.0/22^22-29, 202.89.4.0/22^22-29, 203.84.134.0/23^23-29, 124.248.128.0/24^24-29, 124.248.132.0/24^24-29, 124.248.136.0/24^24-29, 124.248.140.0/24^24-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.8.13.0/24^24-29, 202.12.0.0/24^24-29, 202.12.91.0/24^24-29, 202.20.97.0/24^24-29, 202.27.83.0/24^24-29, 202.36.33.0/24^24-29, 202.36.75.0/24^24-29, 202.36.119.0/24^24-29, 202.36.154.0/24^24-29, 202.36.162.0/24^24-29, 202.36.218.0/24^24-29, 202.37.93.0/24^24-29, 202.37.168.0/24^24-29, 202.37.205.0/24^24-29, 202.46.188.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.99.0/24^24-29, 202.55.105.0/24^24-29, 202.55.107.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: peering(a)fx.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20081219 source: NZRR ------------------------------------------------------------

1 0

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

18 Dec '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.14.32.0/19^19-29, 202.53.176.0/20^20-29, 202.160.48.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, 202.160.112.0/21^21-29, 203.190.208.0/21^21-29, 113.197.64.0/22^22-29, 202.37.48.0/22^22-29, 202.89.4.0/22^22-29, 203.84.134.0/23^23-29, 124.248.128.0/24^24-29, 124.248.132.0/24^24-29, 124.248.136.0/24^24-29, 124.248.140.0/24^24-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.12.91.0/24^24-29, 202.20.97.0/24^24-29, 202.27.83.0/24^24-29, 202.36.33.0/24^24-29, 202.36.75.0/24^24-29, 202.36.119.0/24^24-29, 202.36.154.0/24^24-29, 202.36.162.0/24^24-29, 202.36.218.0/24^24-29, 202.37.93.0/24^24-29, 202.37.168.0/24^24-29, 202.37.205.0/24^24-29, 202.46.188.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.99.0/24^24-29, 202.55.105.0/24^24-29, 202.55.107.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: peering(a)fx.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20081212 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.14.32.0/19^19-29, 202.53.176.0/20^20-29, 202.86.96.0/20^20-29, 202.160.48.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, 202.160.112.0/21^21-29, 203.190.208.0/21^21-29, 113.197.64.0/22^22-29, 202.37.48.0/22^22-29, 202.89.4.0/22^22-29, 203.84.134.0/23^23-29, 124.248.128.0/24^24-29, 124.248.132.0/24^24-29, 124.248.136.0/24^24-29, 124.248.140.0/24^24-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.8.13.0/24^24-29, 202.12.0.0/24^24-29, 202.12.91.0/24^24-29, 202.20.97.0/24^24-29, 202.27.83.0/24^24-29, 202.36.33.0/24^24-29, 202.36.75.0/24^24-29, 202.36.119.0/24^24-29, 202.36.154.0/24^24-29, 202.36.162.0/24^24-29, 202.36.218.0/24^24-29, 202.37.93.0/24^24-29, 202.37.168.0/24^24-29, 202.37.205.0/24^24-29, 202.46.188.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.99.0/24^24-29, 202.55.105.0/24^24-29, 202.55.107.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: peering(a)fx.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20081219 source: NZRR ------------------------------------------------------------

1 0

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

18 Dec '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.126.128/29, 161.29.192.160/29, 161.29.193.80/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 20081118 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.192.160/29, 161.29.193.80/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 20081219 source: NZRR ------------------------------------------------------------

1 0

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

18 Dec '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.193.144.0/21^21-29, 116.199.208.0/21^21-29, 210.54.56.0/21^21-29, 210.79.48.0/21^21-29, 113.21.224.0/22^22-29, 202.127.8.0/22^22-29, 210.54.148.0/22^22-29, 210.55.12.0/22^22-29, 120.138.22.0/23^23-29, 202.37.82.0/23^23-29, 202.175.142.0/23^23-29, 192.203.216.0/24^24-29, 202.27.8.0/24^24-29, 202.27.77.0/24^24-29, 202.36.12.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.46.189.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 20081204 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, 202.49.64.0/21^21-29, 210.54.56.0/21^21-29, 210.79.48.0/21^21-29, 113.21.224.0/22^22-29, 202.127.8.0/22^22-29, 210.54.148.0/22^22-29, 210.55.12.0/22^22-29, 120.138.22.0/23^23-29, 202.37.82.0/23^23-29, 202.175.142.0/23^23-29, 192.203.216.0/24^24-29, 202.27.8.0/24^24-29, 202.27.77.0/24^24-29, 202.36.12.0/24^24-29, 202.36.170.0/24^24-29, 202.36.174.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.46.189.0/24^24-29, 202.49.140.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.129.253.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 20081219 source: NZRR ------------------------------------------------------------

1 0

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

18 Dec '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.14.32.0/19^19-29, 202.53.176.0/20^20-29, 202.160.48.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, 202.160.112.0/21^21-29, 203.190.208.0/21^21-29, 113.197.64.0/22^22-29, 202.37.48.0/22^22-29, 202.89.4.0/22^22-29, 203.84.134.0/23^23-29, 124.248.128.0/24^24-29, 124.248.132.0/24^24-29, 124.248.136.0/24^24-29, 124.248.140.0/24^24-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.12.91.0/24^24-29, 202.20.97.0/24^24-29, 202.27.83.0/24^24-29, 202.36.33.0/24^24-29, 202.36.75.0/24^24-29, 202.36.119.0/24^24-29, 202.36.154.0/24^24-29, 202.36.162.0/24^24-29, 202.36.218.0/24^24-29, 202.37.93.0/24^24-29, 202.37.168.0/24^24-29, 202.37.205.0/24^24-29, 202.46.188.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.99.0/24^24-29, 202.55.105.0/24^24-29, 202.55.107.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: peering(a)fx.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20081212 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.14.32.0/19^19-29, 202.53.176.0/20^20-29, 202.86.96.0/20^20-29, 202.160.48.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, 202.160.112.0/21^21-29, 203.190.208.0/21^21-29, 113.197.64.0/22^22-29, 202.37.48.0/22^22-29, 202.89.4.0/22^22-29, 203.84.134.0/23^23-29, 124.248.128.0/24^24-29, 124.248.132.0/24^24-29, 124.248.136.0/24^24-29, 124.248.140.0/24^24-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.8.13.0/24^24-29, 202.12.0.0/24^24-29, 202.12.91.0/24^24-29, 202.20.97.0/24^24-29, 202.27.83.0/24^24-29, 202.36.33.0/24^24-29, 202.36.75.0/24^24-29, 202.36.119.0/24^24-29, 202.36.154.0/24^24-29, 202.36.162.0/24^24-29, 202.36.218.0/24^24-29, 202.37.93.0/24^24-29, 202.37.168.0/24^24-29, 202.37.205.0/24^24-29, 202.46.188.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.99.0/24^24-29, 202.55.105.0/24^24-29, 202.55.107.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: peering(a)fx.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20081219 source: NZRR ------------------------------------------------------------

1 0

IPv6 Steering Group Technical SIG - Announcement/Invitation
by Dean Pemberton 18 Dec '08

18 Dec '08

A workshop at held at InternetNZ on the 28 November in Wellington saw the formation of a New Zealand IPv6 Steering Group. This group includes representatives from telecommunications carriers, internet service providers, ICT vendors, and industry and user associations. The members of this steering group consist of invited senior representatives from the following organisations: InternetNZ TUANZ ISPANZ Telecommunications Carriers Forum Digital Development Forum Telecom TelstraClear WorldXChange Orcon FX Networks REANNZ Canterbury Development Corporation Kordia Cisco Vodafone Juniper Networks Alcatel Lucent Braintrust This steering group will primarily be concerned with high level discussion regarding the deployment of IPv6 within New Zealand. The steering group will not necessarily be a place where technical discussion takes place. As with so many things these days, a combination of business and technical expertise must be bought together to solve a given problem. To this end at the same workshop a Technical Special Interest Group (TechSIG) was also established. The goals of this group are: . To act as a central point for IPv6 technical discussion within the New Zealand Internet community. . To identify to the IPv6 Steering Group any business related barriers to IPv6 deployment which have been identified by the SIG's technical contributors. . To comment and provide potential solutions to technical related barriers identified by members of the IPv6 Steering Group. . To stimulate the production of relevant technical documentation. The co-conveners of this group are Andy Linton Nathan Ward Brian Carpenter Dean Pemberton A mailing list has been created and membership is open to all interested parties. Subscription details can be found at the link below; http://listserver.internetnz.net.nz/mailman/listinfo/ipv6-techsig I would encourage anyone who has an interest in the deployment and growth of IPv6 to join and contribute to the list. Please do not feel that this is a 'Networking Specialist Only' list. The deployment of IPv6 (and depletion of IPv4) has just as significant an impact on system administrators and content/application providers as it does on network administrators. I welcome all technical viewpoints onto the list. Thank you for your time. Dean Pemberton (Co-convener, IPv6 Steering Group Technical SIG)

1 0

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

18 Dec '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:AS9889 descr: advertised to AS9560 by Maximum Internet Ltd - AS9889 members: 123.100.64.0/18^18-29, 124.198.128.0/18^18-29, 202.89.32.0/19^19-29, 203.89.160.0/19^19-29, 114.134.160.0/20^20-29, 202.55.96.0/20^20-29, 114.134.176.0/21^21-29, 119.47.112.0/21^21-29, 202.189.160.0/21^21-29, 122.102.108.0/22^22-29, 210.55.100.0/22^22-29, 210.55.104.0/22^22-29, 117.53.150.0/23^23-29, 202.49.88.0/23^23-29, 210.54.142.0/23^23-29, 192.138.251.0/24^24-29, 202.6.5.0/24^24-29, 202.27.8.0/24^24-29, 202.27.204.0/24^24-29, 202.36.70.0/24^24-29, 202.36.227.0/24^24-29, 202.37.72.0/24^24-29, 202.37.162.0/24^24-29, 202.37.181.0/24^24-29, 202.37.205.0/24^24-29, 202.37.232.0/24^24-29, 202.49.141.0/24^24-29, 202.150.102.0/24^24-29, 203.12.15.0/24^24-29, 203.97.42.0/24^24-29, 205.233.243.0/24^24-29, 210.54.13.0/24^24-29, 210.55.169.0/24^24-29, 210.55.214.0/24^24-29, 210.55.230.0/24^24-29, 203.167.219.56/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)maxnet.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20081121 source: NZRR REPLACED BY: route-set: AS9560:RS-ROUTES:AS9889 descr: advertised to AS9560 by Maximum Internet Ltd - AS9889 members: 123.100.64.0/18^18-29, 124.198.128.0/18^18-29, 202.89.32.0/19^19-29, 203.89.160.0/19^19-29, 114.134.160.0/20^20-29, 202.55.96.0/20^20-29, 114.134.176.0/21^21-29, 119.47.112.0/21^21-29, 202.189.160.0/21^21-29, 113.197.64.0/22^22-29, 122.102.108.0/22^22-29, 210.55.100.0/22^22-29, 210.55.104.0/22^22-29, 117.53.150.0/23^23-29, 202.49.88.0/23^23-29, 203.84.134.0/23^23-29, 210.54.142.0/23^23-29, 192.138.251.0/24^24-29, 202.6.5.0/24^24-29, 202.27.8.0/24^24-29, 202.27.204.0/24^24-29, 202.36.70.0/24^24-29, 202.36.227.0/24^24-29, 202.37.72.0/24^24-29, 202.37.162.0/24^24-29, 202.37.181.0/24^24-29, 202.37.232.0/24^24-29, 202.49.141.0/24^24-29, 202.150.102.0/24^24-29, 203.12.15.0/24^24-29, 203.97.42.0/24^24-29, 205.233.243.0/24^24-29, 210.54.13.0/24^24-29, 210.55.169.0/24^24-29, 210.55.214.0/24^24-29, 210.55.230.0/24^24-29, 203.167.219.56/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)maxnet.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20081219 source: NZRR ------------------------------------------------------------

1 0

Microsoft releasing emergency patch for perilous IE flaw
by Dean Pemberton 16 Dec '08

16 Dec '08

Interesting reading. http://news.yahoo.com/s/afp/20081216/ts_alt_afp/uschinaitinternetsoftwarecr… Microsoft will release an emergency patch on Wednesday to fix a perilous software flaw allowing hackers to hijack Internet Explorer browsers and take over computers. The US software giant said on Tuesday that in response to "the threat to customers" it immediately mobilized security engineering teams worldwide to deliver a software cure "in the unprecedented time of eight days." According to researchers at software security firm Trend Micro, attacks based on the vulnerability in the world's most popular Web browser are spreading "like wildfire" with millions of computers already compromised.

1 0