- NZNOG - lists.nznog.org

IANA IPv4 allocations and bogon update: 41/8
by Rob Thomas 13 Apr '05

13 Apr '05

-----BEGIN PGP SIGNED MESSAGE----- [ Apologies to those of you who receive this note in multiple forums. ] Hi, team. The numerous Team Cymru bogon projects have been updated as of 13 APR 2005 to reflect the following IANA allocation made on 12 APR 2005: 041/8 Apr 05 AfriNIC (whois.afrinic.net) IANA allocations change over time, so please check regularly to ensure you have the latest filters if you are not using the bogon BGP feed(s). We do announce updates to the bogon projects to sundry lists, such as the bogon-announce list. We can not stress this point strongly enough - these allocations change. If you do not adjust your filters, you will be unable to access perhaps large portions of the Internet. Worse yet, you may end up blocking access for people who transit through you. Please do not apply any filters or blocks to your network without carefully considering the ramifications of doing so. As a point of reference, the Team Cymru master Bogon Reference Page can be found here: <http://www.cymru.com/Bogons/> A quick summary of the documents and projects that have been updated include the following: HTTP The Bogon List - <http://www.cymru.com/Documents/bogon-list.html> The Text Bogon Lists - <http://www.cymru.com/Documents/bogon-bn-nonagg.txt> - <http://www.cymru.com/Documents/bogon-bn-agg.txt> Secure BIND Template - <http://www.cymru.com/Documents/secure-bind-template.html> Secure IOS Template (Cisco) - <http://www.cymru.com/Documents/secure-ios-template.html> Secure BGP Template (Cisco) - <http://www.cymru.com/Documents/secure-bgp-template.html> Secure JUNOS Template (Juniper) - <http://www.cymru.com/gillsr/documents/junos-template.htm> Secure JUNOS BGP Template (Juniper) - <http://www.cymru.com/gillsr/documents/junos-bgp-template.htm> Ingress Prefix Filter Templates, Loose and Strict (Cisco) - <ftp://ftp-eng.cisco.com/cons/isp/security/Ingress-Prefix-Filter- Templates/> Ingress Prefix Filter Template, Loose (Juniper) - <http://www.cymru.com/gillsr/documents/junos-isp-prefix-filter- loose.htm> Ingress Prefix Filter Template, Strict (Juniper) - <http://www.cymru.com/gillsr/documents/junos-isp-prefix-filter- strict.htm> BGP Bogon route-server for AUTOMATED updates of bogon filters - All bogon route-server peers have already received the appropriate BGP prefix updates. - <http://www.cymru.com/BGP/bogon-rs.html> RADb fltr-unallocated fltr-martian fltr-bogons - <http://www.cymru.com/Bogons/index.html#radb> RIPE NCC fltr-unallocated fltr-martian fltr-bogons - <http://www.cymru.com/Bogons/index.html#ripe> DNS Bogon (bogons.cymru.com) zone - <http://www.cymru.com/Bogons/index.html#dns> Monitoring Bogon prefix monitoring - <http://www.cymru.com/BGP/robbgp-bogon.html> Bogus ASN monitoring - <http://www.cymru.com/BGP/asnbogusrep.html> Please feel free to contact Team Cymru <team-cymru(a)cymru.com> with any comments, questions, or concerns. Thank you for your continued support. Rob. - -- Rob Thomas http://www.cymru.com ASSERT(coffee != empty); -----BEGIN PGP SIGNATURE----- Version: PGP 6.5.2 iQCVAwUBQl578FkX3QAo5sgJAQEBUQQAhxlGUyzcvxzHVF2/PHZt27K04nSCxSWu k0G70eCN6QRib3h9HIlz3GCu24aBPJMcM+zH6SOGjydVHsDFJFFGuw42HcTWAttV 35nbzeN4jqBQQZGtel3he+lNPcd60uHloE3za/4F6P/flBrl2S3peoCo4TpxDnfe RoBcAod+aTQ= =74Xj -----END PGP SIGNATURE-----

1 0

DNS + IPv6
by Philip D'Ath 10 Apr '05

10 Apr '05

I'm doing some work with IPv6 at the moment, and one of the upcoming tasks I'm going to need to do is get a couple of IPv6 DNS servers online. Can someone tell me if the NZ SRS supports IPv6 glue records? Specifically, can I register the AAAA NS records?

3 2

Re: [nznog] Trade Me peering via the APE and WIX route servers
by Andy Linton 07 Apr '05

07 Apr '05

Trademe are announcing their network to both APE and WIX. Their preference is to route packets via the WIX as they're based in Wellington so we've path stuffed the APE announcement so that dual APE/WIX homed entities favour the WIX. This is also so that paths can be symmetric as return packets from Trademe will favour the WIX where they can. Some of you who peer at the APE and WIX may still be favouring announcements from your upstream provider and in many cases these will be links that you pay charges which are related to usage in some way. If I were in your shoes I'd be constructing some BGP policy tweaks to favour APE routes over routes from a link I was paying for regardless of AS path. I've added two community strings to the announcements of 202.21.128.0/24 via AS24078 which may help: 24078:9439 announced via WIX 24078:9560 announced via APE

1 0

Notification of NZRR Database changes
by NZRR Database Notifications 07 Apr '05

07 Apr '05

Dear Colleague, This is to notify you that some object(s) in NZRR database which you either maintain or are listed as to-be-notified have been added, deleted or changed. These objects are used to configure the various NZIX route servers (http://nzix.net/) so you can expect the relevant servers to be reloaded in the near future. The reloading of the servers is staggered over a period of time so that if you are peering with both servers at an exchange, you can maintain at least one BGP session at all times and consequently a full set of routes. --- PREVIOUS OBJECT: aut-num: AS24078 as-name: NZRR-AS24078 descr: TradeMe descr: APE peering at '192.203.154.18' descr: see Citylink RT job #2209 admin-c: RPA1-NZRR tech-c: RPA1-NZRR import: from AS9560 accept ANY AND NOT fltr-bogons export: to AS9560 announce AS24078 notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: asjl(a)citylink.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050408 source: NZRR REPLACED BY: aut-num: AS24078 as-name: NZRR-AS24078 descr: TradeMe descr: APE peering at '192.203.154.18' descr: see Citylink RT job #2209 descr: WIX peering at '202.7.1.67' descr: see Citylink RT job #359 admin-c: RPA1-NZRR tech-c: RPA1-NZRR import: from AS9439 accept ANY AND NOT fltr-bogons export: to AS9439 announce AS24078 import: from AS9560 accept ANY AND NOT fltr-bogons export: to AS9560 announce AS24078 notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: asjl(a)citylink.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050408 source: NZRR

2 1

Notification of NZRR Database changes
by NZRR Database Notifications 07 Apr '05

07 Apr '05

Dear Colleague, This is to notify you that some object(s) in NZRR database which you either maintain or are listed as to-be-notified have been added, deleted or changed. These objects are used to configure the various NZIX route servers (http://nzix.net/) so you can expect the relevant servers to be reloaded in the near future. The reloading of the servers is staggered over a period of time so that if you are peering with both servers at an exchange, you can maintain at least one BGP session at all times and consequently a full set of routes. --- OBJECT BELOW CREATED: route-set: AS9560:RS-ROUTES:AS24078 descr: Route set advertised to AS9560 by TradeMe - AS24078 members: 202.21.128.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: asjl(a)citylink.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050408 source: NZRR

1 0

Russell Brown interviews Raymond O'Brien
by Simon Lyall 06 Apr '05

06 Apr '05

from TelstraClear on peering. http://www.darkmere.gen.nz/temp/rb_raymondobrien-2005-04-06.mp3 -- Simon J. Lyall | Very Busy | Web: http://www.darkmere.gen.nz/ "To stay awake all night adds a day to your life" - Stilgar | eMT.

2 1

RE: [nznog] Seminar on UWB
by Donald Neal 06 Apr '05

06 Apr '05

> -----Original Message----- > From: Steve Phillips [mailto:steve(a)focb.co.nz] > Sent: Wednesday, 6 April 2005 9:05 p.m. > To: nznog(a)list.waikato.ac.nz > Subject: Re: [nznog] Seminar on UWB > > > wasn't this posted earlier today ? > At the time I acted on the request I received to post it, I hadn't noticed that it had already been posted. My apologues for any confusion caused. - Donald Neal Donald Neal |"Do not use your laptop in a wet Support Engineer |environment unless it operates on NGN Operations |batteries." Integration & Services Division +----------------------------------- Alcatel NZ Ltd - Telecom's network operations manager "This communication, including any attachments, is confidential. If you are not the intended recipient, you should not read it - please contact me immediately, destroy it, and do not copy or use any part of this communication or disclose anything about it. Thank you. Please note that this communication does not designate an information system for the purposes of the Electronic Transactions Act 2002."

1 0

Seminar on UWB
by Donald Neal 05 Apr '05

05 Apr '05

This announcement is posted on behalf of the Ministry for Economic Development. - - - - - Dear industry colleagues, Ultra Wide Band (UWB) is a new wireless technology developed to transmit large amounts of data over very short distances. UWB devices are designed to operate at very low power levels, enabling them in theory, to share spectrum with traditionally licensed services over a wide range of frequencies without adverse impact to those services. Potential applications of UWB are high-speed wireless networking in the workplace or at home, ground penetrating radar for geological surveys and search and rescue, wall penetrating imaging in construction, vehicular radar for collision avoidance, medical imaging, and hand-held communication and measurement systems. The Ministry is in the process of preparing an engineering discussion paper seeking submissions from the industry and stakeholders, on spectrum allocation and technical standards for UWB devices. In conjuction with this paper, the Ministry is planning to hold seminars in Auckland and Wellington to clarify and discuss issues raised. The details of the seminars are given below: Auckland 10 am Friday 15 April 2005 Stamford Plaza 22 Albert St, Auckland Central Wellington 10 am Wednesday 20 April 2005 Rangi Marie Room 1 Te Papa Cable st Wellington Confirmation of your attendance together with your choice of venue should be sent to <mailto:radiospectrum(a)med.govt.nz> mailto:radiospectrum(a)med.govt.nz Please feel free to circulate this message to any additional persons who you feel may have an interest in this topic. The Ministry expects to publish the discussion paper prior to the seminar dates. Kind Regards, Chris Perera Senior Planning Analyst Radio Spectrum Policy & Planning The Ministry of Economic Development 33, Bowen St, Wellington, New Zealand DDI: +64-4-462 4279 Fax: +64-4-499 0969 email: <mailto:chris.perera(a)med.govt.nz> chris.perera(a)med.govt.nz http://www.govt.nz - connecting you to New Zealand central & local government services Any opinions expressed in this message are not necessarily those of the Ministry of Economic Development. This message and any files transmitted with it are confidential and solely for the use of the intended recipient. If you are not the intended recipient or the person responsible for delivery to the intended recipient, be advised that you have received this message in error and that any use is strictly prohibited. Please contact the sender and delete the message and any attachment from your computer. "This communication, including any attachments, is confidential. If you are not the intended recipient, you should not read it - please contact me immediately, destroy it, and do not copy or use any part of this communication or disclose anything about it. Thank you. Please note that this communication does not designate an information system for the purposes of the Electronic Transactions Act 2002."

3 2

Seminar on UWB (fwd)
by Jamie Curtis 05 Apr '05

05 Apr '05

Forwarded by request from Chris Perera (a speaker at the last NZNOG conference for those of you not there). ---------- Forwarded message ---------- Date: Wed, 6 Apr 2005 11:01:33 +1200 From: Chris Perera <chris.perera(a)med.govt.nz> Subject: Seminar on UWB Dear industry colleagues, Ultra Wide Band (UWB) is a new wireless technology developed to transmit large amounts of data over very short distances. UWB devices are designed to operate at very low power levels, enabling them in theory, to share spectrum with traditionally licensed services over a wide range of frequencies without adverse impact to those services. Potential applications of UWB are high-speed wireless networking in the workplace or at home, ground penetrating radar for geological surveys and search and rescue, wall penetrating imaging in construction, vehicular radar for collision avoidance, medical imaging, and hand-held communication and measurement systems. The Ministry is in the process of preparing an engineering discussion paper seeking submissions from the industry and stakeholders, on spectrum allocation and technical standards for UWB devices. In conjuction with this paper, the Ministry is planning to hold seminars in Auckland and Wellington to clarify and discuss issues raised. The details of the seminars are given below: Auckland 10 am Friday 15 April 2005 Stamford Plaza 22 Albert St, Auckland Central Wellington 10 am Wednesday 20 April 2005 Rangi Marie Room 1 Te Papa Cable st Wellington Confirmation of your attendance together with your choice of venue should be sent to <mailto:radiospectrum(a)med.govt.nz> mailto:radiospectrum(a)med.govt.nz Please feel free to circulate this message to any additional persons who you feel may have an interest in this topic. The Ministry expects to publish the discussion paper prior to the seminar dates. Kind Regards, Chris Perera Senior Planning Analyst Radio Spectrum Policy & Planning The Ministry of Economic Development 33, Bowen St, Wellington, New Zealand DDI: +64-4-462 4279 Fax: +64-4-499 0969 email: <mailto:chris.perera(a)med.govt.nz> chris.perera(a)med.govt.nz http://www.govt.nz - connecting you to New Zealand central & local government services Any opinions expressed in this message are not necessarily those of the Ministry of Economic Development. This message and any files transmitted with it are confidential and solely for the use of the intended recipient. If you are not the intended recipient or the person responsible for delivery to the intended recipient, be advised that you have received this message in error and that any use is strictly prohibited. Please contact the sender and delete the message and any attachment from your computer.

1 0

RFC1918 Addresses in routing paths
by Jonathan Brewer 04 Apr '05

04 Apr '05

Hi Folks, I am wondering about the etiquette of reporting RFC1918 addresses back to hosts performing a traceroute. Example below: Hostname 1. ourhost.ourprovider.net.nz 2. f3-0-2.core1.wlg.ourprovider.net.nz 3. f0-0-4.core3.wlg.ourprovider.net.nz 4. f4-0-5.core2.akl.ourprovider.net.nz 5. g1-0-1396.u12.brfd.otherprovider.net.nz 6. g1-0-1043.u12.brh.otherprovider.net.nz 7. 10.65.32.1 8. 10.65.32.250 9. 10.69.0.2 10. a12-3-23.u21.tar.otherprovider.net.nz 11. fa7-4-1042.bigrouter.otherprovider.net.nz 12. otherhost.otherprovider.net.nz Any comments on this practice? Cheers, Jon ------------------------------------ Araneo Limited info (at) araneo.net.nz 5th Floor Central House 26 Brandon Street Wellington, New Zealand tel: +64-4-473-3932 fax: +64-4-472-0960 http://www.araneo.net.nz ------------------------------------

7 7

Notification of NZRR Database changes
by NZRR Database Notifications 31 Mar '05

31 Mar '05

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

1 0

Notification of NZRR Database changes
by NZRR Database Notifications 30 Mar '05

30 Mar '05

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

1 0

Notification of NZRR Database changes
by NZRR Database Notifications 30 Mar '05

30 Mar '05

Dear Colleague, This is to notify you that some object(s) in NZRR database which you either maintain or are listed as to-be-notified have been added, deleted or changed. These objects are used to configure the various NZIX route servers (http://nzix.net/) so you can expect the relevant servers to be reloaded in the near future. The reloading of the servers is staggered over a period of time so that if you are peering with both servers at an exchange, you can maintain at least one BGP session at all times and consequently a full set of routes. --- PREVIOUS OBJECT: aut-num: AS23754 as-name: NZRR-AS23754 descr: CityLink descr: CHIX peering at '218.100.24.3' descr: see Citylink RT job #1927 admin-c: RPA1-NZRR tech-c: RPA1-NZRR import: from AS24388 accept ANY AND NOT fltr-bogons export: to AS24388 announce AS23754 notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: asjl(a)citylink.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050331 source: NZRR REPLACED BY: aut-num: AS23754 as-name: NZRR-AS23754 descr: CityLink descr: SIX peering at '218.100.25.3' descr: see Citylink RT job #1927 admin-c: RPA1-NZRR tech-c: RPA1-NZRR import: from AS24387 accept ANY AND NOT fltr-bogons export: to AS24387 announce AS23754 notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: asjl(a)citylink.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050331 source: NZRR

1 0

Notification of NZRR Database changes
by NZRR Database Notifications 30 Mar '05

30 Mar '05

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

1 0

Notification of NZRR Database changes
by NZRR Database Notifications 30 Mar '05

30 Mar '05

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

1 0

Notification of NZRR Database changes
by NZRR Database Notifications 30 Mar '05

30 Mar '05

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

1 0

Notification of NZRR Database changes
by NZRR Database Notifications 30 Mar '05

30 Mar '05

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

1 0

IANA IPv4 allocations and bogon update: 73/8
by Rob Thomas 30 Mar '05

30 Mar '05

-----BEGIN PGP SIGNED MESSAGE----- [ Apologies to those of you who receive this note in multiple forums. ] Hi, team. The numerous Team Cymru bogon projects have been updated as of 30 MAR 2005 to reflect the following IANA allocation made on 30 MAR 2005: 073/8 Mar 05 ARIN (whois.arin.net) IANA allocations change over time, so please check regularly to ensure you have the latest filters if you are not using the bogon BGP feed(s). We do announce updates to the bogon projects to sundry lists, such as the bogon-announce list. We can not stress this point strongly enough - these allocations change. If you do not adjust your filters, you will be unable to access perhaps large portions of the Internet. Worse yet, you may end up blocking access for people who transit through you. Please do not apply any filters or blocks to your network without carefully considering the ramifications of doing so. As a point of reference, the Team Cymru master Bogon Reference Page can be found here: <http://www.cymru.com/Bogons/> A quick summary of the documents and projects that have been updated include the following: HTTP The Bogon List - <http://www.cymru.com/Documents/bogon-list.html> The Text Bogon Lists - <http://www.cymru.com/Documents/bogon-bn-nonagg.txt> - <http://www.cymru.com/Documents/bogon-bn-agg.txt> Secure BIND Template - <http://www.cymru.com/Documents/secure-bind-template.html> Secure IOS Template (Cisco) - <http://www.cymru.com/Documents/secure-ios-template.html> Secure BGP Template (Cisco) - <http://www.cymru.com/Documents/secure-bgp-template.html> Secure JUNOS Template (Juniper) - <http://www.cymru.com/gillsr/documents/junos-template.htm> Secure JUNOS BGP Template (Juniper) - <http://www.cymru.com/gillsr/documents/junos-bgp-template.htm> Ingress Prefix Filter Templates, Loose and Strict (Cisco) - <ftp://ftp-eng.cisco.com/cons/isp/security/Ingress-Prefix-Filter-Templates/> Ingress Prefix Filter Template, Loose (Juniper) - <http://www.cymru.com/gillsr/documents/junos-isp-prefix-filter-loose.htm> Ingress Prefix Filter Template, Strict (Juniper) - <http://www.cymru.com/gillsr/documents/junos-isp-prefix-filter-strict.htm> BGP Bogon route-server for AUTOMATED updates of bogon filters - All bogon route-server peers have already received the appropriate BGP prefix updates. - <http://www.cymru.com/BGP/bogon-rs.html> RADb fltr-unallocated fltr-martian fltr-bogons - <http://www.cymru.com/Bogons/index.html#radb> RIPE NCC fltr-unallocated fltr-martian fltr-bogons - <http://www.cymru.com/Bogons/index.html#ripe> DNS Bogon (bogons.cymru.com) zone - <http://www.cymru.com/Bogons/index.html#dns> Monitoring Bogon prefix monitoring - <http://www.cymru.com/BGP/robbgp-bogon.html> Bogus ASN monitoring - <http://www.cymru.com/BGP/asnbogusrep.html> Please feel free to contact Team Cymru <team-cymru(a)cymru.com> with any comments, questions, or concerns. Thank you for your continued support. Rob, for Team Cymru. - -- Rob Thomas http://www.cymru.com Shaving with Occam's razor since 1999. -----BEGIN PGP SIGNATURE----- Version: PGP 6.5.2 iQCVAwUBQks9clkX3QAo5sgJAQFCHgP/V6mR3gVMiNQ5bvkfSgsT5nkIw0bn2BJA nE4qKGQrB22WL6t83PMsMONjW7GvHJA7Ds4DVgVggTUBJ/SqupM1xQ3SBwEokHcW oydTMiUrsS1dmZMdoLoSHNdGC6hLciTgYayIO/EBI9IGoQYdR/swzgjzHXkLWghO 0C67MWkIT7M= =+ixP -----END PGP SIGNATURE-----

1 0

Wassenaar Agreement and strong crypto exports
by neil gardner 29 Mar '05

29 Mar '05

Hi guys - this isn't strictly operational but I think it's an appropriate audience. As per the subject, I'm after current info about experiences with MFAT over the export of strong crypto, either as software, or embedded in hardware. The online references I can find (Some listed below) are reasonably old and I was hoping there had been some change. (I quote from a 1997 letter from Sec Foreign affairs and trade - Mr Borrie) "This sort of product (encrpytion software) is considered a "dual use" good in terms of the New Zealand Export Controls which means that they are able to be adapted for military, terrorist or criminal use" (I could adapt a plastic spoon for criminal use - but that's beside the point!) Source : http://www.cs.auckland.ac.nz/~pgut001/policy/mfat_2r.html I looked at the MFAT site and they still list encryption software on their "New Zealand Strategic Goods List Index of Controlled Goods" page. Source : http://www.mfat.govt.nz/foreign/dis/nzsgl/pages/laste.html So I guess my question is does anyone know if they have relaxed their approach to 3DES (or even AES-xxx) given that these 'technologies' are freely available internationally, and that 128bit encryption has been effectively opened way up by international adoption in browsers? I'm happy to summarise if there's a bit of feedback. Cheers - Neil Gardner. NOTICE: This message contains privileged and confidential information intended only for the use of the addressee named above. If you are not the intended recipient of this message you are hereby notified that you must not disseminate, copy or take any action in reliance on it. If you have received this message in error please notify Allied Telesyn Research Ltd immediately. Any views expressed in this message are those of the individual sender, except where the sender has the authority to issue and specifically states them to be the views of Allied Telesyn Research.

1 0

[enum-sg] Request to be invited to a workshop on ENUM policy for New Zealand (Draft)
by Peter Macaulay 29 Mar '05

29 Mar '05

In Auckland, on April 13 2005, at SkyCity, InternetNZ is hosting a one day workshop on ENUM policy for New Zealand. Chaired by Tony Holmes, a globally known speaker on ENUM issues, the workshop is for all those who will be involved in decisions about implementation of ENUM in New Zealand, or who have a commercial or technical interest. InternetNZ is in the process of developing some components for an ENUM trial which will be shown at a later workshop. More details will be published in the next few days, and will be echoed on the InternetNZ website. Places are limited. Please respond to office(a)internetnz.net.nz so your request can be considered. DRAFT AGENDA: Desired Outcome: A foundation and way forward for trialling ENUM in New Zealand 1. INTRODUCTIONS 2. AIM OF THE WORKSHOP To determine: - Why should there be a trial - what questions are we setting out to answer? - What are the objectives of the trial? - What needs to happen before a trial can take place? - Who needs to be involved in a trial? - Who will administer the trial? - What are the deliverables of the trial? 3. THE DELEGATION OF 4.6.e164.arpa - Tony Holmes: UK Experience 4. EXPERIENCE OF OTHER TRIALS - Tony Holmes: Experience of UK and other jurisdictions 5. MAXIMISING BENEFITS FROM STANDARDS - Tony Holmes: Overview of the role of standards to be applied in a trial 6. UNIVERSAL COMMUNICATIONS IDENTIFIERS (UCI) and PERSONAL USER AGENTS (PUA) - Micheal Sutton. An Overview of the assignment 7. SOME ADDITIONAL PERSPECTIVES - Regulatory perspectives - Variations on the use of .arpa for ENUM that are occurring in the US and the UK 8. THE WAY FORWARD FOR NZ - issues - what needs to be done - who needs to be involved - actions - timeframe 9. Concluding Summation -- *Peter Macaulay* /Executive Director/ *InternetNZ */Direct +64 4 495 2113 Skype petermacaulay Mobile +64 21 488 485 / _______________________________________________ enum-sg mailing list enum-sg(a)internetnz.net.nz http://farsight.internetnz.net.nz/mailman/listinfo/enum-sg

1 0

HEADS UP - Upcoming webcast
by Richard Naylor 28 Mar '05

28 Mar '05

Evening All, This is a slightly late-ish advisory that R2.co.nz will be webcasting the NZ Secondary Schools Rowing Championships from Lake Kaipiro on 8 and 9 April. The webcast servers are located at both APE and WIX and network operators may experience a frenzy of teenagers wanting to watch their team win. Or hassling their Help Desks that nothing works. Operators not currently peering at APE or WIX should contact CityLink if they would like assistance with peering. During the webcast, we will be attempting to do the event live, as well as uploading a recorded version of each race, so that folks can relive those few moments of glory. This will add to the potential traffic experienced on the day(s). Thank you for your co-operation. Richard aka richard.naylor(a)r2.co.nz

1 0

Notification of NZRR Database changes
by NZRR Database Notifications 22 Mar '05

22 Mar '05

Dear Colleague, This is to notify you that some object(s) in NZRR database which you either maintain or are listed as to-be-notified have been added, deleted or changed. These objects are used to configure the various NZIX route servers (http://nzix.net/) so you can expect the relevant servers to be reloaded in the near future. The reloading of the servers is staggered over a period of time so that if you are peering with both servers at an exchange, you can maintain at least one BGP session at all times and consequently a full set of routes. The update causing these changes had the following mail headers: - From: Andy Linton <asjl(a)citylink.co.nz> - Cc: - Subject: [CityLink #2128] Routing updates for APE Route Servers (fwd) - Date: Wed, 23 Mar 2005 16:49:23 +1200 (NZST) - Msg-Id: <Pine.LNX.4.58.0503231649060.23389(a)jennings.citylink.co.nz> NZRR Database Notification Department --- PREVIOUS OBJECT: route-set: AS9560:RS-ROUTES:AS9889 descr: advertised to AS9560 by Maxnet - AS9889 members: 210.55.230.0/24^24-29, 210.55.214.0/24^24-29, 210.55.169.0/24^24-29, 210.55.155.0/24^24-29, 210.55.104.0/22^22-29, 210.55.100.0/22^22-29, 202.37.181.0/24^24-29, 202.37.72.0/24^24-29, 202.36.70.0/24^24-29, 202.27.204.0/24^24-29, 202.89.32.0/19^19-29, 202.6.5.0/24^24-29, 202.49.141.0/24^24-29, 203.89.160.0/19^19-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: david.fox(a)maxnet.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050314 source: NZRR REPLACED BY: route-set: AS9560:RS-ROUTES:AS9889 descr: advertised to AS9560 by Maxnet - AS9889 members: 202.6.5.0/24^24-29, 202.27.204.0/24^24-29, 202.36.70.0/24^24-29, 202.37.72.0/24^24-29, 202.37.181.0/24^24-29, 202.49.141.0/24^24-29, 202.89.32.0/19^19-29, 203.89.160.0/19^19-29, 203.97.42.0/24^24-29, 203.167.219.56/29, 210.55.100.0/22^22-29, 210.55.104.0/22^22-29, 210.55.155.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 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: david.fox(a)maxnet.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050323 source: NZRR

1 0

Notification of NZRR Database changes
by NZRR Database Notifications 22 Mar '05

22 Mar '05

Dear Colleague, This is to notify you that some object(s) in NZRR database which you either maintain or are listed as to-be-notified have been added, deleted or changed. These objects are used to configure the various NZIX route servers (http://nzix.net/) so you can expect the relevant servers to be reloaded in the near future. The reloading of the servers is staggered over a period of time so that if you are peering with both servers at an exchange, you can maintain at least one BGP session at all times and consequently a full set of routes. The update causing these changes had the following mail headers: - From: Andy Linton <asjl(a)citylink.co.nz> - Cc: - Subject: [CityLink #2129] Routing updates for WIX Route Servers (fwd) - Date: Wed, 23 Mar 2005 16:48:32 +1200 (NZST) - Msg-Id: <Pine.LNX.4.58.0503231648120.23389(a)jennings.citylink.co.nz> NZRR Database Notification Department --- PREVIOUS OBJECT: route-set: AS9439:RS-ROUTES:AS9889 descr: advertised to AS9439 by Maxnet - AS9889 members: 210.55.230.0/24^24-29, 210.55.214.0/24^24-29, 210.55.169.0/24^24-29, 210.55.155.0/24^24-29, 210.55.104.0/22^22-29, 210.55.100.0/22^22-29, 202.37.181.0/24^24-29, 202.37.72.0/24^24-29, 202.36.70.0/24^24-29, 202.27.204.0/24^24-29, 202.89.32.0/19^19-29, 202.6.5.0/24^24-29, 202.49.141.0/24^24-29, 203.89.160.0/19^19-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: david.fox(a)maxnet.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050318 source: NZRR REPLACED BY: route-set: AS9439:RS-ROUTES:AS9889 descr: advertised to AS9439 by Maxnet - AS9889 members: 202.6.5.0/24^24-29, 202.27.204.0/24^24-29, 202.36.70.0/24^24-29, 202.37.72.0/24^24-29, 202.37.181.0/24^24-29, 202.49.141.0/24^24-29, 202.89.32.0/19^19-29, 203.89.160.0/19^19-29, 203.97.42.0/24^24-29, 203.167.219.56/29, 210.55.100.0/22^22-29, 210.55.104.0/22^22-29, 210.55.155.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 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: david.fox(a)maxnet.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050323 source: NZRR

1 0

telecom planning to break VoIP over its network?
by Joe Abley 21 Mar '05

21 Mar '05

http://www.pbs.org/cringely/pulpit/pulpit20050317.html "And there are other dirty tricks available to broadband ISPs. Telecom New Zealand, for example, is reportedly planning to alter TCP packet interleaving to discourage VoIP. By bunching all voice packets in the first half of each second, half a second of dead air would be added to every conversation, changing latency in a way that would drive grandmothers everywhere back to their old phone companies. This is because phone conversations happen effectively in real time and so are very sensitive to problems of latency. Where one-way video and audio can use buffering to overcome almost any interleaving issue, it is a deal-breaker for voice."

18 22

SANOG 6 in Thumpu, Bhutan, 16-23 July 2005
by Joe Abley 21 Mar '05

21 Mar '05

SANOG VI 16-23 July, 2005 Thimphu, Bhutan SANOG VI Program and Fellowship Announcement SANOG VI program and agenda are now published on <http://www.sanog.org/sanog6/>. SANOG VI is being held in Thimphu, Bhutan from 16-23 July, 2005. You can refer to <www.sanog.org/sanog6/> for details. Program and Agenda SANOG VI program incorporates the following: Three hands-on workshops (16-20 July 2005) - IP Services Workshop - ISP Routing and BGP Multihoming Workshop - ISP and NSP Security Workshop, Tutorials (21-22 July 2005) - BGP and High Availability Routing Workshop by Juniper - VOIP and SIP Deployment - ISP and Network Security - IP Networks and Wireless Architecture - Netflow / Flowtools - DNS and DNSSec deployment Birds-of-a-Feather (22 July 2005) - Regional Updates BoF - APNIC BoF Full Day Conference Program (23 July 2005) - Routing and Internet Operations - Network Architecture and - Application Deployment Additional Programs: (21-23 July 2005) - APNIC Regional policy update - APNIC hostmaster Consultation SANOG VI Fellowship Annoucement SANOG VI is also pleased to annouce the fellowship program with support of the Internet Society and Network Startup Resource Center (NSRC). SANOG VI fellows will received a maximum of USD 500 towards air fare and local accomodation during the event. You can find more information about the fellowship program from the SANOG Fellowship Site at <http://www.sanog.org/fellowship/>. SANOG VI Call for Papers SANOG VI Call for papers for the conference is available online at <http://www.sanog.org/sanog6/cfp.htm>. Everyone is Welcome We expect a huge turn out from the region at this SANOG meeting owing to the popularity at previous meets. With more involvement of APNIC in the content of overall program, We hope you would be able to make it to this meeting. The meeting is open to everyone from the operational community, and thus anyone who wants to find out more about Internet operations in South Asia is welcome. You can register for SANOG by sending in the form available at <www.sanog.org/sanog6/> or using the online registration system. Registrations from inside Bhutan can be paid by cheques.

1 0

RE: [nznog] telecom planning to break VoIP over its network?
by Philip D'Ath 20 Mar '05

20 Mar '05

Perhaps you missed the billion dollar announcement they made sometime ago how they are building a new all IP network, and are phasing out most of the old PSTN exchanges. From memory, something like 700 of them are scheduled to be decommissioned. -----Original Message----- Perhaps I phrased that a little off, what I was meaning to insinuate was that they wouldn't be ditching the ole PSTN anytime soon. But hey *shrug* there are alot of varying ideas on that aswell. -Richard _______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog

2 1

OT: WTD: Cisco expert for short job in Sydney, .au.
by Zach Bagnall 20 Mar '05

20 Mar '05

Hey all. We're sending a router (Cisco 831) to a datacentre in Sydney, and need someone to install on site, establish connectivity, and get an IPSec tunnel up. The router has been configured for NAT and IPSec here in NZ, but obviously not tested in the live environment. Probably an hour or so to get connectivity up, and a few more to liase with the techs on the other end of the VPN in order establish that connection. Hoping to get this done in the week following Easter. Any (off-list) personal recommendations appreciated. Zach.

4 3

RE: [nznog] telecom planning to break VoIP over its network?
by Olof Olsson 20 Mar '05

20 Mar '05

All, I believe the only "things" that Telecom have done to-date are: 1. To change the ADSL modulation speed to each subscribers "plan speed" + ATM overhead. For example, the 256/128 kbps plan has an ADSL modulation speed of 320/160 kbps (downstream/upstream). 2. Always have ADSL interleaving on, with a relatively long interleaving delay. Interleaving is used between the ADSL modem and the DSLAM to improve error correction performance against burst errors. The above means: *** An interleaving delay of approximately 28 ms is introduced *** A serialisation delay of approximately 3-50 ms is introduced (64 - 1024 byte packets). In other words, the total one-way latency is approximately 36 - 83 ms depending on packet size. Jitter will of course increase as latency increses. (Packets arriving behind large packets etc.) Which is bad for VoIP. The question is: did Telecom do this to make VoIPoUBS harder to implement? (The latency and jitter could be significantly reduced by lowering the interleaving delay and by not limiting ADSL modulation rates. Interleaving is not needed if the subscribers local loop is of a reasonable quality.) --Olof

1 0

RE: [nznog] telecom planning to break VoIP over its network?
by Philip D'Ath 18 Mar '05

18 Mar '05

This sounds like a porky to me. That's a lot of effort to go to. Telecom are a revenue generating company. Do you spend lots of try trying to devise methods to stop protocols working that you likely to be using yourself long term, or stick to spending your money on developing new products to generate more money. -----Original Message----- From: Joe Abley [mailto:jabley(a)isc.org] Sent: Friday, 18 March 2005 1:26 p.m. To: nznog Subject: [nznog] telecom planning to break VoIP over its network? http://www.pbs.org/cringely/pulpit/pulpit20050317.html "And there are other dirty tricks available to broadband ISPs. Telecom New Zealand, for example, is reportedly planning to alter TCP packet interleaving to discourage VoIP. By bunching all voice packets in the first half of each second, half a second of dead air would be added to every conversation, changing latency in a way that would drive grandmothers everywhere back to their old phone companies. This is because phone conversations happen effectively in real time and so are very sensitive to problems of latency. Where one-way video and audio can use buffering to overcome almost any interleaving issue, it is a deal-breaker for voice." _______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog

4 5

RE: [nznog] telecom planning to break VoIP over its network?
by Philip D'Ath 17 Mar '05

17 Mar '05

Its quite the opposite actually. It's much better to drop VoIP packets on VoIP codec streams (aka RTP streams) than it is to queue them. From my experience you can loose about 30% of the packets on a G.711 RTP stream within minimal impact on the voice itself. Queuing them on the other hand causes the jitter buffers to start extending themselves to compensate in the variations in latency caused by the buffer. This leads to a lag between when you speak and you hear the other person responding on the other end responding to you. I find rate limiting works best for UDP and traffic shaping works best for TCP. ps. UDP streaming applications don't re-transmit packets. If your doing something real time and you loose the packet, you loose the packet. This can lead to the video becoming jumpy, or the audio breaking up. -----Original Message----- From: Erin Salmon - Unleash Computers Ltd [mailto:erin(a)unleash.co.nz] Sent: Friday, 18 March 2005 2:40 p.m. To: nznog(a)list.waikato.ac.nz Subject: RE: [nznog] telecom planning to break VoIP over its network? In regards to Craig Spiers' comments, I doubt Telecom would see any amount of processing power as justification not to render VoIP useless on their networks. 20,000 Skype users must be hurting them. I think you can be 99.9% confident that IDGs statements about UBS are correct. Try using a VoIP application on a UBS line, especially during peak times, and you'll see what I mean. In order to cap the speed to 256kbps Telecom does just drop packets. I understand this is a limitation of the current hardware at the exchanges, and that it will be replaced at some point in the future by equipment which can queue packets instead (probably when they roll out ADSL2+). While queuing packets isn't fantastic for VoIP either, it's a step forward from dropping them altogether. Queuing is certainly more efficient for ordinary TCP and even streamed UDP traffic, because data doesn't need to be resent from the source. NZ needs some competition in the Telco market.

1 0

ConceptNET AS17474
by Craig Spiers 17 Mar '05

17 Mar '05

For those of you peering with ConceptNET please update your prefix lists. Changes: Updated 202.150.96.0/20 to 202.150.96.0/19 (currently advertised as 2x /20) Full Prefix List: ip prefix-list conceptnet-domestic-ape description ConceptNET Domestic Routes VIA APE <craig(a)concept.net.nz> ip prefix-list conceptnet-domestic-ape seq 5 permit 202.150.96.0/19 ip prefix-list conceptnet-domestic-ape seq 10 permit 202.127.8.0/22 ip prefix-list conceptnet-domestic-ape seq 15 permit 203.97.44.0/24 ip prefix-list conceptnet-domestic-ape seq 20 permit 202.7.5.32/29 ip prefix-list conceptnet-domestic-ape seq 25 permit 202.7.6.32/29 Regards, Craig - ConceptNET

1 0

Upcoming Webcasts on R2.co.nz
by Richard Naylor 17 Mar '05

17 Mar '05

After a hectic few weeks of webcasts, heres whats coming, so that you can be prepared. Saturday 26 March - a wedding in Carterton. Not expected to cause any major traffic flows. But I'm sure they'll drink beer at the reception (just to keep this on topic). Theres lots of video of the past few events going up at the moment. We hope this will include footage of the 30minute "World of Bendon" dance routine from Girl's Day Out. (is that in our terms of reference ? do I get extra bonus points ?) rich

1 0

Re: Re: [nznog] telecom planning to break VoIP over its network?
by Ian McDonald 17 Mar '05

17 Mar '05

> So why would Telecom behave any different in a LLU world? Because they would have to. > Sure, pick a > metric and we'll be a modest percentage better off, however people will still > be complaining, and we still won't have what we really want. > Depends what you mean by modest percentage. The whole point of LLU is that other companies can start using their own equipment - and they do. Witness the growth in Australia, USA and the UK where LLU along with a heavy regulation environment is seeing much higher speed delivered to users then here in NZ. > Spend the time, effort and money on building networks, not chasing, > implementing and then fighting to actually get something useful from LLU. > I'm an observer, not an ISP but understand what you are saying here. I agree we won't be the same as other countries due to our geography but at least we would achieve real results in Auckland.... (which is not where I live). > Cheers, > Jonny. > > I'll stop here now before it goes (any further) into a flame war. Ian

1 0

Re: Re: [nznog] telecom planning to break VoIP over its network?
by Jonny Martin 17 Mar '05

17 Mar '05

> Of course Telecom will object against LLU as it DOES hurt their bottom > line and they are owned by shareholders. It really has to be a policy > decision by the government. So why would Telecom behave any different in a LLU world? Sure, pick a metric and we'll be a modest percentage better off, however people will still be complaining, and we still won't have what we really want. Spend the time, effort and money on building networks, not chasing, implementing and then fighting to actually get something useful from LLU. Cheers, Jonny.

1 0

Notification of NZRR Database changes
by NZRR Database Notifications 17 Mar '05

17 Mar '05

Dear Colleague, This is to notify you that some object(s) in NZRR database which you either maintain or are listed as to-be-notified have been added, deleted or changed. These objects are used to configure the various NZIX route servers (http://nzix.net/) so you can expect the relevant servers to be reloaded in the near future. The reloading of the servers is staggered over a period of time so that if you are peering with both servers at an exchange, you can maintain at least one BGP session at all times and consequently a full set of routes. The update causing these changes had the following mail headers: - From: Andy Linton <asjl(a)citylink.co.nz> - Cc: - Subject: [CityLink #2108] Routing updates for WIX Route Servers (fwd) - Date: Fri, 18 Mar 2005 15:22:12 +1300 (NZDT) - Msg-Id: <Pine.LNX.4.58.0503181521560.19063(a)jennings.citylink.co.nz> NZRR Database Notification Department --- PREVIOUS OBJECT: route-set: AS9439:RS-ROUTES:AS17474 descr: Route set advertised to AS9439 by ConceptNET - AS17474 members: 202.150.96.0/20^20-29, 203.97.44.0/24^24-29, 202.49.250.0/24^24-29, 202.50.176.0/24^24-29, 202.127.8.0/22^22-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: craig(a)concept.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20040908 source: NZRR REPLACED BY: route-set: AS9439:RS-ROUTES:AS17474 descr: advertised to AS9439 by Craig Spiers - AS17474 members: 202.150.96.0/19^19-29, 202.127.8.0/22^22-29, 203.97.44.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: craig(a)concept.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050318 source: NZRR

1 0

Notification of NZRR Database changes
by NZRR Database Notifications 17 Mar '05

17 Mar '05

Dear Colleague, This is to notify you that some object(s) in NZRR database which you either maintain or are listed as to-be-notified have been added, deleted or changed. These objects are used to configure the various NZIX route servers (http://nzix.net/) so you can expect the relevant servers to be reloaded in the near future. The reloading of the servers is staggered over a period of time so that if you are peering with both servers at an exchange, you can maintain at least one BGP session at all times and consequently a full set of routes. The update causing these changes had the following mail headers: - From: Andy Linton <asjl(a)citylink.co.nz> - Cc: - Subject: [CityLink #2107] Routing updates for APE Route Servers (fwd) - Date: Fri, 18 Mar 2005 15:21:36 +1300 (NZDT) - Msg-Id: <Pine.LNX.4.58.0503181521180.19063(a)jennings.citylink.co.nz> NZRR Database Notification Department --- PREVIOUS OBJECT: route-set: AS9560:RS-ROUTES:AS17474 descr: advertised to AS9560 by Craig Spiers - AS17474 members: 202.150.96.0/20^20-29, 202.127.8.0/22^22-29, 203.97.44.0/24^24-29, 202.50.176.0/24^24-29, 202.7.6.32/29, 202.7.5.32/29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: craig(a)concept.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050314 source: NZRR REPLACED BY: route-set: AS9560:RS-ROUTES:AS17474 descr: advertised to AS9560 by Craig Spiers - AS17474 members: 202.150.96.0/19^19-29, 202.127.8.0/22^22-29, 203.97.44.0/24^24-29, 202.7.5.32/29, 202.7.6.32/29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: craig(a)concept.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050318 source: NZRR

1 0

Notification of NZRR Database changes
by NZRR Database Notifications 17 Mar '05

17 Mar '05

Dear Colleague, This is to notify you that some object(s) in NZRR database which you either maintain or are listed as to-be-notified have been added, deleted or changed. These objects are used to configure the various NZIX route servers (http://nzix.net/) so you can expect the relevant servers to be reloaded in the near future. The reloading of the servers is staggered over a period of time so that if you are peering with both servers at an exchange, you can maintain at least one BGP session at all times and consequently a full set of routes. The update causing these changes had the following mail headers: - From: Andy Linton <asjl(a)citylink.co.nz> - Cc: - Subject: RE: [CityLink #2105] AutoReply: Routing updates for WIX Route Servers (fwd) - Date: Fri, 18 Mar 2005 15:20:32 +1300 (NZDT) - Msg-Id: <Pine.LNX.4.58.0503181520070.19063(a)jennings.citylink.co.nz> NZRR Database Notification Department --- PREVIOUS OBJECT: route-set: AS9439:RS-ROUTES:AS9889 descr: Route set advertised to AS9439 by Maxnet - AS9889 members: 202.14.217.0/24^24-29, 202.27.204.0/24^24-29, 202.36.70.0/24^24-29, 202.37.72.0/24^24-29, 202.37.181.0/24^24-29, 202.50.167.0/24^24-29, 202.89.32.0/19^19-29, 210.55.29.0/24^24-29, 210.55.100.0/22^22-29, 210.55.104.0/22^22-29, 210.55.110.0/24^24-29, 210.55.155.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 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: alastair.johnson(a)maxnet.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20041008 source: NZRR REPLACED BY: route-set: AS9439:RS-ROUTES:AS9889 descr: advertised to AS9439 by Maxnet - AS9889 members: 210.55.230.0/24^24-29, 210.55.214.0/24^24-29, 210.55.169.0/24^24-29, 210.55.155.0/24^24-29, 210.55.104.0/22^22-29, 210.55.100.0/22^22-29, 202.37.181.0/24^24-29, 202.37.72.0/24^24-29, 202.36.70.0/24^24-29, 202.27.204.0/24^24-29, 202.89.32.0/19^19-29, 202.6.5.0/24^24-29, 202.49.141.0/24^24-29, 203.89.160.0/19^19-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: david.fox(a)maxnet.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050318 source: NZRR

1 0

Notification of NZRR Database changes
by NZRR Database Notifications 17 Mar '05

17 Mar '05

Dear Colleague, This is to notify you that some object(s) in NZRR database which you either maintain or are listed as to-be-notified have been added, deleted or changed. These objects are used to configure the various NZIX route servers (http://nzix.net/) so you can expect the relevant servers to be reloaded in the near future. The reloading of the servers is staggered over a period of time so that if you are peering with both servers at an exchange, you can maintain at least one BGP session at all times and consequently a full set of routes. The update causing these changes had the following mail headers: - From: Andy Linton <asjl(a)citylink.co.nz> - Cc: - Subject: [CityLink #2103] Routing updates for WIX Route Servers (fwd) - Date: Fri, 18 Mar 2005 15:18:45 +1300 (NZDT) - Msg-Id: <Pine.LNX.4.58.0503181518250.19063(a)jennings.citylink.co.nz> NZRR Database Notification Department --- PREVIOUS OBJECT: route-set: AS9439:RS-ROUTES:AS4770 descr: advertised to AS9439 by ICONZ - AS4770 members: 138.235.0.0/16^16-29, 192.107.113.0/24^24-29, 192.173.16.0/21^21-29, 198.32.66.0/24^24-29, 199.212.93.0/24^24-29, 202.6.84.0/24^24-29, 202.12.70.0/24^24-29, 202.12.248.0/21^21-29, 202.14.100.0/24^24-29, 202.20.6.0/24^24-29, 202.21.130.0/24^24-29, 202.21.136.0/23^23-29, 202.36.155.0/24^24-29, 202.36.157.0/24^24-29, 202.36.32.0/24^24-29, 202.36.36.0/22^22-29, 202.36.44.0/24^24-29, 202.36.45.0/24^24-29, 202.36.76.0/23^23-29, 202.36.119.0/24^24-29, 202.37.136.0/24^24-29, 202.37.140.0/22^22-29, 202.37.144.0/21^21-29, 202.37.163.0/24^24-29, 202.37.197.0/24^24-29, 202.37.200.0/22^22-29, 202.37.224.0/21^21-29, 202.37.232.0/24^24-29, 202.37.240.0/23^23-29, 202.37.252.0/23^23-29, 202.37.76.0/24^24-29, 202.37.85.0/24^24-29, 202.41.136.0/22^22-29, 202.41.140.0/24^24-29, 202.46.190.0/24^24-29, 202.49.62.0/24^24-29, 202.49.89.0/24^24-29, 202.49.249.0/24^24-29, 202.49.159.0/24^24-29, 202.50.87.0/24^24-29, 202.50.246.0/24^24-29, 202.55.96.0/20^20-29, 202.74.224.0/21^21-29, 202.78.240.0/23^23-29, 202.182.192.0/19^19-29, 205.233.128.0/21^21-29, 205.233.136.0/23^23-29, 205.233.243.0/24^24-29, 210.185.0.0/18^18-29, 210.48.0.0/17^17-29, 210.54.136.0/22^22-29, 210.54.140.0/24^24-29, 210.54.160.0/19^19-29, 210.55.182.0/23^23-29, 210.55.24.0/22^22-29, 210.55.253.0/24^24-29, 210.56.32.0/20^20-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: john(a)iconz.net mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050304 source: NZRR REPLACED BY: route-set: AS9439:RS-ROUTES:AS4770 descr: advertised to AS9439 by ICONZ - AS4770 members: 138.235.0.0/16^16-29, 192.107.113.0/24^24-29, 192.173.16.0/21^21-29, 198.32.66.0/24^24-29, 199.212.93.0/24^24-29, 202.6.84.0/24^24-29, 202.12.70.0/24^24-29, 202.12.248.0/21^21-29, 202.14.100.0/24^24-29, 202.20.6.0/24^24-29, 202.21.130.0/24^24-29, 202.21.136.0/23^23-29, 202.36.155.0/24^24-29, 202.36.157.0/24^24-29, 202.36.32.0/24^24-29, 202.36.36.0/22^22-29, 202.36.44.0/24^24-29, 202.36.45.0/24^24-29, 202.36.76.0/23^23-29, 202.36.119.0/24^24-29, 202.37.136.0/24^24-29, 202.37.140.0/22^22-29, 202.37.144.0/21^21-29, 202.37.163.0/24^24-29, 202.37.197.0/24^24-29, 202.37.200.0/22^22-29, 202.37.224.0/21^21-29, 202.37.232.0/24^24-29, 202.37.240.0/23^23-29, 202.37.252.0/23^23-29, 202.37.76.0/24^24-29, 202.37.85.0/24^24-29, 202.41.136.0/22^22-29, 202.41.140.0/24^24-29, 202.46.190.0/24^24-29, 202.49.62.0/24^24-29, 202.49.89.0/24^24-29, 202.49.249.0/24^24-29, 202.49.159.0/24^24-29, 202.50.87.0/24^24-29, 202.50.246.0/24^24-29, 202.55.96.0/20^20-29, 202.74.224.0/21^21-29, 202.78.240.0/21^21-29, 202.182.192.0/19^19-29, 205.233.128.0/21^21-29, 205.233.136.0/23^23-29, 205.233.243.0/24^24-29, 210.185.0.0/18^18-29, 210.48.0.0/17^17-29, 210.54.136.0/22^22-29, 210.54.140.0/24^24-29, 210.54.160.0/19^19-29, 210.55.182.0/23^23-29, 210.55.24.0/22^22-29, 210.56.32.0/20^20-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: john(a)iconz.net mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050318 source: NZRR

1 0

Notification of NZRR Database changes
by NZRR Database Notifications 17 Mar '05

17 Mar '05

Dear Colleague, This is to notify you that some object(s) in NZRR database which you either maintain or are listed as to-be-notified have been added, deleted or changed. These objects are used to configure the various NZIX route servers (http://nzix.net/) so you can expect the relevant servers to be reloaded in the near future. The reloading of the servers is staggered over a period of time so that if you are peering with both servers at an exchange, you can maintain at least one BGP session at all times and consequently a full set of routes. The update causing these changes had the following mail headers: - From: Andy Linton <asjl(a)citylink.co.nz> - Cc: - Subject: [CityLink #2102] Routing updates for APE Route Servers (fwd) - Date: Fri, 18 Mar 2005 15:18:10 +1300 (NZDT) - Msg-Id: <Pine.LNX.4.58.0503181517410.19063(a)jennings.citylink.co.nz> NZRR Database Notification Department --- PREVIOUS OBJECT: route-set: AS9560:RS-ROUTES:AS4770 descr: advertised to AS9560 by ICONZ - AS4770 members: 138.235.0.0/16^16-29, 192.107.113.0/24^24-29, 192.173.16.0/21^21-29, 198.32.66.0/24^24-29, 199.212.93.0/24^24-29, 202.6.84.0/24^24-29, 202.12.70.0/24^24-29, 202.12.248.0/21^21-29, 202.14.100.0/24^24-29, 202.20.6.0/24^24-29, 202.21.130.0/24^24-29, 202.21.136.0/23^23-29, 202.36.155.0/24^24-29, 202.36.157.0/24^24-29, 202.36.32.0/24^24-29, 202.36.36.0/22^22-29, 202.36.44.0/24^24-29, 202.36.45.0/24^24-29, 202.36.76.0/23^23-29, 202.36.119.0/24^24-29, 202.37.136.0/24^24-29, 202.37.140.0/22^22-29, 202.37.144.0/21^21-29, 202.37.163.0/24^24-29, 202.37.197.0/24^24-29, 202.37.200.0/22^22-29, 202.37.224.0/21^21-29, 202.37.232.0/24^24-29, 202.37.240.0/23^23-29, 202.37.252.0/23^23-29, 202.37.76.0/24^24-29, 202.37.85.0/24^24-29, 202.41.136.0/22^22-29, 202.41.140.0/24^24-29, 202.46.190.0/24^24-29, 202.49.62.0/24^24-29, 202.49.89.0/24^24-29, 202.49.249.0/24^24-29, 202.49.159.0/24^24-29, 202.50.87.0/24^24-29, 202.50.246.0/24^24-29, 202.55.96.0/20^20-29, 202.74.224.0/21^21-29, 202.78.240.0/23^23-29, 202.182.192.0/19^19-29, 205.233.128.0/21^21-29, 205.233.136.0/23^23-29, 205.233.243.0/24^24-29, 210.185.0.0/18^18-29, 210.48.0.0/17^17-29, 210.54.136.0/22^22-29, 210.54.140.0/24^24-29, 210.54.160.0/19^19-29, 210.55.182.0/23^23-29, 210.55.24.0/22^22-29, 210.55.253.0/24^24-29, 210.56.32.0/20^20-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: john(a)iconz.net mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050304 source: NZRR REPLACED BY: route-set: AS9560:RS-ROUTES:AS4770 descr: advertised to AS9560 by ICONZ - AS4770 members: 138.235.0.0/16^16-29, 192.107.113.0/24^24-29, 192.173.16.0/21^21-29, 198.32.66.0/24^24-29, 199.212.93.0/24^24-29, 202.6.84.0/24^24-29, 202.12.70.0/24^24-29, 202.12.248.0/21^21-29, 202.14.100.0/24^24-29, 202.20.6.0/24^24-29, 202.21.130.0/24^24-29, 202.21.136.0/23^23-29, 202.36.155.0/24^24-29, 202.36.157.0/24^24-29, 202.36.32.0/24^24-29, 202.36.36.0/22^22-29, 202.36.44.0/24^24-29, 202.36.45.0/24^24-29, 202.36.76.0/23^23-29, 202.36.119.0/24^24-29, 202.37.136.0/24^24-29, 202.37.140.0/22^22-29, 202.37.144.0/21^21-29, 202.37.163.0/24^24-29, 202.37.197.0/24^24-29, 202.37.200.0/22^22-29, 202.37.224.0/21^21-29, 202.37.232.0/24^24-29, 202.37.240.0/23^23-29, 202.37.252.0/23^23-29, 202.37.76.0/24^24-29, 202.37.85.0/24^24-29, 202.41.136.0/22^22-29, 202.41.140.0/24^24-29, 202.46.190.0/24^24-29, 202.49.62.0/24^24-29, 202.49.89.0/24^24-29, 202.49.249.0/24^24-29, 202.49.159.0/24^24-29, 202.50.87.0/24^24-29, 202.50.246.0/24^24-29, 202.55.96.0/20^20-29, 202.74.224.0/21^21-29, 202.78.240.0/21^21-29, 202.182.192.0/19^19-29, 205.233.128.0/21^21-29, 205.233.136.0/23^23-29, 205.233.243.0/24^24-29, 210.185.0.0/18^18-29, 210.48.0.0/17^17-29, 210.54.136.0/22^22-29, 210.54.140.0/24^24-29, 210.54.160.0/19^19-29, 210.55.182.0/23^23-29, 210.55.24.0/22^22-29, 210.56.32.0/20^20-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: john(a)iconz.net mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050318 source: NZRR

1 0

Re: RE: [nznog] telecom planning to break VoIP over its network?
by Jonny Martin 17 Mar '05

17 Mar '05

> NZ needs some competition in the Telco market. I have to disagree with that. There is only one steady state equilibrium in a traditional telco market. We have that already. What we need are more _alternatives_ to telcos. Get out there and build some network. It's not that hard :) Cheers, Jonny.

1 0

Updating the APE and WIX route servers
by Andy Linton 17 Mar '05

17 Mar '05

Can I remind you that when you want us to make changes to the filters which control what you can announce on the exchanges you need to complete the forms at: APE http://ape.nzix.net/cgi-bin/ChangeRoutes.cgi WIX http://wix.nzix.net/cgi-bin/ChangeRoutes.cgi Please note that if you want changes at both exchanges you need to ask explicitly by completing *both* forms. We won't attempt to use telepathy as part of this process.

1 0

ICONZ Prefix list update - 2005-03-18
by John Johnston 17 Mar '05

17 Mar '05

AS: 4770 APE: 192.203.154.44 WIX: 202.7.1.1 Hey all, For all those that peer direct with ICONZ here is an update. Current list is attached or goto http://www.iconz.net/prefix Regards John Johnston Network Engineering Manager ICONZ New Zealand Limited DDI: +64 9 977 3500 FAX: +64 9 977 3535 Mobile: 021 277 5692 Email: john.johnston(a)iconz.net 0800 THE NET www.iconz.net

1 0

Anycast and how it can work for you
by Barry Murphy 17 Mar '05

17 Mar '05

Hey Guys, Just wondering how many providers other than citylink adapt anycast into their network. I decided to write something here to explain to others what it is and how I've implemented it. To start, I run www.fast.co.nz which provides _free_ downloads of open source ISOs and websites. Since certain ISPs decided to depeer the ISP that was hosting my server couldn't fit the bill for this free content, even though it was saving the providers international bandwidth, thus I incorporated anycast. I have a server in Wellington connected to WIX and another on APE. Both servers advertise the IP range 202.7.6.32/29, ovcourse the Auckland server to APE and the Wellington server to WIX, Citylink then advertise the same range at a datacenter in the USA. If a users provider is connected to one of the above exchanges, they are connected to the Server closest to them, if they don't peer at either exchange they are sent to the USA server Where in my case they are forwarded to http://peer.fast.co.nz . In a commercial environment such as Trademe this could be implemented to save money. Trademe Could run it's servers in Wellington the same way they are now, and server the content to anyone That peers at the WIX, they can then advertise the same ip range in the USA and mirror the servers or maybe just an image server for the .jpg, .gif, .png images etc. How does this save money having servers in the USA, well to rent colo space and a p4 2.8gig Server in the USA costs me as little as $80 p/m for 1tb, that's right 1024Gigs worth of data And the connection is very stable. For commercial companies such as Trademe they may require a Little more bandwidth than a TB and support 24/7 etc, so they may pay tops $400 p/m, this would Be a LOT cheaper than buying additional circuits from providers in NZ. How this would effect providers that have depeered? Well lets take stuff for example, we know They push close to 25Mb/s at times, lets add Trademe and say they push 50Mb/s , well this would Mean that the providers that don't peer will be spending a couple hundred thousand $ to provide The content to their users, it would be cheaper for them to just peer. The above is just an explanation of anycast and how it could be used to serve your websites or A way to better manage your network. Any views written to the NZNog are always the view of my own And not those of my peers or employers. Regards Barry

3 2

Recovery of unused address space-implementation
by Elly Tawhai 16 Mar '05

16 Mar '05

Hi, Just forwarding this annoucement made about the Recovery of unused address space-implementation for those from NZ not subscribed to Apnic-announce mailing list. Regards, Elly APNIC * To: apnic-announce(a)apnic.net * Subject: [apnic-talk] [Apnic-announce] Recovery of unused address space -implementation * From: APNIC Secretariat <secretariat(a)apnic.net> * Date: Fri, 18 Feb 2005 11:53:47 +1000 * Cc: * List-archive: <http://www.apnic.net/mailing-lists/apnic-talk> * List-help: <mailto:apnic-talk-request(a)lists.apnic.net?subject=help> * List-id: General discussions on APNIC <apnic-talk.lists.apnic.net> * List-post: <mailto:apnic-talk(a)lists.apnic.net> * List-subscribe: <http://mailman.apnic.net/mailman/listinfo/apnic-talk>,<mailto:apnic-talk-request(a)lists.apnic.net?subject=subscribe> * List-unsubscribe: <http://mailman.apnic.net/mailman/listinfo/apnic-talk>,<mailto:apnic-talk-request(a)lists.apnic.net?subject=unsubscribe> * Reply-to: apnic-talk(a)apnic.net * Sender: apnic-announce-bounces(a)lists.apnic.net * User-agent: Mozilla Thunderbird 0.8 (Macintosh/20040913) Dear colleagues, In March 2005, the APNIC Secretariat will implement the policy, "Recovery of unused address space". The policy is described in section 5 of "Policies for historical Internet resources in the APNIC Whois Database" at: http://www.apnic.net/docs/policy/historical-resource-policies.html#5 This policy implements the consensus decision reached at APNIC 17 and endorsed by the Executive Council on 14 May in relation to proposal prop-017-v001. Details of the original proposal and links to discussions are available at: http://www.apnic.net/docs/policy/proposals/prop-017-v001.html For more information about this policy, please see the "Guide to the recovery of unused address space" at: http://www.apnic.net/docs/policy/historical-recovery-guide.html If you have questions about this policy, please contact the APNIC helpdesk at: Email: helpdesk(a)apnic.net Phone: +617 3858 3188 Fax: +617 3858 3199 Regards, ______________________________________________________________________ APNIC Secretariat <secretariat(a)apnic.net> Asia Pacific Network Information Centre (APNIC) Tel: +61-7-3858-3100 PO Box 2131 Milton, QLD 4064 Australia Fax: +61-7-3858-3199 ----------------------------------------------------------------------

3 2

peering discussion on the radio with Russell OConnell
by Barry Murphy 16 Mar '05

16 Mar '05

Original mp3 was taken from http://www.95bfm.com/hardnews.php however I cannot locate it now: http://anycast.fast.co.nz/extras/russelloconnell-2005-03-16-bfm.mp3 (For ape or wix connected users only) Regards Barry

2 1

University of Auckland peering at the APE
by Andy Linton 15 Mar '05

15 Mar '05

Their peering session has been up now for about three hours. If you're an APE route server peer and you route to them via more expensive 'Domestic Transit Services' you may want to architect a different solution. They're announcing 130.216.0.0/16. If you are connected to the APE switch fabric and you're not peering with the route servers we'd be happy to help.

1 0

Routes from Ihug and possibly others
by Barry Murphy 14 Mar '05

14 Mar '05

Hey there, I've had a few reports from ihug customers trying to get to the following IP ranges that fall off APE: 202.7.6.32/29 - WIX Only 202.7.5.32/29 - APE Only 202.7.6.32/29 - ANYCAST (advertised at both exchanges) These ranges are provided by citylink for an APE only and anycast range, if your accepting routes from the route-servers, please check your filters and allow traffic for the above 3 ranges. These IP's pass traffic for the www.fast.co.nz project with opensource mirrors and downloads, if you want your users to be able to receive these downloads in the cheapest and quickest possible way, then fix it :) Thanks Barry

1 1

Notification of NZRR Database changes
by NZRR Database Notifications 14 Mar '05

14 Mar '05

Dear Colleague, This is to notify you that some object(s) in NZRR database which you either maintain or are listed as to-be-notified have been added, deleted or changed. These objects are used to configure the various NZIX route servers (http://nzix.net/) so you can expect the relevant servers to be reloaded in the near future. The reloading of the servers is staggered over a period of time so that if you are peering with both servers at an exchange, you can maintain at least one BGP session at all times and consequently a full set of routes. The update causing these changes had the following mail headers: - From: Andy Linton <asjl(a)citylink.co.nz> - Cc: - Subject: [CityLink #2078] Routing updates for WIX Route Servers (fwd) - Date: Tue, 15 Mar 2005 11:52:52 +1300 (NZDT) - Msg-Id: <Pine.LNX.4.58.0503151152250.14480(a)jennings.citylink.co.nz> NZRR Database Notification Department --- PREVIOUS OBJECT: route-set: AS9439:RS-ROUTES:AS18406 descr: advertised to AS9439 by FX Networks - AS18406 members: 202.53.176.0/20^20-29, 202.7.4.72/29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: noc-minor(a)fx.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20041116 source: NZRR REPLACED BY: route-set: AS9439:RS-ROUTES:AS18406 descr: advertised to AS9439 by FX Networks - AS18406 members: 202.53.189.0/24^24-29, 161.29.254.0/23^23-29, 202.7.4.72/29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: noc-minor(a)fx.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050315 source: NZRR --- PREVIOUS OBJECT: route: 202.7.4.72/29 descr: Route for FX Networks - AS18406 descr: WIX experimental block origin: AS18406 notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: noc-minor(a)fx.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20041116 source: NZRR REPLACED BY: route: 202.7.4.72/29 descr: Route for FX Networks - AS18406 origin: AS18406 notify: rpsl-admin(a)nzix.net notify: noc-minor(a)fx.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050315 source: NZRR

1 0

nznog06
by Simon Lyall 14 Mar '05

14 Mar '05

In the next little while we'll probably do a survey on nznog05 and what people want from nznog06. 1. If anybody has any topics, talsk or areas they would like to suggest for nznog06 can they please email me. I can add these to the survey to gague the level of interest for them. 2. One way we might do the survey is via a webpage like: http://www.nanogpc.org/survey/public/survey.php?name=npc_0205 If somebody is setup to host, create one of these ( with at least a human-readable result output) can they email me please. If not we'll do it via email or perhaps a site like www.surveygalaxy.com . -- Simon J. Lyall. | Very Busy | Mail: simon(a)darkmere.gen.nz "To stay awake all night adds a day to your life" - Stilgar | eMT.

1 0

NetSmart APE prefix list update
by Paul Horak 14 Mar '05

14 Mar '05

If you peer with NetSmart at APE (ASN 10200) please note the following changes: Added 202.37.168.0/24 Full list 202.27.83.0/24 202.36.75.0/24 202.37.168.0/24 If you don't peer with us but want to I would be pleased to hear from you. :-) Cheers, Paul NetSmart Ltd http://www.netsmart.co.nz/, Level 2, Regency House, 1 Elizabeth Street, P O Box 15020, Tauranga, New Zealand Tel: 07 5711367 Fax: 07 5711372

1 0

Notification of NZRR Database changes
by NZRR Database Notifications 13 Mar '05

13 Mar '05

Dear Colleague, This is to notify you that some object(s) in NZRR database which you either maintain or are listed as to-be-notified have been added, deleted or changed. These objects are used to configure the various NZIX route servers (http://nzix.net/) so you can expect the relevant servers to be reloaded in the near future. The reloading of the servers is staggered over a period of time so that if you are peering with both servers at an exchange, you can maintain at least one BGP session at all times and consequently a full set of routes. The update causing these changes had the following mail headers: - From: Andy Linton <asjl(a)citylink.co.nz> - Cc: - Subject: RE: [CityLink #2073] AutoReply: Routing updates for APE Route Servers (fwd) - Date: Mon, 14 Mar 2005 16:30:40 +1300 (NZDT) - Msg-Id: <Pine.LNX.4.58.0503141630100.13184(a)jennings.citylink.co.nz> NZRR Database Notification Department --- PREVIOUS OBJECT: route-set: AS9560:RS-ROUTES:AS9889 descr: advertised to AS9560 by Maxnet - AS9889 members: 210.55.230.0/24^24-29, 210.55.214.0/24^24-29, 210.55.169.0/24^24-29, 210.55.155.0/24^24-29, 210.55.104.0/22^22-29, 210.55.100.0/22^22-29, 202.37.181.0/24^24-29, 202.37.72.0/24^24-29, 202.36.70.0/24^24-29, 202.27.204.0/24^24-29, 202.89.32.0/19^19-29, 202.6.5.0/24^24-29, 202.49.141.0/24^24-29, 203.89.160.0/19^19-29, 202.7.5.32/29, 202.7.6.32/29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: david.fox(a)maxnet.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050307 source: NZRR REPLACED BY: route-set: AS9560:RS-ROUTES:AS9889 descr: advertised to AS9560 by Maxnet - AS9889 members: 210.55.230.0/24^24-29, 210.55.214.0/24^24-29, 210.55.169.0/24^24-29, 210.55.155.0/24^24-29, 210.55.104.0/22^22-29, 210.55.100.0/22^22-29, 202.37.181.0/24^24-29, 202.37.72.0/24^24-29, 202.36.70.0/24^24-29, 202.27.204.0/24^24-29, 202.89.32.0/19^19-29, 202.6.5.0/24^24-29, 202.49.141.0/24^24-29, 203.89.160.0/19^19-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: david.fox(a)maxnet.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050314 source: NZRR

1 0

Notification of NZRR Database changes
by NZRR Database Notifications 13 Mar '05

13 Mar '05

Dear Colleague, This is to notify you that some object(s) in NZRR database which you either maintain or are listed as to-be-notified have been added, deleted or changed. These objects are used to configure the various NZIX route servers (http://nzix.net/) so you can expect the relevant servers to be reloaded in the near future. The reloading of the servers is staggered over a period of time so that if you are peering with both servers at an exchange, you can maintain at least one BGP session at all times and consequently a full set of routes. The update causing these changes had the following mail headers: - From: Andy Linton <asjl(a)citylink.co.nz> - Cc: - Subject: RE: [CityLink #2072] AutoReply: Routing updates for APE Route Servers (fwd) - Date: Mon, 14 Mar 2005 13:20:22 +1300 (NZDT) - Msg-Id: <Pine.LNX.4.58.0503141320030.12596(a)jennings.citylink.co.nz> NZRR Database Notification Department --- PREVIOUS OBJECT: route-set: AS9560:RS-ROUTES:AS17474 descr: Route set advertised to AS9560 by ConceptNET - AS17474 members: 202.49.250.0/24, 202.50.176.0/24, 202.127.8.0/22, 202.150.96.0/20, 203.97.44.0/24, 203.21.31.0/24 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: craig(a)concept.net.nz notify: nznog(a)list.waikato.ac.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20040304 changed: rpsl-admin(a)nzix.net 20040325 changed: rpsl-admin(a)nzix.net 20040617 changed: rpsl-admin(a)nzix.net 20040625 changed: rpsl-admin(a)nzix.net 20040813 source: NZRR REPLACED BY: route-set: AS9560:RS-ROUTES:AS17474 descr: advertised to AS9560 by Craig Spiers - AS17474 members: 202.150.96.0/20^20-29, 202.127.8.0/22^22-29, 203.97.44.0/24^24-29, 202.50.176.0/24^24-29, 202.7.6.32/29, 202.7.5.32/29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: craig(a)concept.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050314 source: NZRR --- PREVIOUS OBJECT: route: 202.150.96.0/20 descr: Route for ConceptNET - AS17474 origin: AS17474 notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: craig(a)concept.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20040908 source: NZRR REPLACED BY: route: 202.150.96.0/20 descr: Route for Craig Spiers - AS17474 origin: AS17474 notify: rpsl-admin(a)nzix.net notify: craig(a)concept.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050314 source: NZRR --- PREVIOUS OBJECT: route: 202.127.8.0/22 descr: Route for ConceptNET - AS17474 origin: AS17474 notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: craig(a)concept.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20040908 source: NZRR REPLACED BY: route: 202.127.8.0/22 descr: Route for Craig Spiers - AS17474 origin: AS17474 notify: rpsl-admin(a)nzix.net notify: craig(a)concept.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050314 source: NZRR --- PREVIOUS OBJECT: route: 203.97.44.0/24 descr: Route for ConceptNET - AS17474 origin: AS17474 notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: craig(a)concept.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20040908 source: NZRR REPLACED BY: route: 203.97.44.0/24 descr: Route for Craig Spiers - AS17474 origin: AS17474 notify: rpsl-admin(a)nzix.net notify: craig(a)concept.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050314 source: NZRR --- PREVIOUS OBJECT: route: 202.50.176.0/24 descr: Route for ConceptNET - AS17474 origin: AS17474 notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: craig(a)concept.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20040908 source: NZRR REPLACED BY: route: 202.50.176.0/24 descr: Route for Craig Spiers - AS17474 origin: AS17474 notify: rpsl-admin(a)nzix.net notify: craig(a)concept.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050314 source: NZRR

1 0

Cisco 2948G-L3...... I wonder if I could trouble someone out there.........
by Joe Gilliam 11 Mar '05

11 Mar '05

Well, I need some help. I found your list by googling and what I saw seemed to be pretty good. First of all, I am not a Cisco person. I don't know enough to do what I really want to do with this switch. My side of the world is the Administration of a large PACS System. I am not a part of the Network admin. Just the Apps side. But I am an MCSE and I can usually get myself out of trouble. UNTIL I GOT THIS DARN SWITCH....... I know enough to get in the switch, log in as the exec from the console and maybe change a few things here and there. I know this is an older CatOS type switch. But, I don't know many of the serious commands. OK, All I want is to change the setup so this switch will be a basic Layer 2 switch with all ports active, set to 10/100 Auto. And I want to configure an uplink port. And I want to turn on and off DHCP, like a light switch. I want to use this little jewel for lan parties. (FOR FUN, NOT FOR WORK!) Does someone out there have a place where I can get example configs, or even a manual so I can learn the CatOs or maybe even give me some pointers of how to configure the thing? This is the first time I have posted here, and haven't seen any traffic from the site. I just subscribed. So if this request is something you guys don't like to see, I won't bug you again. I am just looking for a little guidence. I can't seem to find anyone around here in Kansas that admits to knowing anything about this switch. Thanks in advance......... Joe Gilliam Wichita, Kansas

2 1

Re: [offlist] Re: [nznog] Ispmap / wix / ape - Slightly OT
by neil gardner 10 Mar '05

10 Mar '05

>>>> Jeremy Brooking <godfather(a)mafia.org.nz> 11/03/2005 10:44:58 a.m. >>Mark Foster wrote: >> Any ISPs who have run semi-transparent caching like to stick up their >> hands as to the sheer _volume_ of logging data collected relative to their >> customer base? And indicate exactly how long they archive those logs for, >> and how accessible they are??? > >Lots. > >No long. Ah, this is obviously some strange use of the word exactly that I wasn't previously aware of. (Apologies to Arthur Dent) Cheers - N. NOTICE: This message contains privileged and confidential information intended only for the use of the addressee named above. If you are not the intended recipient of this message you are hereby notified that you must not disseminate, copy or take any action in reliance on it. If you have received this message in error please notify Allied Telesyn Research Ltd immediately. Any views expressed in this message are those of the individual sender, except where the sender has the authority to issue and specifically states them to be the views of Allied Telesyn Research.

1 0

Re: [offlist] Re: [nznog] Ispmap / wix / ape - Slightly OT
by Mark Foster 10 Mar '05

10 Mar '05

On Wed, 9 Mar 2005 11:34:09 +1300 (NZDT), "Alastair Johnson" <aj(a)sneep.net> wrote : > Nathan Ward wrote: > > > Simon Lyall wrote: > > >>It breaks a few places that use the IP address to auth http sessions, > >>apparently some sites don't believe these weird cookie thingies are ready > >>for prime time. > >> > >> > > Hmm. This would be a problem if your requests for the same site were > > going to different proxy servers. > > I don't think that happens with Foundys, by default. If it does, it's > > easily 'fix'-able. > > We had an issue at Maxnet that was a site which broke in this manner. > Essentially they 'authenticated' the customer off the IP address of the > proxy, which using WCCP was reasonably static unless a proxy failed. > However, after the initial authentication, it then redirected them to an > SSL site on 443/tcp, which obviously was not going through the transparent > cache farm, and the customer was (correctly) not configured to use a > cache. > > So the request suddenly came from the customer's IP address. Result: The > site would refuse to allow them in. > > A stupid way of doing it, and we solved the problem by excluding the site > from the cache. For the life of me, I can't remember what it was, but I > recall the site was black and popular. I think it might have been some > games thing. > The other negative of Non-Transparent-Proxying that this brings to mind is the relative difficulty that ISPs have identifying persons who abuse web based services (websites, forums, et al) - The logs which collect 'cache?.xyz.co.nz' aren't exactly going to give the ISP information used to resolve user accounts and specific individuals. And most ISPs with the above issue don't log their proxies either, or if they do, can only log for a short period of time due to the sheer volume of log data created. So TransProxying, or none at all, would be my personal choice. (I hear that in at least one cases the amount of $ saved by transproxying was being re-spent in maintaining the boxes themselves - so they were pulled out due to lack of value vs inconvenience. And theyre now saving money.) Mark. All IMHO, as usual.

4 6

Re: [offlist] Re: [nznog] Ispmap / wix / ape - Slightly OT
by Nathan Ward 08 Mar '05

08 Mar '05

David Robb wrote: > On Wed, 9 Mar 2005, Nathan Ward wrote: > >> IMO, using cache's in fully transparent mode is a rather broken thing >> to do, unless you cache on your entire border.. > > Ever tried to architect a network to do that? :) > We tried. It's easier to deal with the occasional network that breaks. Really? I imagine that there would be lots of breakage in this area, especially during failures (your's, or other's) or routing that lacks clue. When you are caching fully transparently, do the Foundry's only send the HTTP return packets to the caches if they are part of a cached session? That would limit some problems, but obviously not all, and wouldn't fix this one. How do you detect that there is a problem network? That relies on customers, right? Do they really call and complain enough? I know my Mother would just put any failures like that down to "The Internet is broken again". Why don't you cache semi-transparently? (IE, connections to web servers come from the external IP address of the proxy server). I'm not aware of any real life cases of that breaking things, and as far as I am aware, it's what most NZ providers do.. Feel free to prove me wrong here, of course. -- Nathan Ward

4 4

A good reliable local NTP server to use?
by Simon Buchanan 08 Mar '05

08 Mar '05

Can anyone let me know of a good reliable local(NZ) NTP server to use? We are connected to APE... Thanks Simon -- Operations Manager - Networker. Creative Broadband Services. Web: www.networker.co.nz Eml: simon(a)networker.co.nz Tel: +64-21-348884

2 1

Ispmap / wix / ape - Slightly OT
by Barry Murphy 08 Mar '05

08 Mar '05

Hey guys, I've added some extra details (AS, APE, WIX) to ispmap on page: http://www.ispmap.co.nz/searchisp.php . I was going to gather the data off www.ape.net.nz and www.wix.net.nz however through Telstra Clear I cannot load these sites as they go international. So I ask if people can submit their ISP (if you peer at WIX / APE). ISPNAME: WIX: Yes/No APE: Yes/No If you work for the provider: YES/NO Thanks Barry

4 4

Telecom ADSL Testing equipment
by neil gardner 07 Mar '05

07 Mar '05

Hi there - if there's anyone on this list that can perform ADSL line testing at a pretty low level, please urgently get in touch with me via email. I am looking to monitor _exactly_ what is going on between our wall jack and the DSLAM. I have tried channels and not gotten very far. This is to troubleshoot an issue (Line condition) which may be able to hang a certain DSL chipset. Thanks - Neil Gardner Senior Tester Allied Telesyn Research NOTICE: This message contains privileged and confidential information intended only for the use of the addressee named above. If you are not the intended recipient of this message you are hereby notified that you must not disseminate, copy or take any action in reliance on it. If you have received this message in error please notify Allied Telesyn Research Ltd immediately. Any views expressed in this message are those of the individual sender, except where the sender has the authority to issue and specifically states them to be the views of Allied Telesyn Research.

1 0

WorldxChange Prefix List Update
by Gordon Smith 07 Mar '05

07 Mar '05

Would all direct peers please update their prefix lists as follows: ip prefix-list wxnz-networks permit 202.182.192.0/19 le 24 ip prefix-list wxnz-networks permit 58.28.0.0/16 le 24 Added: ip prefix-list wxnz-networks permit 58.28.0.0/16 le 24 For those who are not direct peering and wish to, email peering(a)wxnz.net IPv6 national peering is also available Cheers, Gordon

1 0

DNS entries
by Webmaster 07 Mar '05

07 Mar '05

When a DNS transfer is made to a new host what is 'normal' practice among operators in regards to the old record? Do you delete it immmediately, wait a specified time and then delete it, or wait to hear from the customer? Thanks. Richard

2 1

Notification of NZRR Database changes
by NZRR Database Notifications 06 Mar '05

06 Mar '05

Dear Colleague, This is to notify you that some object(s) in NZRR database which you either maintain or are listed as to-be-notified have been added, deleted or changed. These objects are used to configure the various NZIX route servers (http://nzix.net/) so you can expect the relevant servers to be reloaded in the near future. The reloading of the servers is staggered over a period of time so that if you are peering with both servers at an exchange, you can maintain at least one BGP session at all times and consequently a full set of routes. The update causing these changes had the following mail headers: - From: Andy Linton <asjl(a)citylink.co.nz> - Cc: - Subject: Notification of NZRR Database changes (fwd) - Date: Mon, 7 Mar 2005 14:29:34 +1300 (NZDT) - Msg-Id: <Pine.LNX.4.58.0503071427520.4454(a)jennings.citylink.co.nz> NZRR Database Notification Department --- PREVIOUS OBJECT: aut-num: AS17705 as-name: NZRR-AS17705 descr: Inspire Net descr: WIX peering at '202.7.0.123' descr: see Citylink RT job #2009 admin-c: RPA1-NZRR tech-c: RPA1-NZRR import: from AS9439 accept ANY AND NOT fltr-bogons export: to AS9439 announce AS17705 notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: noc(a)inspire.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050307 source: NZRR REPLACED BY: aut-num: AS17705 as-name: NZRR-AS17705 descr: Inspire Net descr: WIX peering at '202.7.0.123' descr: see Citylink RT job #2009 descr: PNIX peering at '218.100.21.10' descr: see Citylink RT job #1487 descr: APE peering at '192.203.154.17' descr: see Citylink RT job #1552 admin-c: RPA1-NZRR tech-c: RPA1-NZRR import: from AS9439 accept ANY AND NOT fltr-bogons export: to AS9439 announce AS17705 import: from AS9560 accept ANY AND NOT fltr-bogons export: to AS9560 announce AS17705 import: from AS9281 accept ANY AND NOT fltr-bogons export: to AS9281 announce AS17705 notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: noc(a)inspire.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050307 source: NZRR

1 0

Notification of NZRR Database changes
by NZRR Database Notifications 06 Mar '05

06 Mar '05

Dear Colleague, This is to notify you that some object(s) in NZRR database which you either maintain or are listed as to-be-notified have been added, deleted or changed. These objects are used to configure the various NZIX route servers (http://nzix.net/) so you can expect the relevant servers to be reloaded in the near future. The reloading of the servers is staggered over a period of time so that if you are peering with both servers at an exchange, you can maintain at least one BGP session at all times and consequently a full set of routes. --- PREVIOUS OBJECT: aut-num: AS17705 as-name: NZRR-AS17705 descr: Inspire Net descr: PNIX peering at '218.100.21.10' descr: see Citylink RT job #1487 descr: APE peering at '192.203.154.17' descr: see Citylink RT job #1552 admin-c: RPA1-NZRR tech-c: RPA1-NZRR import: from AS9560 accept ANY AND NOT fltr-bogons export: to AS9560 announce AS17705 import: from AS9281 accept ANY AND NOT fltr-bogons export: to AS9281 announce AS17705 notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: noc(a)inspire.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20041126 source: NZRR REPLACED BY: aut-num: AS17705 as-name: NZRR-AS17705 descr: Inspire Net descr: WIX peering at '202.7.0.123' descr: see Citylink RT job #2009 admin-c: RPA1-NZRR tech-c: RPA1-NZRR import: from AS9439 accept ANY AND NOT fltr-bogons export: to AS9439 announce AS17705 notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: noc(a)inspire.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050307 source: NZRR --- PREVIOUS OBJECT: route: 203.96.157.0/24 descr: Route for Inspire Net - AS17705 origin: AS17705 notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: noc(a)inspire.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20041126 source: NZRR REPLACED BY: route: 203.96.157.0/24 descr: Route for Inspire Net - AS17705 origin: AS17705 notify: rpsl-admin(a)nzix.net notify: noc(a)inspire.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050307 source: NZRR --- OBJECT BELOW CREATED: route-set: AS9439:RS-ROUTES:AS17705 descr: Route set advertised to AS9439 by Inspire Net - AS17705 members: 203.79.88.0/24^24-29, 203.79.89.0/24^24-29, 203.96.157.0/24^24-29, 203.114.128.0/18^18-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)inspire.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050307 source: NZRR

1 0

Notification of NZRR Database changes
by NZRR Database Notifications 06 Mar '05

06 Mar '05

Dear Colleague, This is to notify you that some object(s) in NZRR database which you either maintain or are listed as to-be-notified have been added, deleted or changed. These objects are used to configure the various NZIX route servers (http://nzix.net/) so you can expect the relevant servers to be reloaded in the near future. The reloading of the servers is staggered over a period of time so that if you are peering with both servers at an exchange, you can maintain at least one BGP session at all times and consequently a full set of routes. The update causing these changes had the following mail headers: - From: Andy Linton <asjl(a)citylink.co.nz> - Cc: - Subject: RE: [CityLink #2003] AutoReply: Routing updates for APE Route Servers (fwd) - Date: Mon, 7 Mar 2005 11:42:37 +1300 (NZDT) - Msg-Id: <Pine.LNX.4.58.0503071141330.4454(a)jennings.citylink.co.nz> NZRR Database Notification Department --- PREVIOUS OBJECT: route-set: AS9560:RS-ROUTES:AS9889 descr: advertised to AS9560 by Maxnet - AS9889 members: 210.55.230.0/24^24-29, 210.55.214.0/24^24-29, 210.55.169.0/24^24-29, 210.55.155.0/24^24-29, 210.55.104.0/22^22-29, 210.55.100.0/22^22-29, 202.37.181.0/24^24-29, 202.37.72.0/24^24-29, 202.36.70.0/24^24-29, 202.27.204.0/24^24-29, 202.89.32.0/19^19-29, 202.6.5.0/24^24-29, 202.49.141.0/24^24-29, 203.89.160.0/19^19-29, 202.7.5.32/29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: david.fox(a)maxnet.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050302 source: NZRR REPLACED BY: route-set: AS9560:RS-ROUTES:AS9889 descr: advertised to AS9560 by Maxnet - AS9889 members: 210.55.230.0/24^24-29, 210.55.214.0/24^24-29, 210.55.169.0/24^24-29, 210.55.155.0/24^24-29, 210.55.104.0/22^22-29, 210.55.100.0/22^22-29, 202.37.181.0/24^24-29, 202.37.72.0/24^24-29, 202.36.70.0/24^24-29, 202.27.204.0/24^24-29, 202.89.32.0/19^19-29, 202.6.5.0/24^24-29, 202.49.141.0/24^24-29, 203.89.160.0/19^19-29, 202.7.5.32/29, 202.7.6.32/29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: david.fox(a)maxnet.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050307 source: NZRR

1 0

telstra clear
by Garrett Stoupe 06 Mar '05

06 Mar '05

Has anyone experienced network / internet related problems since Telstra clear de peered itself from wix? We are using a woosh wireless business connection, and we are experiencing some slowness, even with google. The problems started happening when Telstra clear de peered from wix It would be interesting to see if anyone else is experiencing any problems Garrett Stoupe Network And Database Administrator Cabbage Tree Press garretts(a)te.co.nz www.te.co.nz www.jobzone.co.nz www.nzcarbuys.co.nz

2 2

OT: Seeking a Book
by Anaru Hartley 05 Mar '05

05 Mar '05

Hello All, I have been looking for a way to progress my career in the Telecommunications Industry and a good friend of mine suggested that I read this particular book. I was hoping one of you individuals would be able to put me in the direction of one or might be able to lend me a copy of it. Here is a picture of the books cover: http://www50.brinkster.com/photochopnz/top.jpg Thanks in advance!

2 2

Cisco 2600 LNS help.
by Neil Fincham 05 Mar '05

05 Mar '05

Hi all, On of my clients has had a bit of a disaster and lost their config for a Cosco 2600 that they were using as an LNS for telstraclear's network, I have put the basic information back in (IP, Routes etc) but my cisco speek for LNS and Radius is non existant. Could someone cut and paste the relevent bits out of one of their routers (minus passwords and such) and send it to me. As you can imagine this is quite urgent and help would be greatly appreiciated, this is what I have at the moment;- L2TP#write terminal Building configuration... Current configuration : 1642 bytes ! version 12.3 service timestamps debug uptime service timestamps log uptime service password-encryption ! hostname L2TP ! boot-start-marker boot-end-marker ! ! voice-card 0 dspfarm no local-bypass ! aaa new-model ! ! aaa authentication login default local aaa authentication ppp default local aaa authentication ppp vpdn group radius aaa authorization network default group radius aaa accounting network default start-stop group radius aaa session-id common ip subnet-zero ! ! ! ! ip name-server 203.97.37.1 vpdn enable ! vpdn-group 1 accept-dialin protocol l2tp virtual-template 1 terminate-from hostname sp_lac ! no ftp-server write-enable ! ! ! ! ! ! ! ! ! ! ! ! syscon password XXX syscon community XXX ! ! controller E1 0/1 ! ! ! interface FastEthernet0/0 ip address XXX.XXX.XXX.XXX 255.255.255.248 speed auto half-duplex no mop enabled ! interface Serial0/0 no ip address shutdown ! interface FastEthernet0/1 description connected to EthernetLAN ip address XXX.XXX.XXX.XXX 255.255.255.248 duplex auto speed auto ! interface Virtual-Template1 ip unnumbered FastEthernet0/1 peer default ip address pool default ppp authentication chap vpdn ppp multilink ! ip classless ip route 0.0.0.0 0.0.0.0 XXX.XXX.XXX.XXX permanent ip route 203.98.24.0 255.255.255.0 XXX.XXX.XXX.XXX permanent ip route 203.98.25.0 255.255.255.0 XXX.XXX.XXX.XXX permanent no ip http server ! ! snmp-server community public RO snmp-server enable traps tty snmp-server manager ! radius-server host XXX.XXX.XXX.XXX auth-port 1812 acct-port 1813 radius-server key XXXXXXXXXX ! control-plane ! ! ! ! ! ! ! ! line con 0 line aux 0 line vty 0 4 ! ! ! end Thanks for any help. No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.308 / Virus Database: 266.6.2 - Release Date: 4/03/2005

1 0

Notification of NZRR Database changes
by NZRR Database Notifications 03 Mar '05

03 Mar '05

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

1 0

tradme etc
by Simon Lyall 03 Mar '05

03 Mar '05

Interestign wee article: http://www.nzherald.co.nz/index.cfm?c_id=5&ObjectID=10113474 Somebody might know this fior sure but doesn't AT&T (trademe's upstream) connect to APE? Just I can't see trademe's routes being advertised there. -- Simon J. Lyall. | Very Busy | Mail: simon(a)darkmere.gen.nz "To stay awake all night adds a day to your life" - Stilgar | eMT.

7 6

How fair practice is this; is it spam? - Orcon Response
by Craig Whitmore 03 Mar '05

03 Mar '05

This has been posted on Behalf of Orcon MD by Craig Whitmore --- There appears to have been a serious mis-understanding between Barry and Orcon on this matter Orcon has NOT spammed Barry's customers, and Barry's post is very mis-leading. I will clarify Orcon's position, and lay out the facts, and then I suggest that Barry and Orcon take this matter offline as it is not something that needs to be discussed in NZNOG. Orcon has not, and never will: a) Spam potential customers seeking to provide them services b) Poach customers deliberately from wholesale customers, as a significant portion of our revenue comes from wholesale. What has happened is that our marketing department has been in MUTUAL contact with the owner of a single website, and came to an arrangement whereby we would receive free advertising on the person's website in return for providing free web-hosting and domain name registration. Our marketing department was not aware that this website owner was actually a customer of a customer of Barry's. The website owner has contacted their provider (a customer of a Barry's), and told them that they were moving to us, and the provider and Barry have come to the knee-jerk reaction that we are trying to poach customers. This is absolutely NOT the case. Once Barry made us aware of the issue, Barry's account manager tried to point out that end users are free to choose whichever web hosting provider they want, and that sometimes we lose customers to our wholesale hosting customers and vice-versa - this does NOT mean we are poaching customers or spamming people. However, our account manager communicated this to Barry in a less than elegant manner, and via email, after I had specifically asked that Barry be called so that the situation could be discussed and explained rationally. It is NOT our desire that Barry be upset, This is a SINGLE website owner who had prior discussions with our marketing department, and this conflict has only just been brought to our attention. Thanks for reading NZNOGer's - thanks for your time. Regards Seeby Woodhouse MD Orcon Internet -----Original Message----- From: Barry Murphy [mailto:barry(a)unix.co.nz] Sent: Friday, March 04, 2005 2:23 PM To: nznog(a)list.waikato.ac.nz Subject: [nznog] How fair practice is this; is it spam? ok.... how fair is this... I purchase telehousing from orcon and register domains through them. They have spammed one of my customers offering to host their website free of charge in return for advertising space on their website. After hearing this I emailed my account manager at orcon and this was his response. "As Im sure you are aware, Orcon also runs hosting, and as such, from a marketing perspective we have to treat other web hosting companies as competition, even if they are buying wholesale services from us. All other ISP's do the same - Telecom actively market to our customers for all ISP services even though we purchase a massive amount of wholesale services off them. " Is this spam/fair practice? Seeing as they could obtain a list of these domains in their database (as they're the registrar for this domain) Kindest Regards Barry Murphy _______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog

2 1

problems with NTP on bigben?
by Simon Blake 03 Mar '05

03 Mar '05

Anybody else observed that bigben gained about 19 years at about 1:25pm this arvo? $ date Tue Jan 1 14:54:33 NZDT 2002 $ /usr/sbin/ntpdate -q truechimer.waikato.ac.nz server 130.217.76.32, stratum 2, offset -0.001089, delay 0.04276 1 Jan 14:49:38 ntpdate[17537]: adjust time server 130.217.76.32 offset -0.001089 sec $ /usr/sbin/ntpdate -q bigben.clix.net.nz server 203.167.224.60, stratum 1, offset 619315199.998172, delay 0.03613 1 Jan 14:49:55 ntpdate[17540]: step time server 203.167.224.60 offset 619315199.998172 sec - To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog

13 20

How fair practice is this; is it spam?
by Barry Murphy 03 Mar '05

03 Mar '05

ok.... how fair is this... I purchase telehousing from orcon and register domains through them. They have spammed one of my customers offering to host their website free of charge in return for advertising space on their website. After hearing this I emailed my account manager at orcon and this was his response. "As Im sure you are aware, Orcon also runs hosting, and as such, from a marketing perspective we have to treat other web hosting companies as competition, even if they are buying wholesale services from us. All other ISP's do the same - Telecom actively market to our customers for all ISP services even though we purchase a massive amount of wholesale services off them. " Is this spam/fair practice? Seeing as they could obtain a list of these domains in their database (as they're the registrar for this domain) Kindest Regards Barry Murphy

3 2

Notification of NZRR Database changes
by NZRR Database Notifications 03 Mar '05

03 Mar '05

Dear Colleague, This is to notify you that some object(s) in NZRR database which you either maintain or are listed as to-be-notified have been added, deleted or changed. These objects are used to configure the various NZIX route servers (http://nzix.net/) so you can expect the relevant servers to be reloaded in the near future. The reloading of the servers is staggered over a period of time so that if you are peering with both servers at an exchange, you can maintain at least one BGP session at all times and consequently a full set of routes. The update causing these changes had the following mail headers: - From: Andy Linton <asjl(a)citylink.co.nz> - Cc: - Subject: [CityLink #1987] Routing updates for APE Route Servers (fwd) - Date: Fri, 4 Mar 2005 13:10:15 +1300 (NZDT) - Msg-Id: <Pine.LNX.4.58.0503041309040.991(a)jennings.citylink.co.nz> NZRR Database Notification Department --- PREVIOUS OBJECT: route-set: AS9439:RS-ROUTES:AS4770 descr: advertised to AS9439 by ICONZ - AS4770 members: 138.235.0.0/16^16-29, 192.107.113.0/24^24-29, 192.173.16.0/21^21-29, 198.32.66.0/24^24-29, 199.212.90.0/23^23-29, 199.212.92.0/23^23-29, 202.6.84.0/24^24-29, 202.12.70.0/24^24-29, 202.12.248.0/21^21-29, 202.14.100.0/24^24-29, 202.21.130.0/24^24-29, 202.21.136.0/23^23-29, 202.36.155.0/24^24-29, 202.36.157.0/24^24-29, 202.36.32.0/24^24-29, 202.36.36.0/22^22-29, 202.36.44.0/24^24-29, 202.36.45.0/24^24-29, 202.36.76.0/23^23-29, 202.37.136.0/24^24-29, 202.37.140.0/22^22-29, 202.37.144.0/21^21-29, 202.37.163.0/24^24-29, 202.37.197.0/24^24-29, 202.37.200.0/22^22-29, 202.37.224.0/21^21-29, 202.37.232.0/24^24-29, 202.37.240.0/23^23-29, 202.37.252.0/23^23-29, 202.37.76.0/24^24-29, 202.37.85.0/24^24-29, 202.41.136.0/22^22-29, 202.41.140.0/24^24-29, 202.49.62.0/24^24-29, 202.49.89.0/24^24-29, 202.49.249.0/24^24-29, 202.50.87.0/24^24-29, 202.50.246.0/24^24-29, 202.55.96.0/20^20-29, 202.74.224.0/21^21-29, 202.182.192.0/19^19-29, 205.233.128.0/21^21-29, 205.233.136.0/23^23-29, 205.233.243.0/24^24-29, 210.185.0.0/18^18-29, 210.48.0.0/17^17-29, 210.54.136.0/22^22-29, 210.54.140.0/24^24-29, 210.54.160.0/19^19-29, 210.55.182.0/23^23-29, 210.55.24.0/22^22-29, 210.55.253.0/24^24-29, 210.56.32.0/20^20-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: john(a)iconz.net mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050225 source: NZRR REPLACED BY: route-set: AS9439:RS-ROUTES:AS4770 descr: advertised to AS9439 by ICONZ - AS4770 members: 138.235.0.0/16^16-29, 192.107.113.0/24^24-29, 192.173.16.0/21^21-29, 198.32.66.0/24^24-29, 199.212.93.0/24^24-29, 202.6.84.0/24^24-29, 202.12.70.0/24^24-29, 202.12.248.0/21^21-29, 202.14.100.0/24^24-29, 202.20.6.0/24^24-29, 202.21.130.0/24^24-29, 202.21.136.0/23^23-29, 202.36.155.0/24^24-29, 202.36.157.0/24^24-29, 202.36.32.0/24^24-29, 202.36.36.0/22^22-29, 202.36.44.0/24^24-29, 202.36.45.0/24^24-29, 202.36.76.0/23^23-29, 202.36.119.0/24^24-29, 202.37.136.0/24^24-29, 202.37.140.0/22^22-29, 202.37.144.0/21^21-29, 202.37.163.0/24^24-29, 202.37.197.0/24^24-29, 202.37.200.0/22^22-29, 202.37.224.0/21^21-29, 202.37.232.0/24^24-29, 202.37.240.0/23^23-29, 202.37.252.0/23^23-29, 202.37.76.0/24^24-29, 202.37.85.0/24^24-29, 202.41.136.0/22^22-29, 202.41.140.0/24^24-29, 202.46.190.0/24^24-29, 202.49.62.0/24^24-29, 202.49.89.0/24^24-29, 202.49.249.0/24^24-29, 202.49.159.0/24^24-29, 202.50.87.0/24^24-29, 202.50.246.0/24^24-29, 202.55.96.0/20^20-29, 202.74.224.0/21^21-29, 202.78.240.0/23^23-29, 202.182.192.0/19^19-29, 205.233.128.0/21^21-29, 205.233.136.0/23^23-29, 205.233.243.0/24^24-29, 210.185.0.0/18^18-29, 210.48.0.0/17^17-29, 210.54.136.0/22^22-29, 210.54.140.0/24^24-29, 210.54.160.0/19^19-29, 210.55.182.0/23^23-29, 210.55.24.0/22^22-29, 210.55.253.0/24^24-29, 210.56.32.0/20^20-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: john(a)iconz.net mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050304 source: NZRR --- PREVIOUS OBJECT: route-set: AS9560:RS-ROUTES:AS4770 descr: advertised to AS9560 by ICONZ - AS4770 members: 138.235.0.0/16^16-29, 192.107.113.0/24^24-29, 192.173.16.0/21^21-29, 198.32.66.0/24^24-29, 199.212.90.0/23^23-29, 199.212.92.0/23^23-29, 202.6.84.0/24^24-29, 202.12.70.0/24^24-29, 202.12.248.0/21^21-29, 202.14.100.0/24^24-29, 202.21.130.0/24^24-29, 202.21.136.0/23^23-29, 202.36.155.0/24^24-29, 202.36.157.0/24^24-29, 202.36.32.0/24^24-29, 202.36.36.0/22^22-29, 202.36.44.0/24^24-29, 202.36.45.0/24^24-29, 202.36.76.0/23^23-29, 202.37.136.0/24^24-29, 202.37.140.0/22^22-29, 202.37.144.0/21^21-29, 202.37.163.0/24^24-29, 202.37.197.0/24^24-29, 202.37.200.0/22^22-29, 202.37.224.0/21^21-29, 202.37.232.0/24^24-29, 202.37.240.0/23^23-29, 202.37.252.0/23^23-29, 202.37.76.0/24^24-29, 202.37.85.0/24^24-29, 202.41.136.0/22^22-29, 202.41.140.0/24^24-29, 202.49.62.0/24^24-29, 202.49.89.0/24^24-29, 202.49.249.0/24^24-29, 202.50.87.0/24^24-29, 202.50.246.0/24^24-29, 202.55.96.0/20^20-29, 202.74.224.0/21^21-29, 202.182.192.0/19^19-29, 205.233.128.0/21^21-29, 205.233.136.0/23^23-29, 205.233.243.0/24^24-29, 210.185.0.0/18^18-29, 210.48.0.0/17^17-29, 210.54.136.0/22^22-29, 210.54.140.0/24^24-29, 210.54.160.0/19^19-29, 210.55.182.0/23^23-29, 210.55.24.0/22^22-29, 210.55.253.0/24^24-29, 210.56.32.0/20^20-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: john(a)iconz.net mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050225 source: NZRR REPLACED BY: route-set: AS9560:RS-ROUTES:AS4770 descr: advertised to AS9560 by ICONZ - AS4770 members: 138.235.0.0/16^16-29, 192.107.113.0/24^24-29, 192.173.16.0/21^21-29, 198.32.66.0/24^24-29, 199.212.93.0/24^24-29, 202.6.84.0/24^24-29, 202.12.70.0/24^24-29, 202.12.248.0/21^21-29, 202.14.100.0/24^24-29, 202.20.6.0/24^24-29, 202.21.130.0/24^24-29, 202.21.136.0/23^23-29, 202.36.155.0/24^24-29, 202.36.157.0/24^24-29, 202.36.32.0/24^24-29, 202.36.36.0/22^22-29, 202.36.44.0/24^24-29, 202.36.45.0/24^24-29, 202.36.76.0/23^23-29, 202.36.119.0/24^24-29, 202.37.136.0/24^24-29, 202.37.140.0/22^22-29, 202.37.144.0/21^21-29, 202.37.163.0/24^24-29, 202.37.197.0/24^24-29, 202.37.200.0/22^22-29, 202.37.224.0/21^21-29, 202.37.232.0/24^24-29, 202.37.240.0/23^23-29, 202.37.252.0/23^23-29, 202.37.76.0/24^24-29, 202.37.85.0/24^24-29, 202.41.136.0/22^22-29, 202.41.140.0/24^24-29, 202.46.190.0/24^24-29, 202.49.62.0/24^24-29, 202.49.89.0/24^24-29, 202.49.249.0/24^24-29, 202.49.159.0/24^24-29, 202.50.87.0/24^24-29, 202.50.246.0/24^24-29, 202.55.96.0/20^20-29, 202.74.224.0/21^21-29, 202.78.240.0/23^23-29, 202.182.192.0/19^19-29, 205.233.128.0/21^21-29, 205.233.136.0/23^23-29, 205.233.243.0/24^24-29, 210.185.0.0/18^18-29, 210.48.0.0/17^17-29, 210.54.136.0/22^22-29, 210.54.140.0/24^24-29, 210.54.160.0/19^19-29, 210.55.182.0/23^23-29, 210.55.24.0/22^22-29, 210.55.253.0/24^24-29, 210.56.32.0/20^20-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: john(a)iconz.net mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050304 source: NZRR

1 0

The Impact of the Reworked TTL Field on Regional IP Allocations
by Jim Fleming 02 Mar '05

02 Mar '05

The Impact of the Reworked TTL Field on Regional IP Allocations The TTL Field (or Hop Count) is normally 8-bits wide. Some operating systems start it with a value of 255 (all 1s) and some with 64 and other smaller values. In order to improve services for broad-band users, there is a benefit in **reducing** the size of the TTL Field from 8-bits to 4-bits. That limits the maximum number of hops to 15. Equipment that auto-encapsulates can work around this by moving a packet a long distance and then removing a wrapper and allowing it to have some of the hops near the source and some near the destination. Reducing the TTL Field to 4-bits frees up 4-bits for address expansion. With two of those bits for the Source and two bits for the Destination, the entire legacy Internet plus three more equal size address spaces can be supported, without changing the existing protocol header size. One could view that as a planar Internet or a 4-story office building. Existing allocations of address space could all be viewed as from one plane or one could map regions to the 4 planes, allowing a region to expand to space used by another region because the extra bits prevent collisions and provide unique allocations. Another approach is to use the 4 planes for local networks, VPNs, a wireless extranet, and the legacy Internet (core). In a restricted approach only intra-plane traffic is allowed. A totally open approach would allow any node to address any other node. This would be like any location in the 4-story office being able to connect with any other, rather then be restricted to intra-floor-only connections. A more conservative approach is simply to zero the left-most 4 bits and reserve (save) the other three planes for future generations, once equipment is better able to route and process the reworked TTL Field. Current market trials and tests with broad-band-only subscribers will help to determine which approach has the most benefit. IP address allocations are already being red-lined for re-allocation and use in other planar nets because they can not be reached in 15 hops from/to certain regions of the world. Since there may not be any bandwidth to those regions anyway, it does not matter because the laws of physics will prevent broadband services from becoming available in one region with the same level of service observed in another region. Voice services are of course "the killer apps" and place great demands on the aging best-effort transports. As new equipment is provisioned it can be done with an awareness of the benefits of using a smaller TTL Field. Some might argue that 15 hops is stilll too many and one or two more bits should be removed leaving a 7 hop or a 3 hop limit. The 7 hop approach only frees up 1 more bit and it can be combined with the unused 49th bit to add another entire bit to both the source and destination fields. The 3 hop approach makes one look sooner at the needed equipment to bypass the aging legacy core. Having 6 added bits for addressing and 8 planar levels can have more long-term benefits and there can still be a short-term work-around because the 3-bits of the destination address field can be allowed to be processed by *existing* TTL algorithms and packets then transform their addressing as they pass thru the core network. The address bits can then be used to prioritize delivery by allowing packets that come from a long distance to be processed before those that come from closer locations. They appear to be going to different destinations by looking at the changed TTL value as an address. Since packets now travel greater distances with less decrements of the hop-count the 7 hop approach may be the best compromise. Eventually, the free-market place will decide. People can not make "governance" decisions based on 20 year old designs and how they are applied in regions of the world that have no bandwidth. That is the lowest-common-denominator approach advocated by The Big Lie Society. As people have seen, that prevents a nation from Running at the speed of light. Jim Fleming A.Net

4 3

Read-Only BLOB (packet) Additions to the IP Protocol
by Jim Fleming 02 Mar '05

02 Mar '05

Read-Only BLOB (packet) Additions to the IP Protocol An analysis of many packets of data show that the same binary content appears over and over. This is especially the case when a smaller and smaller size BLOB is considered. For example, a 512 byte (octet) BLOB contains 4096 bits (ones or zeroes) and there can be a large number of **unique** BLOBs, in fact, approximately (1.0443888814131525066917527107166e+1233). If users are able to create (own?) any number of the unique BLOBs and then place them in a public cache (library), then new broadband modems can pull those BLOBs in and attach them to packet headers. Since the BLOBS are read-only and never change, once created, they can each have their own IP address as the "source". The destination address is the end-user's system. One obvious BLOB is a 512 byte BLOB of all zeroes. Another obvious one is all ones. Those can be two of the possible BLOBS. If a 32-bit index (handle) is used to specify a unique BLOB, then there can be exactly 4,294,967,296. It might take several BLOBS to hold commonly communicated binary content. Also, several BLOBS may be needed if graphics/voice/sound is recorded vs. text. Compression can be allowed because the BLOB is just 512 bytes of arbitrary ones and zeroes. Also, careful attention to repetition in tones (like dial-tone in VOIP) can result in the same BLOB being used over and over with no clicks or gaps noticed between BLOBs. With that as a bit of an intro, no pun intended, some "Internet Governance" questions come to mind. 1. Who owns the content of the BLOBs ? 2. If it costs $1 dollar (OZ dollars) to "register" a unique BLOB who collects that $4,294,967,296 ? 3. How and where will the BLOBs be cached ? 4. Do the users really care where they come from as long as their broad-band system works "better" ? 5. Are people concerned that the same BLOB may appear over and over, creating boring content ? 6. Are people concerned that a small error could become part of a read-only archive and live for a long time ? 7. As a follow-on to #6, would another BLOB be allowed ? to fix that error ? 8. Is first-come-first-serve the best way to sell off the BLOBs? 9. Should existing archives and databases be encoded first ? at no charge ? 10. Once one BLOB address space is used up, should another be opened up ? 11. Will there be vanity-value in owning a BLOB ? Is the one-millionth BLOB special ? 12. Will BLOBs that can be compressed be favored ? 13. Should there be an age-limit to register a BLOB ? For the curious, the entire BLOB cache would be 2,199,023,255,552 bytes without compression. An ISP can cache the entire BLOB space and do inserts in the last mile of the broad-band connection. The broad-band "modem" can of course cache a working set of the most common BLOBs. Is this bit torrent at the IP level ? http://bittorrent.com/ Jim Fleming A.Net

3 2

ICONZ Prefix list update - 2005-03-03
by John Johnston 02 Mar '05

02 Mar '05

AS: 4770 APE: 192.203.154.44 WIX: 202.7.1.1 Hey all, For all those that peer with ICONZ here is yet another update. Current list is attached or goto http://www.iconz.net/prefix Regards John Johnston Network Engineering Manager ICONZ New Zealand Limited DDI: +64 9 977 3500 FAX: +64 9 977 3535 Mobile: 021 277 5692 Email: john.johnston(a)iconz.net 0800 THE NET www.iconz.net

1 0

Notification of NZRR Database changes
by NZRR Database Notifications 02 Mar '05

02 Mar '05

Dear Colleague, This is to notify you that some object(s) in NZRR database which you either maintain or are listed as to-be-notified have been added, deleted or changed. These objects are used to configure the various NZIX route servers (http://nzix.net/) so you can expect the relevant servers to be reloaded in the near future. The reloading of the servers is staggered over a period of time so that if you are peering with both servers at an exchange, you can maintain at least one BGP session at all times and consequently a full set of routes. The update causing these changes had the following mail headers: - From: Andy Linton <asjl(a)citylink.co.nz> - Cc: - Subject: - Date: Thu, 3 Mar 2005 13:21:39 +1300 (NZDT) - Msg-Id: <Pine.LNX.4.58.0503031320190.31409(a)jennings.citylink.co.nz> NZRR Database Notification Department --- PREVIOUS OBJECT: route-set: AS9439:RS-ROUTES:AS2687 descr: Route set advertised to AS9439 by AT&T Global - AS2687 members: 152.158.254.0/24^24-29, 152.158.255.0/24^24-29, 202.14.142.0/24^24-29, 202.27.160.0/24^24-29, 202.36.68.0/24^24-29, 202.36.69.0/24^24-29, 202.36.80.0/24^24-29, 202.36.195.0/24^24-29, 202.37.93.0/24^24-29, 202.37.254.0/24^24-29, 202.46.160.0/20^20-29, 202.49.144.0/24^24-29, 202.50.137.0/24^24-29, 202.135.20.0/24^24-29, 202.135.34.0/24^24-29, 202.135.38.0/24^24-29, 202.135.48.0/24^24-29, 202.135.49.0/24^24-29, 202.135.62.0/24^24-29, 202.135.85.0/24^24-29, 202.135.107.0/24^24-29, 202.135.111.0/24^24-29, 202.135.112.0/24^24-29, 202.135.116.0/24^24-29, 202.135.142.0/24^24-29, 202.135.182.0/24^24-29, 202.135.185.0/24^24-29, 202.135.190.0/24^24-29, 202.135.192.0/24^24-29, 202.135.231.0/24^24-29, 203.163.68.0/24^24-29, 203.163.70.0/24^24-29, 203.163.71.0/24^24-29, 203.163.86.0/24^24-29, 203.163.94.0/24^24-29, 203.163.98.0/24^24-29, 203.196.119.0/24^24-29, 219.88.103.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: greg.kapp(a)ap.att.com mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050302 source: NZRR REPLACED BY: route-set: AS9439:RS-ROUTES:AS2687 descr: Route set advertised to AS9439 by AT&T Global - AS2687 members: 152.158.254.0/24^24-29, 152.158.255.0/24^24-29, 202.14.142.0/24^24-29, 202.27.160.0/24^24-29, 202.36.68.0/24^24-29, 202.36.69.0/24^24-29, 202.36.80.0/24^24-29, 202.36.195.0/24^24-29, 202.37.93.0/24^24-29, 202.37.254.0/24^24-29, 202.46.160.0/20^20-29, 202.49.144.0/24^24-29, 202.50.137.0/24^24-29, 202.135.20.0/24^24-29, 202.135.34.0/24^24-29, 202.135.38.0/24^24-29, 202.135.48.0/24^24-29, 202.135.49.0/24^24-29, 202.135.62.0/24^24-29, 202.135.85.0/24^24-29, 202.135.107.0/24^24-29, 202.135.111.0/24^24-29, 202.135.112.0/24^24-29, 202.135.116.0/24^24-29, 202.135.142.0/24^24-29, 202.135.182.0/24^24-29, 202.135.185.0/24^24-29, 202.135.190.0/24^24-29, 202.135.192.0/24^24-29, 202.135.231.0/24^24-29, 203.163.68.0/24^24-29, 203.163.70.0/24^24-29, 203.163.71.0/24^24-29, 203.163.86.0/24^24-29, 203.163.94.0/24^24-29, 203.163.98.0/24^24-29, 203.196.119.0/24^24-29, 219.88.103.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: attnzdns(a)ap.att.com mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050303 source: NZRR

1 0

RE: [nznog] VON anyone?
by Mark Frater 02 Mar '05

02 Mar '05

Ahh flames... Spin.. Crash.. Burn.. Die.. Before the flames grow higher, humble apologies for html.. etc. < does no sig on this one make up for it?> --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com) Version: 6.0.775 / Virus Database: 522 - Release Date: 8/10/2004

1 0

VON anyone?
by Mark Frater 02 Mar '05

02 Mar '05

1 0

Notification of NZRR Database changes
by NZRR Database Notifications 01 Mar '05

01 Mar '05

Dear Colleague, This is to notify you that some object(s) in NZRR database which you either maintain or are listed as to-be-notified have been added, deleted or changed. These objects are used to configure the various NZIX route servers (http://nzix.net/) so you can expect the relevant servers to be reloaded in the near future. The reloading of the servers is staggered over a period of time so that if you are peering with both servers at an exchange, you can maintain at least one BGP session at all times and consequently a full set of routes. The update causing these changes had the following mail headers: - From: Andy Linton <asjl(a)citylink.co.nz> - Cc: - Subject: RE: [CityLink #1983] AutoReply: Routing updates for APE Route Servers (fwd) - Date: Wed, 2 Mar 2005 20:02:24 +1300 (NZDT) - Msg-Id: <Pine.LNX.4.58.0503022001510.30819(a)jennings.citylink.co.nz> NZRR Database Notification Department --- PREVIOUS OBJECT: route-set: AS9560:rs-routes:AS9889 descr: Route set for AS9889 members: 202.14.217.0/24, 202.27.204.0/24, 202.36.70.0/24, 202.37.72.0/24, 202.37.181.0/24, 202.50.167.0/24, 202.89.32.0/19^19-24, 210.55.29.0/24, 210.55.100.0/22^22-24, 210.55.104.0/22^22-24, 210.55.110.0/24, 210.55.155.0/24, 210.55.169.0/24, 210.55.214.0/24, 210.55.230.0/24 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: alastair.johnson(a)maxnet.co.nz notify: nznog(a)list.waikato.ac.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20031016 changed: rpsl-admin(a)nzix.net 20041008 source: NZRR REPLACED BY: route-set: AS9560:RS-ROUTES:AS9889 descr: advertised to AS9560 by Maxnet - AS9889 members: 210.55.230.0/24^24-29, 210.55.214.0/24^24-29, 210.55.169.0/24^24-29, 210.55.155.0/24^24-29, 210.55.104.0/22^22-29, 210.55.100.0/22^22-29, 202.37.181.0/24^24-29, 202.37.72.0/24^24-29, 202.36.70.0/24^24-29, 202.27.204.0/24^24-29, 202.89.32.0/19^19-29, 202.6.5.0/24^24-29, 202.49.141.0/24^24-29, 203.89.160.0/19^19-29, 202.7.5.32/29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: david.fox(a)maxnet.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050302 source: NZRR --- PREVIOUS OBJECT: route: 210.55.230.0/24 descr: Route for Maxnet - AS9889 origin: AS9889 notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: alastair.johnson(a)maxnet.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20041008 source: NZRR REPLACED BY: route: 210.55.230.0/24 descr: Route for Maxnet - AS9889 origin: AS9889 notify: rpsl-admin(a)nzix.net notify: david.fox(a)maxnet.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050302 source: NZRR --- PREVIOUS OBJECT: route: 210.55.214.0/24 descr: Route for Maxnet - AS9889 origin: AS9889 notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: alastair.johnson(a)maxnet.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20041008 source: NZRR REPLACED BY: route: 210.55.214.0/24 descr: Route for Maxnet - AS9889 origin: AS9889 notify: rpsl-admin(a)nzix.net notify: david.fox(a)maxnet.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050302 source: NZRR --- PREVIOUS OBJECT: route: 210.55.169.0/24 descr: Route for Maxnet - AS9889 origin: AS9889 notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: alastair.johnson(a)maxnet.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20041008 source: NZRR REPLACED BY: route: 210.55.169.0/24 descr: Route for Maxnet - AS9889 origin: AS9889 notify: rpsl-admin(a)nzix.net notify: david.fox(a)maxnet.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050302 source: NZRR --- PREVIOUS OBJECT: route: 210.55.155.0/24 descr: Route for Maxnet - AS9889 origin: AS9889 notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: alastair.johnson(a)maxnet.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20041008 source: NZRR REPLACED BY: route: 210.55.155.0/24 descr: Route for Maxnet - AS9889 origin: AS9889 notify: rpsl-admin(a)nzix.net notify: david.fox(a)maxnet.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050302 source: NZRR --- PREVIOUS OBJECT: route: 210.55.104.0/22 descr: Route for Maxnet - AS9889 origin: AS9889 notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: alastair.johnson(a)maxnet.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20041008 source: NZRR REPLACED BY: route: 210.55.104.0/22 descr: Route for Maxnet - AS9889 origin: AS9889 notify: rpsl-admin(a)nzix.net notify: david.fox(a)maxnet.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050302 source: NZRR --- PREVIOUS OBJECT: route: 210.55.100.0/22 descr: Route for Maxnet - AS9889 origin: AS9889 notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: alastair.johnson(a)maxnet.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20041008 source: NZRR REPLACED BY: route: 210.55.100.0/22 descr: Route for Maxnet - AS9889 origin: AS9889 notify: rpsl-admin(a)nzix.net notify: david.fox(a)maxnet.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050302 source: NZRR --- PREVIOUS OBJECT: route: 202.37.181.0/24 descr: Route for Maxnet - AS9889 origin: AS9889 notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: alastair.johnson(a)maxnet.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20041008 source: NZRR REPLACED BY: route: 202.37.181.0/24 descr: Route for Maxnet - AS9889 origin: AS9889 notify: rpsl-admin(a)nzix.net notify: david.fox(a)maxnet.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050302 source: NZRR --- PREVIOUS OBJECT: route: 202.37.72.0/24 descr: Route for Maxnet - AS9889 origin: AS9889 notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: alastair.johnson(a)maxnet.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20041008 source: NZRR REPLACED BY: route: 202.37.72.0/24 descr: Route for Maxnet - AS9889 origin: AS9889 notify: rpsl-admin(a)nzix.net notify: david.fox(a)maxnet.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050302 source: NZRR --- PREVIOUS OBJECT: route: 202.36.70.0/24 descr: Route for Maxnet - AS9889 origin: AS9889 notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: alastair.johnson(a)maxnet.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20041008 source: NZRR REPLACED BY: route: 202.36.70.0/24 descr: Route for Maxnet - AS9889 origin: AS9889 notify: rpsl-admin(a)nzix.net notify: david.fox(a)maxnet.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050302 source: NZRR --- PREVIOUS OBJECT: route: 202.27.204.0/24 descr: Route for Maxnet - AS9889 origin: AS9889 notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: alastair.johnson(a)maxnet.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20041008 source: NZRR REPLACED BY: route: 202.27.204.0/24 descr: Route for Maxnet - AS9889 origin: AS9889 notify: rpsl-admin(a)nzix.net notify: david.fox(a)maxnet.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050302 source: NZRR --- PREVIOUS OBJECT: route: 202.89.32.0/19 descr: Route for Maxnet - AS9889 origin: AS9889 notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: alastair.johnson(a)maxnet.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20041008 source: NZRR REPLACED BY: route: 202.89.32.0/19 descr: Route for Maxnet - AS9889 origin: AS9889 notify: rpsl-admin(a)nzix.net notify: david.fox(a)maxnet.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050302 source: NZRR

1 0

Notification of NZRR Database changes
by NZRR Database Notifications 01 Mar '05

01 Mar '05

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

1 0

Notification of NZRR Database changes
by NZRR Database Notifications 01 Mar '05

01 Mar '05

Dear Colleague, This is to notify you that some object(s) in NZRR database which you either maintain or are listed as to-be-notified have been added, deleted or changed. These objects are used to configure the various NZIX route servers (http://nzix.net/) so you can expect the relevant servers to be reloaded in the near future. The reloading of the servers is staggered over a period of time so that if you are peering with both servers at an exchange, you can maintain at least one BGP session at all times and consequently a full set of routes. --- PREVIOUS OBJECT: route-set: AS9560:RS-ROUTES:AS3856 descr: advertised to AS9560 by Packet Clearing House - AS3856 members: 192.36.148.0/24^24-29, 194.146.106.0/24^24-29, 194.146.107.0/24^24-29, 194.146.108.0/24^24-29, 199.7.77.0/24^24-29, 199.7.64.0/24^24-29, 204.61.210.0/24^24-29, 204.61.210.0/23^23-29, 204.61.212.0/23^23-29, 204.61.216.0/23^23-29, 206.220.228.0/22^22-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: scg(a)pch.net mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050302 source: NZRR REPLACED BY: route-set: AS9560:RS-ROUTES:AS3856 descr: Route set advertised to AS9560 by PCH2 - AS3856 members: 192.36.148.0/24^24-29, 194.146.106.0/24^24-29, 194.146.107.0/24^24-29, 194.146.108.0/24^24-29, 199.7.77.0/24^24-29, 199.7.64.0/24^24-29, 204.61.210.0/24^24-29, 204.61.210.0/23^23-29, 204.61.212.0/23^23-29, 204.61.216.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: scg(a)pch.net mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050302 source: NZRR

1 0

Notification of NZRR Database changes
by NZRR Database Notifications 01 Mar '05

01 Mar '05

Dear Colleague, This is to notify you that some object(s) in NZRR database which you either maintain or are listed as to-be-notified have been added, deleted or changed. These objects are used to configure the various NZIX route servers (http://nzix.net/) so you can expect the relevant servers to be reloaded in the near future. The reloading of the servers is staggered over a period of time so that if you are peering with both servers at an exchange, you can maintain at least one BGP session at all times and consequently a full set of routes. --- PREVIOUS OBJECT: route-set: AS9560:RS-ROUTES:AS42 descr: advertised to AS9560 by Packet Clearing House - AS42 members: 192.36.148.0/24^24-29, 194.146.106.0/24^24-29, 194.146.107.0/24^24-29, 194.146.108.0/24^24-29, 199.7.77.0/24^24-29, 199.7.64.0/24^24-29, 204.61.210.0/24^24-29, 204.61.210.0/23^23-29, 204.61.212.0/23^23-29, 204.61.216.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: scg(a)pch.net mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050302 source: NZRR REPLACED BY: route-set: AS9560:RS-ROUTES:AS42 descr: Route set advertised to AS9560 by PCH1 - AS42 members: 192.36.148.0/24^24-29, 194.146.106.0/24^24-29, 194.146.107.0/24^24-29, 194.146.108.0/24^24-29, 199.7.77.0/24^24-29, 199.7.64.0/24^24-29, 204.61.210.0/24^24-29, 204.61.210.0/23^23-29, 204.61.212.0/23^23-29, 204.61.216.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: scg(a)pch.net mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050302 source: NZRR

1 0

Spam levels in the last 24 hours?
by neil gardner 01 Mar '05

01 Mar '05

Hi guys - Has anyone else noticed a huge increase in Spam levels in the last 24 or so hours? This is only from 2-3 accounts on 2 ISPs (Orcon and Paradise), but I have gone from seeing 1-2 per day to about 30 making it past the (ISP based) filters in the last 24 hours. Interested to hear from mail admins as to whether this is just me being unlucky, or if there's something screwy happening here... Cheers - Neil G NOTICE: This message contains privileged and confidential information intended only for the use of the addressee named above. If you are not the intended recipient of this message you are hereby notified that you must not disseminate, copy or take any action in reliance on it. If you have received this message in error please notify Allied Telesyn Research Ltd immediately. Any views expressed in this message are those of the individual sender, except where the sender has the authority to issue and specifically states them to be the views of Allied Telesyn Research.

5 6

Notification of NZRR Database changes
by NZRR Database Notifications 01 Mar '05

01 Mar '05

Dear Colleague, This is to notify you that some object(s) in NZRR database which you either maintain or are listed as to-be-notified have been added, deleted or changed. These objects are used to configure the various NZIX route servers (http://nzix.net/) so you can expect the relevant servers to be reloaded in the near future. The reloading of the servers is staggered over a period of time so that if you are peering with both servers at an exchange, you can maintain at least one BGP session at all times and consequently a full set of routes. The update causing these changes had the following mail headers: - From: Andy Linton <asjl(a)citylink.co.nz> - Cc: - Subject: - Date: Wed, 2 Mar 2005 18:56:43 +1300 (NZDT) - Msg-Id: <Pine.LNX.4.58.0503021854360.30667(a)jennings.citylink.co.nz> NZRR Database Notification Department --- OBJECT BELOW CREATED: route-set: AS9560:RS-ROUTES:AS42 descr: advertised to AS9560 by Packet Clearing House - AS42 members: 192.36.148.0/24^24-29, 194.146.106.0/24^24-29, 194.146.107.0/24^24-29, 194.146.108.0/24^24-29, 199.7.77.0/24^24-29, 199.7.64.0/24^24-29, 204.61.210.0/24^24-29, 204.61.210.0/23^23-29, 204.61.212.0/23^23-29, 204.61.216.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: scg(a)pch.net mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050302 source: NZRR --- OBJECT BELOW CREATED: route-set: AS9560:RS-ROUTES:AS3856 descr: advertised to AS9560 by Packet Clearing House - AS3856 members: 192.36.148.0/24^24-29, 194.146.106.0/24^24-29, 194.146.107.0/24^24-29, 194.146.108.0/24^24-29, 199.7.77.0/24^24-29, 199.7.64.0/24^24-29, 204.61.210.0/24^24-29, 204.61.210.0/23^23-29, 204.61.212.0/23^23-29, 204.61.216.0/23^23-29, 206.220.228.0/22^22-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: scg(a)pch.net mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050302 source: NZRR

1 0

Peering exchange in the Wairarapa?
by Blair Harrison 01 Mar '05

01 Mar '05

Hi Guys, I'm just wondering if there is any interest at all in having a peering exchange of some kind in the Wairarapa. I know I've been thinking about such a beast for a while, but at the moment there's only a couple of ISP-like entities (that I know of) who might possibly be interested. WISE Net would be happy to house such a beast if it could be shown that there was sufficient interest, although I'm not sure we're exactly what you might call neutral territory :) So really what I'm asking is, is there anyone else out there? Do you want to peer with us? With others? Have you got a network you want to connect to others with in the Wairarapa at a central place? Raise your hands now, or forever shall your cat5 be under-utilised :) Cheers, Blair Harrison Systems Administrator WISE Net | http://wise.net.nz

4 3

I-Root Server avaiable at the WIX
by Andy Linton 28 Feb '05

28 Feb '05

There is now an instance of an anycast I-Root name server attached to the WIX. Those peering with the WIX route servers should be seeing an announcment for 192.36.148.0/24. From Wellington I'm seeing RTTs like this: $ ping 192.36.148.17 PING 192.36.148.17 (192.36.148.17) 56(84) bytes of data. 64 bytes from 192.36.148.17: icmp_seq=1 ttl=252 time=3.90 ms 64 bytes from 192.36.148.17: icmp_seq=2 ttl=252 time=1.12 ms 64 bytes from 192.36.148.17: icmp_seq=3 ttl=252 time=1.73 ms 64 bytes from 192.36.148.17: icmp_seq=4 ttl=252 time=2.07 ms 64 bytes from 192.36.148.17: icmp_seq=5 ttl=252 time=1.18 ms 64 bytes from 192.36.148.17: icmp_seq=6 ttl=252 time=1.62 ms 64 bytes from 192.36.148.17: icmp_seq=7 ttl=252 time=1.80 ms 64 bytes from 192.36.148.17: icmp_seq=8 ttl=252 time=1.92 ms 64 bytes from 192.36.148.17: icmp_seq=9 ttl=252 time=1.43 ms --- 192.36.148.17 ping statistics --- 9 packets transmitted, 9 received, 0% packet loss, time 8080ms rtt min/avg/max/mdev = 1.125/1.867/3.905/0.782 ms and from a host in Auckland which doesn't see the announcement I see: $ ping 192.36.148.17 PING 192.36.148.17 (192.36.148.17): 56 data bytes 64 bytes from 192.36.148.17: icmp_seq=0 ttl=55 time=257.7 ms 64 bytes from 192.36.148.17: icmp_seq=1 ttl=55 time=255.9 ms 64 bytes from 192.36.148.17: icmp_seq=2 ttl=55 time=255.9 ms 64 bytes from 192.36.148.17: icmp_seq=3 ttl=55 time=256.8 ms 64 bytes from 192.36.148.17: icmp_seq=4 ttl=55 time=256.2 ms 64 bytes from 192.36.148.17: icmp_seq=5 ttl=55 time=257.9 ms 64 bytes from 192.36.148.17: icmp_seq=6 ttl=55 time=259.5 ms 64 bytes from 192.36.148.17: icmp_seq=7 ttl=55 time=256.5 ms 64 bytes from 192.36.148.17: icmp_seq=8 ttl=55 time=257.2 ms --- 192.36.148.17 ping statistics --- 9 packets transmitted, 9 packets received, 0% packet loss round-trip min/avg/max = 255.9/257.0/259.5 ms Thanks to InternetNZ who funded this and to Packet Clearing House and Autonomica for making it happen. Enjoy!

9 13

RE: [nznog] I-Root Server avaiable at the WIX
by Matt Mariu 28 Feb '05

28 Feb '05

I sort of came along late in the 'news' game when the Major Telco's decided to de-peer.. To that effect, Does anyone out there have a solid explanation from them as to why they chose to do what they Did ? Joe, You used to work @ Clear.. Surely you have inside knowledge :) Sorry if this is old news, if theres a link, post it please. -----Original Message----- From: Keith Davidson [mailto:keith(a)wise.net.nz] Sent: Tuesday, 1 March 2005 14:19 To: nznog(a)list.waikato.ac.nz Subject: Re: [nznog] I-Root Server avaiable at the WIX Hmmm, so the aberrant nature of peering in NZ rears its ugly head... Seems strange that the telcos would prefer to route offshore at a financial and a performance cost, rather than peer in NZ and give their users faster speeds and cost reductions... Keith Davidson

2 1

RE: [nznog] I-Root Server avaiable at the WIX
by neil gardner 28 Feb '05

28 Feb '05

>But it still says on Paradises website: > >Citylink Traffic is calculated in the same way as JetStart Traffic, with the >exception of traffic delivered through the Wellington Internet Exchange >(WIX), which is completely free! And there's nothing inaccurate about that is there? They just don't send any more traffic over WIX - but if they did - it would be free. :-) Anyway, good to see they aren't letting elegant solutions get in the way of MORE MONEY!!! Cheers - N. NOTICE: This message contains privileged and confidential information intended only for the use of the addressee named above. If you are not the intended recipient of this message you are hereby notified that you must not disseminate, copy or take any action in reliance on it. If you have received this message in error please notify Allied Telesyn Research Ltd immediately. Any views expressed in this message are those of the individual sender, except where the sender has the authority to issue and specifically states them to be the views of Allied Telesyn Research.

1 0

IPv6 national peering
by Leigh Smith 27 Feb '05

27 Feb '05

Hi all Just to let the people that are interested in IPv6 WorldxChange are now peered at the APE a second peer point will be available soon 2001:7fa:4:c0cb::9a03 AS 17435 Regards Leigh

1 0

IPV6, Cisco
by Philip D'Ath 26 Feb '05

26 Feb '05

After much torment this weekend I have managed to get IPv6 running nicely on a low end Cisco DSL router (Cisco 837). If anyone wants an IPv6 connection at home (and a /48 block of real world IPv6 address space) to experiment with, say yourself some grief and start with this. http://www.ifm.net.nz/cookbooks/ipv6configwizard.html Now if we can just get a critical mass of users we might be able to tempt an ISP to offer native connections ... and actually use Joe's IPv6 F root server.

1 0

RE: [nznog] IPv6, NAT-PT
by Philip D'Ath 26 Feb '05

26 Feb '05

I'm talking about using NAT-PT to allow a native ipv6 network to talk to an ipv4 network. Without some kind of protocol translation (aka PT) ipv6 can't talk to ipv4. The reason this has to be done is because you can't buy an ipv6 connection to an ISP in NZ yet. -----Original Message----- From: Cameron Kerr [mailto:cameron(a)humbledown.org] Sent: Saturday, 26 February 2005 2:27 p.m. To: Philip D'Ath Cc: nznog Subject: Re: [nznog] IPv6, NAT-PT On 26/02/2005, at 1:25 PM, Philip D'Ath wrote: > I'm trying to get NAT-PT support working on a Cisco DSL router to > support native ipv6 clients behind it. I've done a lot of searching, > and can't find the answers to what I'm doing wrong. I have two > problems. Why are you using NAT with IPv6? There is very little reason pros for using IPv6 with NAT, and many cons. Afterall, NAT is just a hack for IPv4 to prevent address exhaustion. IIRC, ISPs are not to give out single IP addresses, but rather /64 allocations. Anyone care to correct me on this? -- Cameron Kerr Telecommunications Teaching Fellow & SysAdmin ckerr(a)cs.otago.ac.nz

7 15

Paradise bouncing emails?
by PhoneNet 25 Feb '05

25 Feb '05

Anyone else getting complaints from customers re email destined for Paradise accounts being bounced? Ian

3 2

RE: [nznog] IPv6, NAT-PT
by Philip D'Ath 25 Feb '05

25 Feb '05

I'm not wishing to get access to ipv6 content at this stage (but will of course eventually want to do this). I'm wanting to start using ipv6 internally. Once we are using it, I'll probably start some of our clients using it later this year. Once enough people are using it hopefully some ISP will start offering native ipv6 connections, because they will have a business case to do so. Hence, the desire to use NAT-PT, otherwise I'll be stuck running dual stacks. -----Original Message----- From: Joe Abley [mailto:jabley(a)isc.org] Sent: Saturday, 26 February 2005 4:57 p.m. To: Philip D'Ath Cc: nznog; Cameron Kerr Subject: Re: [nznog] IPv6, NAT-PT On 25 Feb 2005, at 20:39, Philip D'Ath wrote: > I'm talking about using NAT-PT to allow a native ipv6 network to talk > to an ipv4 network. Without some kind of protocol translation (aka > PT) > ipv6 can't talk to ipv4. The reason this has to be done is because > you can't buy an ipv6 connection to an ISP in NZ yet. Most people running v6 are only using their v6 access to reach content served over v6. Most of the mechanisms suggested to allow a v6-only host to access v4 content remain undeployed. If you want to reach v6 content, the easiest thing to do is find an ISP who can give you v6 transit. In the absense of local carriers with dual-stack edge routers (i.e. in the case of most of the planet) the way you do this is terminate a tunnel somewhere. Joe

1 0

IPv6, NAT-PT
by Philip D'Ath 25 Feb '05

25 Feb '05

I'm trying to get NAT-PT support working on a Cisco DSL router to support native ipv6 clients behind it. I've done a lot of searching, and can't find the answers to what I'm doing wrong. I have two problems. First, I can't get them to grab additional parameters from DHCP. I'm using: ipv6 dhcp pool dhcppool dns-server ::210.55.12.1 - I know the above is not likely to answer AAAA requests, but I plan to use DNS-ALG domain-name local.arpa Interface Ethernet0 ipv6 enable ipv6 nd other-config-flag ipv6 dhcp server dhcppool The second problem is I can't NAT-PT to work at all. It doesn't even attempt to do translations. Snippits I'm using are: Interface Dialer0 description ipv4 Interface connecting to Internet ipv6 nat Interface Ethernet0 description ipv6 Interface connection to local lan (aka LINK-LOCAL) ipv6 address 3FFE:AAAA:BBBB:1::9/64 - An address copied from an example, hope to use LINK-LOCAL addresses later ipv6 enable ipv6 nat ipv6 nat translation udp-timeout 600 ipv6 nat v6v4 source list pt-list1 interface Dialer0 overload ipv6 nat prefix 3FFE:B00:1::/96 ipv6 access-list pt-list1 permit ipv6 3FFE:AAAA:BBBB:1::/64 any

3 2

Notification of NZRR Database changes
by NZRR Database Notifications 24 Feb '05

24 Feb '05

Dear Colleague, This is to notify you that some object(s) in NZRR database which you either maintain or are listed as to-be-notified have been added, deleted or changed. These objects are used to configure the various NZIX route servers (http://nzix.net/) so you can expect the relevant servers to be reloaded in the near future. The reloading of the servers is staggered over a period of time so that if you are peering with both servers at an exchange, you can maintain at least one BGP session at all times and consequently a full set of routes. The update causing these changes had the following mail headers: - From: Andy Linton <asjl(a)citylink.co.nz> - Cc: - Subject: [CityLink #1958] Routing updates for WIX Route Servers (fwd) - Date: Fri, 25 Feb 2005 17:41:59 +1300 (NZDT) - Msg-Id: <Pine.LNX.4.58.0502251727510.24165(a)jennings.citylink.co.nz> NZRR Database Notification Department --- PREVIOUS OBJECT: route-set: AS9439:RS-ROUTES:AS18119 descr: advertised to AS9439 by LinuxNet - AS18119 members: 192.107.113.0/24^24-29, 202.7.4.80/29, 202.21.136.0/23^23-29, 202.36.44.0/24^24-29, 202.37.136.0/24^24-29, 202.49.249.0/24^24-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: lincoln(a)linuxnet.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050222 source: NZRR REPLACED BY: route-set: AS9439:RS-ROUTES:AS18119 descr: advertised to AS9439 by LinuxNet - AS18119 members: 192.107.113.0/24^24-29, 202.7.4.80/29, 202.7.6.32/28^28-29, 202.21.136.0/23^23-29, 202.36.44.0/24^24-29, 202.37.136.0/24^24-29, 202.49.249.0/24^24-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: lincoln(a)linuxnet.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050225 source: NZRR

1 0

Notification of NZRR Database changes
by NZRR Database Notifications 24 Feb '05

24 Feb '05

Dear Colleague, This is to notify you that some object(s) in NZRR database which you either maintain or are listed as to-be-notified have been added, deleted or changed. These objects are used to configure the various NZIX route servers (http://nzix.net/) so you can expect the relevant servers to be reloaded in the near future. The reloading of the servers is staggered over a period of time so that if you are peering with both servers at an exchange, you can maintain at least one BGP session at all times and consequently a full set of routes. The update causing these changes had the following mail headers: - From: Andy Linton <asjl(a)citylink.co.nz> - Cc: - Subject: [CityLink #1951] Routing updates for APE Route Servers (fwd) - Date: Fri, 25 Feb 2005 16:57:10 +1300 (NZDT) - Msg-Id: <Pine.LNX.4.58.0502251654230.24165(a)jennings.citylink.co.nz> NZRR Database Notification Department --- PREVIOUS OBJECT: route-set: AS9560:RS-ROUTES:AS4770 descr: Route set for AS4770 members: 138.235.0.0/16, 192.107.113.0/24, 192.173.16.0/21, 198.32.66.0/24, 199.212.90.0/23, 199.212.92.0/23^23-24, 202.6.84.0/24, 202.12.70.0/24, 202.12.248.0/21, 202.14.100.0/24, 202.21.130.0/24, 202.21.136.0/23, 202.36.155.0/24, 202.36.157.0/24, 202.36.32.0/24, 202.36.36.0/22, 202.36.44.0/24, 202.36.45.0/24, 202.36.76.0/23, 202.37.136.0/24, 202.37.140.0/22, 202.37.144.0/21, 202.37.163.0/24, 202.37.197.0/24, 202.37.200.0/22, 202.37.224.0/21, 202.37.232.0/24, 202.37.240.0/23, 202.37.252.0/23, 202.37.76.0/24, 202.37.85.0/24, 202.41.136.0/22, 202.41.140.0/24, 202.49.62.0/24, 202.49.89.0/24, 202.49.249.0/24, 202.50.87.0/24, 202.50.246.0/24, 202.55.96.0/20, 202.74.224.0/21, 203.9.179.0/24, 203.9.180.0/24, 205.233.128.0/21, 205.233.136.0/23, 205.233.243.0/24, 210.185.0.0/18, 210.48.0.0/17, 210.54.136.0/22, 210.54.140.0/24, 210.54.160.0/19, 210.55.182.0/23, 210.55.24.0/22, 210.55.253.0/24, 210.56.32.0/20 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: john.johnston(a)iconz.net mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20030407 changed: rpsl-admin(a)nzix.net 20040629 changed: rpsl-admin(a)nzix.net 20040831 changed: rpsl-admin(a)nzix.net 20040930 changed: rpsl-admin(a)nzix.net 20050224 source: NZRR REPLACED BY: route-set: AS9560:RS-ROUTES:AS4770 descr: advertised to AS9560 by ICONZ - AS4770 members: 138.235.0.0/16^16-29, 192.107.113.0/24^24-29, 192.173.16.0/21^21-29, 198.32.66.0/24^24-29, 199.212.90.0/23^23-29, 199.212.92.0/23^23-29, 202.6.84.0/24^24-29, 202.12.70.0/24^24-29, 202.12.248.0/21^21-29, 202.14.100.0/24^24-29, 202.21.130.0/24^24-29, 202.21.136.0/23^23-29, 202.36.155.0/24^24-29, 202.36.157.0/24^24-29, 202.36.32.0/24^24-29, 202.36.36.0/22^22-29, 202.36.44.0/24^24-29, 202.36.45.0/24^24-29, 202.36.76.0/23^23-29, 202.37.136.0/24^24-29, 202.37.140.0/22^22-29, 202.37.144.0/21^21-29, 202.37.163.0/24^24-29, 202.37.197.0/24^24-29, 202.37.200.0/22^22-29, 202.37.224.0/21^21-29, 202.37.232.0/24^24-29, 202.37.240.0/23^23-29, 202.37.252.0/23^23-29, 202.37.76.0/24^24-29, 202.37.85.0/24^24-29, 202.41.136.0/22^22-29, 202.41.140.0/24^24-29, 202.49.62.0/24^24-29, 202.49.89.0/24^24-29, 202.49.249.0/24^24-29, 202.50.87.0/24^24-29, 202.50.246.0/24^24-29, 202.55.96.0/20^20-29, 202.74.224.0/21^21-29, 202.182.192.0/19^19-29, 205.233.128.0/21^21-29, 205.233.136.0/23^23-29, 205.233.243.0/24^24-29, 210.185.0.0/18^18-29, 210.48.0.0/17^17-29, 210.54.136.0/22^22-29, 210.54.140.0/24^24-29, 210.54.160.0/19^19-29, 210.55.182.0/23^23-29, 210.55.24.0/22^22-29, 210.55.253.0/24^24-29, 210.56.32.0/20^20-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: john(a)iconz.net mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050225 source: NZRR --- PREVIOUS OBJECT: route-set: AS9439:RS-ROUTES:AS4770 descr: Route set for AS4770 members: 138.235.0.0/16, 192.107.113.0/24, 192.173.16.0/21, 198.32.66.0/24, 199.212.90.0/23, 199.212.92.0/23^23-24, 202.6.84.0/24, 202.12.70.0/24, 202.12.248.0/21, 202.14.100.0/24, 202.21.130.0/24, 202.21.136.0/23, 202.36.155.0/24, 202.36.157.0/24, 202.36.32.0/24, 202.36.36.0/22, 202.36.44.0/24, 202.36.45.0/24, 202.36.76.0/23, 202.37.136.0/24, 202.37.140.0/22, 202.37.144.0/21, 202.37.163.0/24, 202.37.197.0/24, 202.37.200.0/22, 202.37.224.0/21, 202.37.232.0/24, 202.37.240.0/23, 202.37.252.0/23, 202.37.76.0/24, 202.37.85.0/24, 202.41.136.0/22, 202.41.140.0/24, 202.49.62.0/24, 202.49.89.0/24, 202.49.249.0/24, 202.50.87.0/24, 202.50.246.0/24, 202.55.96.0/20, 202.74.224.0/21, 203.9.179.0/24, 203.9.180.0/24, 205.233.128.0/21, 205.233.136.0/23, 205.233.243.0/24, 210.185.0.0/18, 210.48.0.0/17, 210.54.136.0/22, 210.54.140.0/24, 210.54.160.0/19, 210.55.182.0/23, 210.55.24.0/22, 210.55.253.0/24, 210.56.32.0/20 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: john.johnston(a)iconz.net mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20030407 changed: rpsl-admin(a)nzix.net 20040629 changed: rpsl-admin(a)nzix.net 20040831 changed: rpsl-admin(a)nzix.net 20040930 changed: rpsl-admin(a)nzix.net 20050224 source: NZRR REPLACED BY: route-set: AS9439:RS-ROUTES:AS4770 descr: advertised to AS9439 by ICONZ - AS4770 members: 138.235.0.0/16^16-29, 192.107.113.0/24^24-29, 192.173.16.0/21^21-29, 198.32.66.0/24^24-29, 199.212.90.0/23^23-29, 199.212.92.0/23^23-29, 202.6.84.0/24^24-29, 202.12.70.0/24^24-29, 202.12.248.0/21^21-29, 202.14.100.0/24^24-29, 202.21.130.0/24^24-29, 202.21.136.0/23^23-29, 202.36.155.0/24^24-29, 202.36.157.0/24^24-29, 202.36.32.0/24^24-29, 202.36.36.0/22^22-29, 202.36.44.0/24^24-29, 202.36.45.0/24^24-29, 202.36.76.0/23^23-29, 202.37.136.0/24^24-29, 202.37.140.0/22^22-29, 202.37.144.0/21^21-29, 202.37.163.0/24^24-29, 202.37.197.0/24^24-29, 202.37.200.0/22^22-29, 202.37.224.0/21^21-29, 202.37.232.0/24^24-29, 202.37.240.0/23^23-29, 202.37.252.0/23^23-29, 202.37.76.0/24^24-29, 202.37.85.0/24^24-29, 202.41.136.0/22^22-29, 202.41.140.0/24^24-29, 202.49.62.0/24^24-29, 202.49.89.0/24^24-29, 202.49.249.0/24^24-29, 202.50.87.0/24^24-29, 202.50.246.0/24^24-29, 202.55.96.0/20^20-29, 202.74.224.0/21^21-29, 202.182.192.0/19^19-29, 205.233.128.0/21^21-29, 205.233.136.0/23^23-29, 205.233.243.0/24^24-29, 210.185.0.0/18^18-29, 210.48.0.0/17^17-29, 210.54.136.0/22^22-29, 210.54.140.0/24^24-29, 210.54.160.0/19^19-29, 210.55.182.0/23^23-29, 210.55.24.0/22^22-29, 210.55.253.0/24^24-29, 210.56.32.0/20^20-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: john(a)iconz.net mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050225 source: NZRR

1 0

Notification of NZRR Database changes
by NZRR Database Notifications 24 Feb '05

24 Feb '05

Dear Colleague, This is to notify you that some object(s) in NZRR database which you either maintain or are listed as to-be-notified have been added, deleted or changed. These objects are used to configure the various NZIX route servers (http://nzix.net/) so you can expect the relevant servers to be reloaded in the near future. The reloading of the servers is staggered over a period of time so that if you are peering with both servers at an exchange, you can maintain at least one BGP session at all times and consequently a full set of routes. The update causing these changes had the following mail headers: - From: Andy Linton <asjl(a)citylink.co.nz> - Cc: - Subject: - Date: Fri, 25 Feb 2005 11:03:24 +1300 (NZDT) - Msg-Id: <Pine.LNX.4.58.0502251102510.23787(a)jennings.citylink.co.nz> NZRR Database Notification Department --- PREVIOUS OBJECT: route-set: AS9560:RS-ROUTES:AS23754 descr: advertised to AS9560 by Citylink - AS23754 members: 198.48.0.0/22^22-24, 202.8.44.0/22^22-24, 202.7.5.0/24, 202.7.7.0/24, 203.118.144.0/24 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20041029 source: NZRR REPLACED BY: route-set: AS9560:RS-ROUTES:AS23754 descr: advertised to AS9560 by Citylink - AS23754 members: 198.48.0.0/22^22-24, 202.8.44.0/22^22-24, 202.7.5.0/24, 202.7.6.0/24, 203.118.144.0/24 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20041029 source: NZRR

1 0

Email hammering from mta20X-rme.xtra.co.nz
by Simon Buchanan 24 Feb '05

24 Feb '05

Hi there, im wondering if anyone could point me in the rite direction here. Starting last night we have been hammered by xtra's mail servers from the email address haggis(a)guard.co.nz... Has any body on the list had simlar problems... How can i follow this up? Suggestions please :) Regards, Simon

3 2

RE: [nznog] (OT) Fax spam (Anti-spam legislation update)
by Regan Murphy 24 Feb '05

24 Feb '05

>You will need: > >* An older fax machine that scans the document slowly as it sends it >* A vivid marker >* Some sellotape This is the age of technology. Surely a few lines of code, a modem and some fax protocols could achieve the same result. Maybe you could even redirect your email spam junk folders to your fax spammer to give it a nice twist. ;) -- Regan

2 1