- NZNOG - lists.nznog.org

Temporary IP tunnel to Digiweb
by Stephen Sheehan 17 Apr '07

17 Apr '07

Hi, Is anyone able to provide an IP tunnel to bypass the telstra clear outage, 128k will be fine. We need access to our extranet based at digiweb in christchurch. Thanks Stephen Chillisoft Ltd __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

2 1

Email to SMS gateway
by Clark Mills 16 Apr '07

16 Apr '07

Hi all. I read this on one of our internal mailing lists, thought it might be of interest / use. We use something like this for server monitoring but it's not so good if your email server / network is down, aside from the potential lagginess [SP?] that sometimes occurs with the SMS service. Still, it may have some value to you. Of course if any information below is wrong, please let me know. Cheers... Clark ================================================================================= [forwarded & edited] If you are on Vodafone, you can 'register' you phone by texting the letter R to the number 901. You should then get back a 'you are registered etc' welcome message. Once your phone is registered anyone/thing can send you a txt by using an email address such as: 6421123456(a)sms.vodafone.net.nz Where your mobile number is presumed to be 021-123456. As far as I know, there is no charge for this service.

14 17

Re: [nznog] Email to SMS gateway
by Stewart Fleming 16 Apr '07

16 Apr '07

We use the Psychic Hotline. When anything is about to go down, they give us a call and we can get it fixed before it causes a problem. -- -- Tel: 03 474 2100 Cell: 021 993 125 Web: www.wic.co.nz Co-location and Web hosting. Dunedin-wide wireless. Independent Internet Service Provider.

3 2

Re: [nznog] Email to SMS gateway
by Phill Mckenna 16 Apr '07

16 Apr '07

We use a combination of SMS messages sent via a Wavecom GSM Modem for server and network link and services monitoring, and our main alarm system connects via xml to a "datashed" gateway which gives us handset availability notification, automatic escalation and fallback to a Telecom CDMA modem for backup. In addition we send a test message once an hour to a remote site, if the message isn't heard, it triggers a timer that eventually triggers a voice dialer. Telecom paging was our previous provider, however as they keep continuing to threaten to phase this out, we moved over to SMS some time ago. Phill Mckenna Operations Technology Manager Kapiti Coast District Council Operations Centre DDI: +64 4 296 4753 Fax: +64 4 296 4733 Mobile: +64 027 555 5753 E mail: phill.mckenna(a)kapiticoast.govt.nz -----Original Message----- From: Alastair Johnson [mailto:aj(a)sneep.net] Sent: Tuesday, 17 April 2007 11:30 a.m. To: NZ Network Operators Group Subject: Re: [nznog] Email to SMS gateway Erin Salmon - Unleash wrote: > We actually use a Nokia cellphone and a data cable. I'm not aware of a > method which guarantees delivery. We are in the CBD and I note sometimes > when all those nightclubbers are frantically messaging each other messages > occasionally don't make it to the recipient. Best solution to my mind is > just to send a message periodically until a reply is sent to the system to > dismiss the notification. That is a reasonably practical solution. It has the nice side effect of ensuring that even if the message does get delivered, whoever is on call isn't ignoring it. I looked at this a while ago, and used an external mail-to-SMS provider (Bulletin Wireless) which worked fine. Obviously having an out-of-band path to them is also handy. As someone else mentioned, Telecom's analog paging service is also reliable and easy to automate. Pagers tend to work when out of cell coverage or in deep dark basements. _______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog ##################################################################################### This e-mail message and any attached files may contain confidential information, and may be subject to legal professional privilege. If you are not the intended recipient, please delete. Unless formally stated, this e-mail and any attachments do not necessarily reflect the views of the Kapiti Coast District Council. The Council takes extensive precautions with the aim of detecting and removing any virus or defects from its e-mail system but accepts no liability for loss or damage should this e-mail not be virus or defect free or should there be any errors in transmission. #####################################################################################

1 0

Vodafone Peering
by Philip D'Ath 16 Apr '07

16 Apr '07

Does Vodafone peer with anybody in NZ? I've been playing with an HSPDA card, and every traceroute (even to IHUG!) always go directly to the US. I would thought they would at least peer with the other two major Telco's in NZ.

4 3

Re: [nznog] Save your money and hassle
by John ＠ netTRUST 16 Apr '07

16 Apr '07

> [Reply] > > John, > > What do you use to drive it? I see the ActiveXperts software is another > US$395 .... > > Must be a simpler way. SMS link http://smslink.sourceforge.net/ Pro's works well once setup and tuned. Has support for MySQL Supports all major SMS modems though I'm unsure of the support for Nokia or any cellphone. Con's - slow to process send / receive (as is most software because the msgs get stored on the SIM card first) Good for low traffic, unsuited to bulk send/receive. Note to the person suggesting using a cellphone. SMS modems use a pretty standardised AT command set and you talk to them just like you would to a modem. Cellphones AFAIK usually have proprietory interfaces.

2 1

Save your money and hassle
by John ＠ netTRUST 16 Apr '07

16 Apr '07

We exclusively use SMS modems here. The Wavecom is the best you can buy and only slightly dearer then the cheaper models. http://www.itx.co.nz/index.php?cPath=29 is a company I've dealt with before and they are allright.

4 4

Re: [nznog] Email to SMS gateway
by Philip D'Ath 16 Apr '07

16 Apr '07

Actually, SMS does offer "guaranteed" delivery. It doesn't matter if the phone is off, an error occurs in communication, a data circuit goes down ... However there are limits. If the message cannot be delivered (such as end device failure) then you can request a receipt to get notification of this. I don't recall ever noticing a lag of hours for SMS delivery (I don't ever recall a TXT taking more than 60s to be delivered) but I guess different TXT processing systems use different methods for getting the TXT into the network for delivery. -----Original Message----- From: Jasper Bryant-Greene [mailto:j(a)digiweb.net.nz] Sent: Tuesday, 17 April 2007 11:15 a.m. To: Philip D'Ath Cc: Samuel Collinson; Dan Clark; NZ Network Operators Group Subject: Re: [nznog] Email to SMS gateway On this - we have found SMS to be a bit unreliable lately, with messages being delivered hours late or not at all. I am aware that SMS does not provide "guaranteed delivery" - what methods are others on this list using to send alerts reliably? Cheers Jasper

4 3

Affordable Voltage Monitoring over Ethernet?
by Dan Clark 15 Apr '07

15 Apr '07

Gidday, Just wondering if any network operators etc here are using or have seen any kind of device that can measure voltage/current out there somewhere on a network and we can interrogate it remotely and may even send alerts etc if drops below threshold etc? Would have to be resonably affordable, and in simple kit form or off the shelf. If nothing available that anyone can think of I may develop something along these lines, cheap, simple, ethernet, and probably 12V Open for discussion if anyone remotely interested. Regards Dan

5 4

MP3 streaming data usage
by John ＠ netTRUST 15 Apr '07

15 Apr '07

Anyone have any idea how much data would be consumed each day streaming MP3 at 128kbps audio stream rate? Thanks.

11 14

Re: [nznog] MP3 streaming data usage
by Richard Naylor 15 Apr '07

15 Apr '07

At 03:38 p.m. 16/04/2007 +1200, Neil Gardner wrote: >Ergh... Hate to say this, but don't you have that 10 bits to the byte >thing approximately ass-backwards? No. As I said, I come from an Ancient World (TM), where we debugged protocols like DDCMP with a Tek Logic Analayser, scope or logic probe. None of this Ethereal stuff, ethernet hadn't escaped from PARC and Vint was still drawing on envelopes. RS-232 was modern, current loop was till very active (sorry, no pun intended). (Probably Michael Newberry is the only one who will get it anyway, Andy and Sid say they're too young, and the others are looking blank) Each Byte is (or was) a START bit, 8 data bits, PARITY and a STOP or IDLE bit. So we always approximated it to 10 bits. (different devices handle parity bits different ways, it used to be that if there was no parity, no bit was used. LSI USARTS started the trend towards always having a bit used. This is a world where a serial port took up a whole UNIBUS slot (ie a card 400mm by 200mm). As I said, its an approximation for budgeting purposes and comes from an ancient era. Have you found the beer yet ? R

2 1

Re: [nznog] Affordable Voltage Monitoring over Ethernet?
by Richard Naylor 15 Apr '07

15 Apr '07

At 04:10 p.m. 16/04/2007 +1200, Dan Clark wrote: >Gidday, > Just wondering if any network operators etc here are using or have seen > any kind of device that can measure voltage/current out there somewhere > on a network and we can interrogate it remotely and may even send alerts > etc if drops below threshold etc? >Would have to be resonably affordable, and in simple kit form or off the >shelf. > >If nothing available that anyone can think of I may develop something >along these lines, cheap, simple, ethernet, and probably 12V >Open for discussion if anyone remotely interested. google for a Link-10 or Link-20, I think they now do ethernet, it used to be serial, but you just chucked in a Lantronix thingy

1 0

Re: [nznog] MP3 streaming data usage
by Richard Naylor 15 Apr '07

15 Apr '07

At 02:49 p.m. 16/04/2007 +1200, Neil Gardner wrote: >Dammit - I know we've been asked to stop this, but now something >interesting has happened... you found the beer ? >Richard, you, who I know has great experience in this, have posted >figures that are UNDER my very basic but probably right theoretical >minimums > >How do you fit 3600 seconds at 128kbps into 46MB ? I get 56.25MB... I have this ancient spreadsheet with a few assumptions.... I basically round 10bits to the byte to cover overheads in the packet, etc. So a data rate of say 128kbps is 12.8KB per sec or 0.13Mbps 768KB per minute or 7.68Mbps 46080 KB per hour or 460.9 Mbps or 46.08 MBytes per hour Remembering that you will get silence and various other things (outages, etc) it will always be an approximation. It just gives you a feel for the order of magnitude of the bill :-) Most stations actually have a second stream in reserve for special "promotional" occassions and they kick them into life every now and then, just to muck up the stats. The biggest use of it has been to work out that a 10GB plan is OK for radio stations at 32Kbps streams. Now that 40+GB plans are out, folks are looking at webcams again and it looks like we can stream a camera and stay inside a 40GB plan at 128k video, which isn't too bad looking. I should probably rework the spreadsheet for HD streams at 10Mbps. It looks like 5TB a month. And yes, IPV6 and multicast will solve all our problems, including world hunger and the endless shortage of beer. But I'm showing my age......

2 1

Re: [nznog] IPv6 Incentive
by Scott Weeks 14 Apr '07

14 Apr '07

--- andy(a)nosignal.org wrote:---------------- ip is a means to an end, I don't craft packets for fun, I do work or have fun, and ip occurs as a way to send my messages from A to B. --------------------------------------------- ding, ding, ding! From the many lists discussing these issues recently, we finally have a winner! Most folk don't care about v4, v6, v8 or v<insert stuff here>. They want to do something and they 'just want it to work'. 99.999% couldn't give less than a crap how that happens. scott BTW 6,525,170,264 x .00001 = 65250 That's this: World — Population: 6,525,170,264 (July 2006 est.) https://www.cia.gov/cia/publications/factbook/print/xx.html times one minus five nines 65250 is about how many of there are who do give more than a crap about how that happens. Beer...MMMM... 8-)

12 14

[Fwd: Re: IPv6 Incentive]
by Gerard Creamer 12 Apr '07

12 Apr '07

On 13/04/2007 4:24 p.m., Craig Whitmore wrote: >> I'm not a porn fan myself, but from other types of media, 10G isn't that >> much. >> Maybe if they put 1TB of porn and 1TB of free tv content from a major >> studio, then we'd have an experiment. >> Would it be better to be Geek TV (Dr Who, Firefly, etc) or Jo Public TV (Lost, Grey's Anatomy, all 500 seasons of Coro St etc)? I think Geek TV would get more drive for it. Like it would happen though. >> > > There is some content at http://www.ipv6porn.co.nz. (If you have IPv6) Looking at http://www.v6.co.nz/ on the 'Who Provides IPv6' there's nothing - is there an NZ provider of IPv6? I know this topic has come up on the list before, and it usually degrades in circular discussions - it would be nice to hear 'Yes, ISP X offers IP6 within NZ'. Without anyone spieling on about the glories of their own wares, of course :^) Gerard

2 1

New Sepctrum Auction
by Paul Horak 12 Apr '07

12 Apr '07

Plans for auctioning the 2.3Ghz band for BWA/WiMAX have been published: http://www.rsm.govt.nz/auctions/auction09/index.html I think there is a real opportunity here for some of us to get access to spectrum. At present the lions share (or possibly all of it) will go to two or three companies to build a nationwide network. There is also a proposal to allocate some spectrum for regional operators under a "Managed Park". I suspect there are quite a few people interested in this who have not yet been in contact with RSM - it is essential that you let RSM know your interest and you respond to this consultation document. If the vast majority of comments come from the large providers wishing to deploy nationwide networks then I suspect there will be little or no regional spectrum available. I would also be grateful if you can contact me off list if you have an interest in obtaining spectrum for regional use. I have some ideas that might help our cause that I would like to share. 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

2 1

Re: [nznog] IPv6 Incentive
by Scott Weeks 11 Apr '07

11 Apr '07

--- steve(a)focb.co.nz wrote: Scott Weeks wrote: > > --- andy(a)nosignal.org wrote:---------------- > ip is a means to an end, I don't craft packets for fun, I do work or > have fun, and ip occurs as a way to send my messages from A to B. > --------------------------------------------- > > ding, ding, ding! From the many lists discussing these issues > recently, we finally have a winner! Most folk don't care about > v4, v6, v8 or v<insert stuff here>. They want to do something > and they 'just want it to work'. 99.999% couldn't give less > than a crap how that happens. : or are you saying that there are only 65,250 clueful IP/IT : engineers in the world or people working in related fields ? This one. Clueful IP engineers in the world that also care about the version of IP used more than leaving a crap. :-) : Feel like citing references for your 99.999% figure ? It was just for fun and to make the point that most people in the world just don't care how stuff moves around the internet. They just want it to get to where they tell it to go. The five nines comes from many marketing-speak droids when telling everyone that their network has 5-nines of uptime. Of course with no more details than just that... <8-0 <== that's a crazy-eyed marketing droid babbling marketing-speak. scott

1 0

Some graphs of .nz domain statistics
by Blair Harrison 10 Apr '07

10 Apr '07

Hi Guys, I took some of the data provided from the DNC website here: http://dnc.org.nz/story/30221-51-1.html and turned it into some graphs. You can check this out in either HTML or XLS format at my website: http://jedi.school.nz/nzdg.html Hope this is interesting viewing for someone :) Cheers, Blair

1 0

IPv6 Incentive
by Andrew Ruthven 10 Apr '07

10 Apr '07

Hey, During the NZNOG conference it was joked that if the next WoW pack required IPv6 then IPv6 would be rolled out by the ISPs (and transit providers) for the next morning. See the attached mail for an experiment that might be cause it to be rolled out for that evening... Cheers! -- Andrew Ruthven, Wellington, New Zealand At home: andrew(a)etc.gen.nz | This space intentionally | left blank.

15 20

Re: [nznog] IPv6 Incentive
by Simon Lyall 10 Apr '07

10 Apr '07

I think this thread should confine itself to technical matters. Discussion of how to promote ipv6 usage should avoid language and concepts that might be offensive to some people (or their work's filters). Discussion about what is or is not offensive should not be conducted on the list. Simon. Moderator. -- Simon Lyall | Very Busy | Web: http://www.darkmere.gen.nz/ "To stay awake all night adds a day to your life" - Stilgar | eMT.

3 2

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

09 Apr '07

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:AS9889 descr: advertised to AS9560 by Maximum Internet Ltd - AS9889 members: 123.100.64.0/18^18-29, 202.89.32.0/19^19-29, 203.89.160.0/19^19-29, 202.55.96.0/20^20-29, 210.55.100.0/22^22-29, 210.55.104.0/22^22-29, 192.138.251.0/24^24-29, 202.6.5.0/24^24-29, 202.6.116.0/24^24-29, 202.27.204.0/24^24-29, 202.36.70.0/24^24-29, 202.36.227.0/24^24-29, 202.37.72.0/24^24-29, 202.37.181.0/24^24-29, 202.49.141.0/24^24-29, 202.150.102.0/24^24-29, 203.12.15.0/24^24-29, 203.97.42.0/24^24-29, 210.54.13.0/24^24-29, 210.54.142.0/24^24-29, 210.55.169.0/24^24-29, 210.55.214.0/24^24-29, 210.55.230.0/24^24-29, 203.167.219.56/29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: noc(a)maxnet.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20070111 source: NZRR REPLACED BY: route-set: AS9560:RS-ROUTES:AS9889 descr: advertised to AS9560 by Maximum Internet Ltd - AS9889 members: 123.100.64.0/18^18-29, 202.89.32.0/19^19-29, 203.89.160.0/19^19-29, 202.55.96.0/20^20-29, 202.189.160.0/21^21-29, 210.55.100.0/22^22-29, 210.55.104.0/22^22-29, 192.138.251.0/24^24-29, 202.6.5.0/24^24-29, 202.6.116.0/24^24-29, 202.27.204.0/24^24-29, 202.36.70.0/24^24-29, 202.36.227.0/24^24-29, 202.37.72.0/24^24-29, 202.37.162.0/24^24-29, 202.37.181.0/24^24-29, 202.49.141.0/24^24-29, 202.150.102.0/24^24-29, 203.12.15.0/24^24-29, 203.97.42.0/24^24-29, 210.54.13.0/24^24-29, 210.54.142.0/24^24-29, 210.55.169.0/24^24-29, 210.55.214.0/24^24-29, 210.55.230.0/24^24-29, 203.167.219.56/29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: noc(a)maxnet.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20070410 source: NZRR

1 0

More ‘public park’ broadband wireless spectrum released
by Dan Clark 05 Apr '07

05 Apr '07

source from RSM update... More 'public park' broadband wireless spectrum released Further radio spectrum for broadband wireless access has been made available with changes made to the Radiocommunications (General User Radio Licence for Short Range Devices) Notice. The government has opened the 5.47 – 5.725 GHz and 57 - 64 GHz radio frequency bands as 'public park' spectrum for broadband wireless services suitable for expanding wireless local area networks (Wi-Fi) and to extend the reach of existing fibre optic networks. Access to 'public park' spectrum does not attract a licence fee. Previously licensed users in the bands should be able to continue to operate without being unduly impacted. The General User Radio Licence contains conditions to ensure that broadband wireless equipment operating in the 5.47 – 5.725 GHz band does not cause interference to existing radar operations that share this band. Access to the 5.47 – 5.725 GHz band augments access to the 2.4 GHz and 5.8 GHz bands and more than doubles the spectrum that is now exclusively available for wireless local area networks. The General User Radio Licence also contains conditions to ensure that broadband wireless access equipment operating in the 57 – 64 GHz band minimises interference, and maximises reliability and utility within the band. Access to this spectrum may be used to provide short-range (~1 Km) high capacity (1 Gbit/sec) point-to-point links used to extend the reach of fibre-optic cabling, and/or to provide high speed short range backhaul for telecommunications network infrastructure.

4 5

Re: [nznog] Telecom's "peering" change of heart really isn't
by Ian Batterbee 04 Apr '07

04 Apr '07

Somebody wrote: > >Oh, and on your point about universities, I think you will find that most > >(all?) of them already peer. UoA, which is far-and-away the largest university > >in the country, certainly peers at APE. > AUT doesn't peer with APE because it seems a little redundant as we have a connection through Orcon, who peer at APE We also connect to TCL and to KAREN.

7 10

Re: [nznog] Telecom's "peering" change of heart really isn't
by Martin Kealey 04 Apr '07

04 Apr '07

> [...] there are no common and widely accepted > definitions of what peering and other related terms actually mean, > where 'widely' encompasses the whole of industry. We need to take off our techie hats and put on our lawyerie or accountant ones. How about this: Neutral Peering is peering at a Neutral Location. A Neutral Location is one where the entity providing the location does not provide connectivity to that location (or does so "at arms length" and competing equally with all other connectivity providers). A Neutral Location may be any physical size, provided that the location provider does not charge for traffic or bandwidth between participants within the location. In other words, Citylink metro qualifies as a location encompassing all of Wellington, because there is no charge within the "location". Telecom "peering" does not qualify beccause you can't backhaul your own cable and knock on their door saying "where do I plug in". Or if you could, you wouldn't get peering on an arms-length cost basis. -Martin

3 3

Re: [nznog] Google Launches new in home fibre optic service
by Stewart Fleming 02 Apr '07

02 Apr '07

nznog-request(a)list.waikato.ac.nz wrote: >Date: Mon, 02 Apr 2007 14:31:43 +1200 >From: Dean Pemberton <nznog(a)deanpemberton.com> > > > How many people read this, realised it was an april-fools day hoax, and > >still thought "Hmmmmmm Thats not a bad idea........ " > > >Dean > > "Four options were proposed to develop the network in three phases. The capital cost of the options ranged between approximately $700,000 and $7.6 million. The annual operating cost of the network is approximately $150,000. These different options and costs arise from the different methods costed out for laying the fibre network, *including the use of the DCC’s own wastewater ducting*. The study concludes that a combination of these methods may be the most cost-effective and efficient for different portions of each route." URBAN FIBRE NETWORK FEASIBILITY STUDY AND BROADBAND RECOMMENDATIONS Dunedin City Council, 24th January 2007 (emphasis added) -- -- Tel: 03 474 2100 Cell: 021 993 125 Web: www.wic.co.nz Co-location and Web hosting. Dunedin-wide wireless. Independent Internet Service Provider.

2 1

Hungry backhoes in Porirua
by Jonathan Brewer 02 Apr '07

02 Apr '07

Hi Folks, One of the T's suffered fibre cut in Porirua this morning, causing some local tail circuts to disappear. Cheers, Jon

2 1

Telecom's "peering" change of heart really isn't
by Matthew Poole 01 Apr '07

01 Apr '07

http://computerworld.co.nz/news.nsf/news/EA57668828E0FEEFCC2572AC0070D766 "While emphasing that it's still early days for the proposal and details need to be worked out, Marshall says providers would pay for circuits into Telecom's network, and the incumbent would reciprocate for connections towards providers." How is this an improvement on the current situation? They're not making use of existing peering infrastructure, they're just making other providers pay for a (Telecom-supplied) connection into Telecom's network, which is an option that's always been available to anyone willing to spend the money. Here's hoping that they get told that anything less than true neutral peering isn't good enough. -- Matthew Poole "Don't use force. Get a bigger hammer."

7 10

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

01 Apr '07

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: WIX peering at '202.7.0.32' descr: see Citylink RT job #7338 admin-c: RPA1-NZRR tech-c: RPA1-NZRR import: from AS9560 accept ANY AND NOT fltr-bogons export: to AS9560 announce AS23754 import: from AS9439 accept ANY AND NOT fltr-bogons export: to AS9439 announce AS23754 import: from AS24385 accept ANY AND NOT fltr-bogons export: to AS24385 announce AS23754 import: from AS7657 accept {0.0.0.0/0} export: to AS7657 announce AS23754 import: from AS9439 accept ANY AND NOT fltr-bogons export: to AS9439 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 20061122 source: NZRR REPLACED BY: aut-num: AS23754 as-name: NZRR-AS23754 descr: CityLink descr: WIX peering at '202.7.0.32' descr: see Citylink RT job #7338 descr: WIX peering at '202.7.0.34' descr: see Citylink RT job #6072 admin-c: RPA1-NZRR tech-c: RPA1-NZRR import: from AS9560 accept ANY AND NOT fltr-bogons export: to AS9560 announce AS23754 import: from AS9439 accept ANY AND NOT fltr-bogons export: to AS9439 announce AS23754 import: from AS24385 accept ANY AND NOT fltr-bogons export: to AS24385 announce AS23754 import: from AS7657 accept {0.0.0.0/0} export: to AS7657 announce AS23754 import: from AS9439 accept ANY AND NOT fltr-bogons export: to AS9439 announce AS23754 import: from AS9439 accept ANY AND NOT fltr-bogons export: to AS9439 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 20070402 source: NZRR --- PREVIOUS OBJECT: route-set: AS9439:RS-ROUTES:AS23754 descr: advertised to AS9439 by CityLink - AS23754 members: 198.48.0.0/22^22-29, 202.8.44.0/22^22-29, 202.7.6.0/23^23-29, 97.64.46.0/24^24-29, 198.32.71.0/24^24-29, 202.7.5.0/24^24-29, 203.118.144.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: rpsl-admin(a)nzix.net mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20061214 source: NZRR REPLACED BY: route-set: AS9439:RS-ROUTES:AS23754 descr: Route set advertised to AS9439 by Cafenet CHC - AS23754 members: 198.48.3.64/28^28-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: simon(a)citylink.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20070402 source: NZRR

1 0

Google Launches new in home fibre optic service
by Dan Clark 01 Apr '07

01 Apr '07

You guys aren't gonna believe this, actually to be honest I dont really believe it either... http://www.google.com/tisp/ Regards Dan

8 9

Clarification on AUT's connection
by Ian Batterbee 01 Apr '07

01 Apr '07

Trust techo types to actually verify what I said... As a couple of people have now pointed out, AUT's prefix of 156.62.0.0/16 is not currently being advertised through Orcon (however you will find it through TCL and KAREN). This is a temporary situation and shouldn't be considered 'normal'. --- Ian Batterbee, CCNP Senior Network Technician Auckland University of Technology

1 0

Re: [nznog] Telecom's "peering" change of heart really isn't
by Stewart Fleming 30 Mar '07

30 Mar '07

> > >Oh, and on your point about universities, I think you will find that most >(all?) of them already peer. UoA, which is far-and-away the largest university >in the country, certainly peers at APE. > Help me out here. What incentives can I (as operator of a local exchange) now offer to a University to convince it that peering locally is a Good Idea when they have KAREN? At various times, I've offered the University Of Eastern Venezuela (*) peering for a) $XXX/monthly (**), and b) the cost of a piece of patch cord, so far without takers. I think I might have to pay them before the chicken/egg dichotomy gets resolved ("We'll peer if everyone else does"; Everyone Else says "We'll peer if they do".)... (*) Name changed to protect the innocent. (**) Amount obscured, but the number of digits is right.

5 5

Notification of NZRR Database changes
by NZRR Database Notifications 29 Mar '07

29 Mar '07

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:AS24324 descr: advertised to AS9560 by Kordia (former BCL) - AS24324 members: 124.157.64.0/19^19-29, 202.68.80.0/20^20-29, 202.20.0.0/21^21-29, 202.49.16.0/21^21-29, 202.49.128.0/21^21-29, 218.185.224.0/21^21-29, 202.27.88.0/23^23-29, 192.173.17.0/24^24-29, 202.27.83.0/24^24-29, 202.27.90.0/24^24-29, 202.36.75.0/24^24-29, 202.36.137.0/24^24-29, 202.36.154.0/24^24-29, 202.36.173.0/24^24-29, 202.37.168.0/24^24-29, 202.37.197.0/24^24-29, 202.49.106.0/24^24-29, 202.49.158.0/24^24-29, 202.49.183.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: smc(a)kordia.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20061214 source: NZRR REPLACED BY: route-set: AS9560:RS-ROUTES:AS24324 descr: advertised to AS9560 by Kordia - AS24324 members: 124.157.64.0/19^19-29, 202.68.80.0/20^20-29, 202.20.0.0/21^21-29, 202.49.16.0/21^21-29, 202.49.128.0/21^21-29, 218.185.224.0/21^21-29, 202.27.88.0/23^23-29, 192.173.17.0/24^24-29, 202.27.83.0/24^24-29, 202.27.90.0/24^24-29, 202.36.75.0/24^24-29, 202.36.137.0/24^24-29, 202.36.154.0/24^24-29, 202.36.173.0/24^24-29, 202.37.168.0/24^24-29, 202.37.197.0/24^24-29, 202.49.158.0/24^24-29, 202.49.183.0/24^24-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: smc(a)kordia.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20070330 source: NZRR --- PREVIOUS OBJECT: route-set: AS9560:RS-ROUTES:AS7657 descr: advertised to AS9560 by Ihug Ltd - AS7657 members: 121.90.0.0/16^16-29, 124.168.0.0/16^16-29, 203.59.0.0/16^16-29, 203.173.128.0/17^17-29, 203.206.0.0/17^17-29, 203.214.0.0/17^17-29, 202.129.64.0/18^18-29, 210.84.0.0/18^18-29, 124.6.192.0/19^19-29, 202.161.0.0/19^19-29, 203.158.32.0/19^19-29, 203.166.224.0/19^19-29, 203.173.0.0/19^19-29, 203.206.128.0/19^19-29, 203.214.128.0/19^19-29, 203.217.32.0/19^19-29, 203.217.64.0/19^19-29, 202.46.160.0/20^20-29, 202.73.192.0/20^20-29, 203.173.32.0/20^20-29, 203.190.192.0/20^20-29, 202.49.64.0/21^21-29, 202.126.80.0/21^21-29, 203.173.48.0/21^21-29, 203.206.168.0/21^21-29, 203.206.176.0/21^21-29, 203.215.0.0/21^21-29, 203.217.0.0/21^21-29, 203.217.16.0/21^21-29, 210.55.248.0/21^21-29, 202.49.240.0/22^22-29, 203.14.168.0/22^22-29, 203.55.228.0/22^22-29, 203.57.140.0/22^22-29, 203.62.212.0/22^22-29, 203.173.56.0/22^22-29, 203.206.164.0/22^22-29, 203.206.184.0/22^22-29, 203.206.192.0/22^22-29, 203.206.204.0/22^22-29, 203.206.220.0/22^22-29, 203.215.8.0/22^22-29, 203.217.12.0/22^22-29, 203.217.28.0/22^22-29, 202.36.94.0/23^23-29, 202.36.230.0/23^23-29, 202.49.88.0/23^23-29, 202.49.176.0/23^23-29, 202.49.180.0/23^23-29, 202.128.110.0/23^23-29, 203.7.196.0/23^23-29, 203.8.92.0/23^23-29, 203.14.174.0/23^23-29, 203.17.62.0/23^23-29, 203.21.74.0/23^23-29, 203.29.86.0/23^23-29, 203.55.140.0/23^23-29, 203.56.30.0/23^23-29, 203.56.62.0/23^23-29, 203.57.10.0/23^23-29, 203.57.136.0/23^23-29, 203.173.60.0/23^23-29, 203.206.162.0/23^23-29, 203.206.188.0/23^23-29, 203.206.202.0/23^23-29, 203.206.208.0/23^23-29, 203.206.218.0/23^23-29, 203.215.18.0/23^23-29, 203.215.20.0/23^23-29, 203.217.10.0/23^23-29, 210.55.202.0/23^23-29, 97.64.46.0/24^24-29, 192.107.113.0/24^24-29, 192.188.107.0/24^24-29, 198.32.71.0/24^24-29, 202.7.6.0/24^24-29, 202.8.47.0/24^24-29, 202.12.87.0/24^24-29, 202.21.130.0/24^24-29, 202.36.44.0/24^24-29, 202.36.46.0/24^24-29, 202.36.174.0/24^24-29, 202.37.136.0/24^24-29, 202.37.182.0/24^24-29, 202.49.33.0/24^24-29, 202.49.59.0/24^24-29, 202.49.63.0/24^24-29, 202.49.140.0/24^24-29, 202.49.144.0/24^24-29, 202.49.178.0/24^24-29, 202.49.186.0/24^24-29, 202.49.249.0/24^24-29, 202.50.84.0/24^24-29, 202.50.103.0/24^24-29, 202.50.255.0/24^24-29, 202.128.109.0/24^24-29, 202.169.97.0/24^24-29, 202.176.0.0/24^24-29, 203.0.12.0/24^24-29, 203.0.84.0/24^24-29, 203.0.139.0/24^24-29, 203.0.178.0/24^24-29, 203.1.24.0/24^24-29, 203.1.78.0/24^24-29, 203.2.199.0/24^24-29, 203.3.127.0/24^24-29, 203.4.173.0/24^24-29, 203.5.184.0/24^24-29, 203.7.155.0/24^24-29, 203.7.173.0/24^24-29, 203.8.161.0/24^24-29, 203.8.219.0/24^24-29, 203.12.1.0/24^24-29, 203.12.15.0/24^24-29, 203.12.44.0/24^24-29, 203.12.236.0/24^24-29, 203.14.172.0/24^24-29, 203.14.182.0/24^24-29, 203.15.111.0/24^24-29, 203.15.129.0/24^24-29, 203.16.34.0/24^24-29, 203.17.60.0/24^24-29, 203.17.194.0/24^24-29, 203.17.249.0/24^24-29, 203.17.251.0/24^24-29, 203.18.85.0/24^24-29, 203.18.140.0/24^24-29, 203.19.70.0/24^24-29, 203.20.82.0/24^24-29, 203.20.88.0/24^24-29, 203.20.116.0/24^24-29, 203.20.132.0/24^24-29, 203.21.5.0/24^24-29, 203.21.105.0/24^24-29, 203.22.19.0/24^24-29, 203.22.96.0/24^24-29, 203.23.7.0/24^24-29, 203.24.50.0/24^24-29, 203.24.189.0/24^24-29, 203.25.109.0/24^24-29, 203.25.144.0/24^24-29, 203.25.197.0/24^24-29, 203.26.32.0/24^24-29, 203.26.86.0/24^24-29, 203.26.92.0/24^24-29, 203.26.128.0/24^24-29, 203.27.58.0/24^24-29, 203.27.60.0/24^24-29, 203.27.89.0/24^24-29, 203.27.201.0/24^24-29, 203.28.157.0/24^24-29, 203.28.174.0/24^24-29, 203.29.221.0/24^24-29, 203.30.181.0/24^24-29, 203.30.194.0/24^24-29, 203.31.13.0/24^24-29, 203.31.96.0/24^24-29, 203.31.141.0/24^24-29, 203.34.95.0/24^24-29, 203.55.151.0/24^24-29, 203.56.243.0/24^24-29, 203.57.134.0/24^24-29, 203.61.76.0/24^24-29, 203.102.166.0/24^24-29, 203.108.77.0/24^24-29, 203.112.114.0/24^24-29, 203.118.136.0/24^24-29, 203.173.63.0/24^24-29, 203.206.161.0/24^24-29, 203.206.190.0/24^24-29, 203.206.196.0/24^24-29, 203.206.198.0/24^24-29, 203.206.201.0/24^24-29, 203.206.213.0/24^24-29, 203.206.214.0/24^24-29, 203.206.217.0/24^24-29, 203.215.12.0/24^24-29, 203.215.17.0/24^24-29, 203.215.31.0/24^24-29, 210.8.138.0/24^24-29, 210.55.110.0/24^24-29, 210.55.184.0/24^24-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: noc(a)ihug.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20070322 source: NZRR REPLACED BY: route-set: AS9560:RS-ROUTES:AS7657 descr: advertised to AS9560 by Ihug Ltd - AS7657 members: 121.90.0.0/16^16-29, 124.168.0.0/16^16-29, 203.59.0.0/16^16-29, 203.109.128.0/17^17-29, 203.173.128.0/17^17-29, 203.206.0.0/17^17-29, 203.214.0.0/17^17-29, 202.129.64.0/18^18-29, 203.118.128.0/18^18-29, 210.84.0.0/18^18-29, 124.6.192.0/19^19-29, 202.161.0.0/19^19-29, 203.96.192.0/19^19-29, 203.158.32.0/19^19-29, 203.166.224.0/19^19-29, 203.173.0.0/19^19-29, 203.206.128.0/19^19-29, 203.214.128.0/19^19-29, 203.217.32.0/19^19-29, 203.217.64.0/19^19-29, 202.46.160.0/20^20-29, 202.73.192.0/20^20-29, 203.173.32.0/20^20-29, 203.190.192.0/20^20-29, 202.36.16.0/21^21-29, 202.49.64.0/21^21-29, 202.126.80.0/21^21-29, 203.173.48.0/21^21-29, 203.206.168.0/21^21-29, 203.206.176.0/21^21-29, 203.215.0.0/21^21-29, 203.217.0.0/21^21-29, 203.217.16.0/21^21-29, 210.4.208.0/21^21-29, 210.55.248.0/21^21-29, 198.48.0.0/22^22-29, 202.8.44.0/22^22-29, 202.36.24.0/22^22-29, 202.49.240.0/22^22-29, 202.50.188.0/22^22-29, 203.14.168.0/22^22-29, 203.55.228.0/22^22-29, 203.57.140.0/22^22-29, 203.62.212.0/22^22-29, 203.173.56.0/22^22-29, 203.206.164.0/22^22-29, 203.206.184.0/22^22-29, 203.206.192.0/22^22-29, 203.206.204.0/22^22-29, 203.206.220.0/22^22-29, 203.215.8.0/22^22-29, 203.217.12.0/22^22-29, 203.217.28.0/22^22-29, 202.21.136.0/23^23-29, 202.36.94.0/23^23-29, 202.36.230.0/23^23-29, 202.49.46.0/23^23-29, 202.49.88.0/23^23-29, 202.49.148.0/23^23-29, 202.49.176.0/23^23-29, 202.49.180.0/23^23-29, 202.61.2.0/23^23-29, 202.128.110.0/23^23-29, 203.7.196.0/23^23-29, 203.8.92.0/23^23-29, 203.14.174.0/23^23-29, 203.17.62.0/23^23-29, 203.21.74.0/23^23-29, 203.29.86.0/23^23-29, 203.55.140.0/23^23-29, 203.56.30.0/23^23-29, 203.56.62.0/23^23-29, 203.57.10.0/23^23-29, 203.57.136.0/23^23-29, 203.173.60.0/23^23-29, 203.206.162.0/23^23-29, 203.206.188.0/23^23-29, 203.206.202.0/23^23-29, 203.206.208.0/23^23-29, 203.206.218.0/23^23-29, 203.215.14.0/23^23-29, 203.215.18.0/23^23-29, 203.215.20.0/23^23-29, 203.217.10.0/23^23-29, 210.55.202.0/23^23-29, 97.64.46.0/24^24-29, 192.107.113.0/24^24-29, 192.188.107.0/24^24-29, 192.190.108.0/24^24-29, 198.32.71.0/24^24-29, 202.7.6.0/24^24-29, 202.12.87.0/24^24-29, 202.21.130.0/24^24-29, 202.36.44.0/24^24-29, 202.36.46.0/24^24-29, 202.36.174.0/24^24-29, 202.37.136.0/24^24-29, 202.37.182.0/24^24-29, 202.49.33.0/24^24-29, 202.49.59.0/24^24-29, 202.49.63.0/24^24-29, 202.49.140.0/24^24-29, 202.49.144.0/24^24-29, 202.49.178.0/24^24-29, 202.49.186.0/24^24-29, 202.49.249.0/24^24-29, 202.50.84.0/24^24-29, 202.50.103.0/24^24-29, 202.50.255.0/24^24-29, 202.128.109.0/24^24-29, 202.169.97.0/24^24-29, 202.176.0.0/24^24-29, 203.0.12.0/24^24-29, 203.0.84.0/24^24-29, 203.0.139.0/24^24-29, 203.0.178.0/24^24-29, 203.1.24.0/24^24-29, 203.1.78.0/24^24-29, 203.2.199.0/24^24-29, 203.3.127.0/24^24-29, 203.4.173.0/24^24-29, 203.5.184.0/24^24-29, 203.7.155.0/24^24-29, 203.7.173.0/24^24-29, 203.8.161.0/24^24-29, 203.8.219.0/24^24-29, 203.12.1.0/24^24-29, 203.12.15.0/24^24-29, 203.12.44.0/24^24-29, 203.12.236.0/24^24-29, 203.14.172.0/24^24-29, 203.14.182.0/24^24-29, 203.15.111.0/24^24-29, 203.15.129.0/24^24-29, 203.16.34.0/24^24-29, 203.17.60.0/24^24-29, 203.17.194.0/24^24-29, 203.17.249.0/24^24-29, 203.17.251.0/24^24-29, 203.18.85.0/24^24-29, 203.18.140.0/24^24-29, 203.19.70.0/24^24-29, 203.20.82.0/24^24-29, 203.20.88.0/24^24-29, 203.20.116.0/24^24-29, 203.20.132.0/24^24-29, 203.21.5.0/24^24-29, 203.21.105.0/24^24-29, 203.22.19.0/24^24-29, 203.22.96.0/24^24-29, 203.23.7.0/24^24-29, 203.24.50.0/24^24-29, 203.24.189.0/24^24-29, 203.25.109.0/24^24-29, 203.25.144.0/24^24-29, 203.25.197.0/24^24-29, 203.26.32.0/24^24-29, 203.26.86.0/24^24-29, 203.26.92.0/24^24-29, 203.26.128.0/24^24-29, 203.27.58.0/24^24-29, 203.27.60.0/24^24-29, 203.27.89.0/24^24-29, 203.27.201.0/24^24-29, 203.28.157.0/24^24-29, 203.28.174.0/24^24-29, 203.29.221.0/24^24-29, 203.30.181.0/24^24-29, 203.30.194.0/24^24-29, 203.31.13.0/24^24-29, 203.31.96.0/24^24-29, 203.31.141.0/24^24-29, 203.34.95.0/24^24-29, 203.55.151.0/24^24-29, 203.56.243.0/24^24-29, 203.57.134.0/24^24-29, 203.61.76.0/24^24-29, 203.102.166.0/24^24-29, 203.108.77.0/24^24-29, 203.112.114.0/24^24-29, 203.173.63.0/24^24-29, 203.206.161.0/24^24-29, 203.206.190.0/24^24-29, 203.206.196.0/24^24-29, 203.206.198.0/24^24-29, 203.206.201.0/24^24-29, 203.206.213.0/24^24-29, 203.206.214.0/24^24-29, 203.206.217.0/24^24-29, 203.215.12.0/24^24-29, 203.215.17.0/24^24-29, 203.215.31.0/24^24-29, 210.8.138.0/24^24-29, 210.55.110.0/24^24-29, 210.55.184.0/24^24-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: noc(a)ihug.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20070330 source: NZRR

1 0

Notification of NZRR Database changes
by NZRR Database Notifications 29 Mar '07

29 Mar '07

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

1 0

5.8GHz in Dunedin
by Stewart Fleming 29 Mar '07

29 Mar '07

We're trying to track down a potential interference problem that is affecting one of our access points in North Dunedin. Could any local operator using Trango or Motorola 5.8GHz gear in that area please contact me off-list? Thanks. -- -- Tel: 03 474 2100 Cell: 021 993 125 Web: www.wic.co.nz Co-location and Web hosting. Dunedin-wide wireless. Independent Internet Service Provider.

1 0

Re: [nznog] Telecom's "peering" change of heart really isn't
by Alastair Johnson 28 Mar '07

28 Mar '07

[once more for good luck - maybe THIS time I'll get it on list] Matthew Poole wrote: > > On Thu, 29 Mar 2007, Alastair Johnson wrote: > >> Every ISP at Every IX? Does it end at ISPs? What about universities, >> for instance? What about satellite networks where the uplink isn't >> necessarily NZ based? >> > At their local (to their primary centre of operations) IX, obviously. > And I'm envisaging xx,000 being a sufficiently high number that only the > University of Auckland (with around 40,000 FTE students) would even come > close. Okay, but if you're only interconnecting/exchanging at your local IX then suddenly this is not as useful as it sounded. Telecom's primary center of operations is indisputably Auckland. Does that mean that, e.g. Trademe, cannot reach TNZ across an IX? Or do we come back to region-isation again? >> Are you going to pay for my long haul circuits to Palmy? >> > Is your primary centre of operations in Palmy? No? Why would you peer in > Palmy, then? Because you're regulating peering. If we must peer, then surely everyone needs to peer either everywhere (expensive), or at one IX (expensive for some). Otherwise you're significantly reducing the benefit of it before you even start. What happens if my POPs are islands and not connected to my backbone[s]? (think internap PNAPs) I'm only going to originate local prefixes anyway. What if I don't want to haul Content Provider C's traffic from Palmy to my subscribers in Auckland because it's 50+Mbps? Third option: regional based peering. My POP in PMR peers at the PNIX and only originates local prefixes. These all sound like significant business and technical issues that would need to be addressed by regulation. Unless your idea of regulation is to just focus on the big boys. Maybe that's fair, maybe that's not.... >> Doesn't sound like it would work so well, to me. If we said only the >> "major" IXs, what happens when the poor guy in Christchurch signs up his >> XX,000th customer and is forced to peer... but isn't getting access to >> the Big Boys? >> > Realistically, how many ISPs that are based outside AKL/WLG stand any > chance of getting 50+,000 users? Remembering that of the top five, > unless something has changed a lot in recent times, only Xtra and the > TCL stable are > 100k. If the government is serious about our OECD rankings, then I think many ISPs are going to hit >50k. If you believe press releases, Ihug, Orcon, and Callplus are all around (or over) the 100k mark. >> Regulated peering sounds very scary to me... >> > Only if one takes it to absurdity. If it's regulated in such a way that > only the very largest players could be affected, and the requirement on > which IX(s) is based around centre(s) of operations, it's easily > defined, easily enforced, and as I said won't really affect anyone other > than TCL and TCNZ. Which one may state is not particularly fair. Incidentally, what about Vodafone? I've noticed that traffic from a large number of smaller providers currently trombones via Tokyo and Sydney. > Oh, and on your point about universities, I think you will find that > most (all?) of them already peer. UoA, which is far-and-away the largest > university in the country, certainly peers at APE. I think you'll find that UoA in particular does not peer [any longer]. UoW also does not. aj.

2 1

Re: [nznog] jumbo frames
by Jonathan Woolley 28 Mar '07

28 Mar '07

>Jumbo frames aside from the usefulness of bigger payload for >mpls/tunnels etc add some value in an environment where there's some >packet loss. I would have thought it makes it worse, assuming a physical fault resulting in a constant bit error rate combined with larger packet size means higher probability that a packet is corrupted (as there are more bits in it). The resulting packet is discarded which is a bigger loss than discarding a smaller one. >For example in an environment with say a 1Gbps link where packet loss >is .1% with 1500 byte MTU you get 28Mbps througput. With Jumboframes >that leaps to approx 162Mbps. Can I see the maths behind this? If you're talking about packet loss due to congestion and not using TCP then you're probably right

11 13

Re: [nznog] Telecom's "peering" change of heart really isn't
by Matthew Poole 28 Mar '07

28 Mar '07

On Thu, 29 Mar 2007, Alastair Johnson wrote: > Every ISP at Every IX? Does it end at ISPs? What about universities, > for instance? What about satellite networks where the uplink isn't > necessarily NZ based? > At their local (to their primary centre of operations) IX, obviously. And I'm envisaging xx,000 being a sufficiently high number that only the University of Auckland (with around 40,000 FTE students) would even come close. > Are you going to pay for my long haul circuits to Palmy? > Is your primary centre of operations in Palmy? No? Why would you peer in Palmy, then? > Doesn't sound like it would work so well, to me. If we said only the > "major" IXs, what happens when the poor guy in Christchurch signs up his > XX,000th customer and is forced to peer... but isn't getting access to > the Big Boys? > Realistically, how many ISPs that are based outside AKL/WLG stand any chance of getting 50+,000 users? Remembering that of the top five, unless something has changed a lot in recent times, only Xtra and the TCL stable are > 100k. > Regulated peering sounds very scary to me... > Only if one takes it to absurdity. If it's regulated in such a way that only the very largest players could be affected, and the requirement on which IX(s) is based around centre(s) of operations, it's easily defined, easily enforced, and as I said won't really affect anyone other than TCL and TCNZ. Oh, and on your point about universities, I think you will find that most (all?) of them already peer. UoA, which is far-and-away the largest university in the country, certainly peers at APE. -- Matthew Poole "Don't use force. Get a bigger hammer."

1 0

jumbo frames
by Ian Batterbee 27 Mar '07

27 Mar '07

Has anyone got any real world experience of the usefulness of jumbo frames on ethernet (ie, MTU > 1500 bytes). A number of 1000mbps interfaces support it, but it seems to be that it would only be useful if jumbo frames were supported and enabled on all equipment between the sending NIC and final IP destination, so I'm struggling to see how enabling it in just say the core of a network would be all that helpful.

8 7

John Backus passes away
by Richard Naylor 27 Mar '07

27 Mar '07

For those who are a little older.... John Backus, who lead the team that developed FORTRAN passed away last week. FORTRAN was originally developed for the IBM 704 and is regarded as one of the first high-level programming languages. He was involved in the development of ALGOL 58 and ALGOL 60. ALGOL was the first language that I learned, FORTRAN the second. Theres a good obit at NYTimes http://www.nytimes.com/2007/03/19/obituaries/20cnd-backus.html?ex=133204320… Its worth reading. Slashdot also has heaps, including.... FORTRAN was the first working high level compiler language; BASIC was the first working interpreter language. Very different underlying structures. Now COBOL was the second major high level compiler language, and it was very much a reaction to FORTRAN, so I suppose using parent post's logic, we can blame Backus for COBOL. But then that cheapens the contributions of the Girl Admiral (Grace Hopper) who gave us such wonders as the nanosecond wire, and MULTIPLY 2 BY 2 GIVING FOUR. For the youngsters out there: FORTRAN (FORmula TRANslator) was the break-through from machine language and assembly to a higher level language with a compiler. Everything we do now is based on this; I believe that many mission critical engineering libraries are still in Fortran (they were a few years ago) COBOL (COmmon Business Oriented Language, Compiles Only By Odd Luck) was the second successful high level language. Its major improvement over Fortran was getting rid of triphasic logic (branch on <0, or =0, or >0) in favor of boolean logic (branch on !0 or 0). Its most noteworthy failing was the requirement to use the period punctuation mark (full stop) to end sections. This was particularly a problem for girl programmers, since at the time getting into trouble because you missed a period had serious consequences. Cobol simply put too much emphasis on a nearly invisible and easily missed period. BASIC (Beginners All-purpose Symbolic Instruction Code) made two big advances: first, it attempted to span both engineering and business computing (doing each with the same degree of imprecision); second and more important, it introduced the concept of using an interpreter rather than a compiler. Good stuff, that. Yet another baby step toward tomorrow's virtual machines. Most noteworthy program ever written in Basic: Eliza. Most significant long term contribution: the reaction to its spaghetti coding style, from which Pascal and modern procedure based programming arose. </drivel> Rich off for a scotch and to read a few punched cards......

2 1

92/8, 93/8 allocated to the RIPE NCC
by Leo Vegoda 27 Mar '07

27 Mar '07

Hi, The IANA IPv4 registry has been updated to reflect the allocation of two /8 IPv4 blocks to the RIPE NCC in March 2007: 92/8 and 93/8. You can find the IANA IPv4 registry at: http://www.iana.org/assignments/ipv4-address-space Please update your filters as appropriate. Regards, -- Leo Vegoda IANA Numbers Liaison

1 0

Re: [nznog] jumbo frames
by Jonathan Woolley 27 Mar '07

27 Mar '07

>>> Can I see the maths behind this? If you're talking about packet >loss >>> due to congestion and not using TCP then you're probably right >> >>I assume he's talking about my TFRC math from >>http://wand.net.nz/~perry/max_download.php >> >>Assuming you've saturated your link, a one bit in 'n' is going to >take >>out one packet every so often (if it takes out more than that you're >not >>going to get anything much worth discussing over your link in the >first >>place). So increasing the MTU isn't going to make it more likely >that a >>packet is lost, it just means you need to retransmit a larger >packet. >> >>However, since you're using larger MTU's, it's going to take you >less >>RTT's to get back up to full speed on your link, and therefore your >link >>will spend more of its time going at full rate than if you had a >lower >>MTU (since it would require more RTT's at lower throughput before it > >>starts saturating the link again). Ahh, ok. That's an interesting scenario. I'll have a look at the link Jono

1 0

Re: [nznog] jumbo frames
by Jonathan Woolley 27 Mar '07

27 Mar '07

>>If you're fragmenting and drop one packet of a 4-packet-sequence you >waste >>the other 3 packets anyway as its gotta send the whole oversize >packet as >>multiple fragments all over again. My guess is that is his >reasoning - >>and seems fair... Sending a 9600byte packet in one frame, or fragmented into seven frames isn't really a meaningful test if you're trying to prove that jumbo frames are better when there is packet loss. In the real world, the non-jumbo frame setup would only send 1500 byte packets...

1 0

Re: [nznog] jumbo frames
by Jonathan Woolley 27 Mar '07

27 Mar '07

So the most common real world example in NZ is UBS. Take the subscriber's 1500byte packet, add a PPP header, an extra IP and UDP header (for L2TP) and two MPLS headers (inside TNZ's netowrk) and jumbo frames look pretty useful. As alluded to below, 802.1q and especially stacking of vlans are strong reasons, even more so if transported over MPLS (Martini/VPLS). Jono > > > >---- Original Message ---- >From: nznog(a)daork.net >To: NZNOG(a)list.waikato.ac.nz >Subject: Re: [nznog] jumbo frames >Date: Wed, 28 Mar 2007 15:04:56 +1200 > >>MPLS. >>VLANs. >>L2TP with 1500byte payloads. >> >>etc. >> >>On 28/03/2007, at 3:01 PM, Ian Batterbee wrote: >> >>> Has anyone got any real world experience of the usefulness of >jumbo >>> frames on ethernet (ie, MTU > 1500 bytes). A number of 1000mbps >>> interfaces support it, but it seems to be that it would only be >useful >>> if jumbo frames were supported and enabled on all equipment >between >>> the >>> sending NIC and final IP destination, so I'm struggling to see how >>> enabling it in just say the core of a network would be all that >>> helpful. >>> >>> >>> >>> _______________________________________________ >>> NZNOG mailing list >>> NZNOG(a)list.waikato.ac.nz >>> http://list.waikato.ac.nz/mailman/listinfo/nznog >>> >>> !DSPAM:22,4609daac107231355811551! >>> >>> >> >>_______________________________________________ >>NZNOG mailing list >>NZNOG(a)list.waikato.ac.nz >>http://list.waikato.ac.nz/mailman/listinfo/nznog

2 1

Notification of NZRR Database changes
by NZRR Database Notifications 27 Mar '07

27 Mar '07

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

1 0

Notification of NZRR Database changes
by NZRR Database Notifications 25 Mar '07

25 Mar '07

Dear Colleague, This is to notify you that some object(s) in NZRR database which you either maintain or are listed as to-be-notified have been added, deleted or changed. These objects are used to configure the various NZIX route servers (http://nzix.net/) so you can expect the relevant servers to be reloaded in the near future. The reloading of the servers is staggered over a period of time so that if you are peering with both servers at an exchange, you can maintain at least one BGP session at all times and consequently a full set of routes. --- PREVIOUS OBJECT: route-set: AS9439:RS-ROUTES:AS38292 descr: advertised to AS9439 by ZeroOne (NZ) Limited - AS38292 members: 202.174.6.0/23^23-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: noc(a)zeroone.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20070214 source: NZRR REPLACED BY: route-set: AS9439:RS-ROUTES:AS38292 descr: advertised to AS9439 by ZeroOne (NZ) Limited - AS38292 members: 202.174.6.0/23^23-29, 203.152.104.104/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)zeroone.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20070326 source: NZRR

1 0

Xtra accepting ping
by Michael Fincham 24 Mar '07

24 Mar '07

Is it just me, or did some of Xtra's servers (specifically alien.xtra.co.nz/www.xtra.co.nz but probably more) suddenly stop replying to echo requests at some point this afternoon? Certainly had me stumped/panicking when my traceroute died at the penultimate hop... -- --Michael Fincham Unleash Technology Solutions

1 0

The wacky, weird world of not peering
by Philip D'Ath 21 Mar '07

21 Mar '07

http://computerworld.co.nz/news.nsf/news/60FED800168312AECC2572A0001A299 7 ... Thankfully we have heard that Telecom is reconsidering its approach and we say it is about time. With continued data growth, IP-based voice and video becoming widespread, and an increasing number of networks being developed, it is critical that local data is kept local and the most efficient paths across the network are utilised. Telecom has recently been reported in the media as saying it is seriously looking at and now supports the concept of local internet interconnection. Rumours abound of a June/July timetable. Of course for their customers, and TelstraClear's, one would expect they never stopped local interconnection, but this move would re-integrate Telecom with the rest of the internet at a local level. ...

7 8

Notification of NZRR Database changes
by NZRR Database Notifications 21 Mar '07

21 Mar '07

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

1 0

DNS TTLs: trademe and anz
by Simon Lyall 18 Mar '07

18 Mar '07

I'm doing a bit of DNS testing and I start noticing some weird results for a few domains. The two below appear to be specific problems since they are popular and I noticed them but I suspect there are others. The problem is that www.anz.co.nz and www.anz.com have TTLs of zero seconds. This means that *every* DNS look up for them takes either around 40 or 140ms (one server is closer/quicker than the other) since it is never cached. Similarly the TTL for www.trademe.co.nz (and www.oldfriends.co.nz) is just ten seconds so this must be constantly rechecked. Not as bad since their servers are in NZ but still there is a delay. Some companies (like google or yahoo) have very sophisticated systems that constantly check user performance and switch them from datacenter to datacenter in seconds if things start going slow. However unless your company has such a system (and very reliable and nearly DNS servers) then a TTL of a few minutes is good enough for manual updates to quickly propagate. Lower values than that will result in decreased performance for your customers. Even google and yahoo have TTLs of a minute or two. The scary thing is that both sites probably put a lot of time into making the actual pages load as fast as possible. -- Simon Lyall | Very Busy | Web: http://www.darkmere.gen.nz/ "To stay awake all night adds a day to your life" - Stilgar | eMT.

10 13

Call for Hosts: NZNOG 08
by Daniel Lawson 14 Mar '07

14 Mar '07

Call for Hosts: NZNOG 08 We are looking for potential hosts for NZNOG 06 in around a year's time. I would like to hear off-list from people who a) have been to at least one NZNOG conference in the past, and b) might be interested in hosting next year's conference. This is not about committing anybody to anything at this stage. It is a good time to start thinking about whether this is a way in which you could contribute to the community, whether as a single hosting organisation or in cooperation with others. I look forward to hearing from you before the 25th of March. Regards, Daniel Lawson NZNOG 08 Conference Organising Committee.

1 1

Re: [nznog] DNS TTLs: trademe and anz
by Ewen McNeill 12 Mar '07

12 Mar '07

In message <45F5DAA1.9070701(a)deanpemberton.com>, Dean Pemberton writes: >I can remember a time when a similar question was raised about zero time >TTLs on records. [...] It was with a bank. [...] >"We want to make sure that each and every request for an IP address >comes to our DNS server. We don't want it to be cached at all as this >can lead to someone hijacking the cache. We like it this way" So if someone _does_ manage to find a way to poison the cache with a record, then they can happily set a long TTL on the poison record and avoid any other lookups. And there's an almost zero chance that there'll be valid cached record there to prevent the poisoned one being cached. Seems to me some people don't think through the logical consequences of their actions. It also seems to me that anyone needing failover in less than about an hour wants a different solution than updating DNS entries (load balancer, anycast, etc). Ewen

5 7

Re: [nznog] ISP's Natting customer pools
by Martin Kealey 11 Mar '07

11 Mar '07

On 20-Feb-2007 Joe Abley wrote: > On 20-Feb-2007, at 17:16, Martin Kealey wrote: > > Question: are there any (DSL?) CPE units for sale or in development > > that will do v6 to v4 translation, plus v6 pass-thru? > > In practical terms (and I'm being only slightly pedantic) there *is* > no v6 to v4 translation. There are tunnels, and there is native IPv6. Are you saying that when a v6 host says "Connect to ::ffff:cfdb:2d24", the answer will invariably be "can't"? Otherwise we're talking about a third option that smells rather like SNAT, but running on steroids. Hence my using the term "translation". It makes sense for this "natting" to occur as far as possible from the v6 source host and as near as possible to the target v4 host, but in any case it can only go as far away as your v6 transit allows. Since we're only starting the game, that means the CPE border kit. Although I asked about doing both "translation and pass-thru", if the ISP at the other end is sensible it should only need to do one of those at a time. -Martin reference: http://xml.resource.org/public/rfc/html/rfc2373.html#anchor11

3 2

Domestic looking glass or traceroute
by Gerard Creamer 09 Mar '07

09 Mar '07

Hi, I'm looking for a New Zealand based looking glass that's on the Internet - so not the WIX or APE ones. The only one I've been able to find that goes is the ICONZ one at NZIX (http://nzix.net/cgi-bin/mrlg-others.cgi) although did also find Simon Lyall's one, which is currently offline, at http://www.usenet.net.nz/lg.cgi (AS7657). I have found a single working traceroute at http://www.kcbbs.gen.nz/cgi-bin/trace (AS9303). There are two others listed at traceroute.org, but neither is working. Is it just there there aren't many of these about, or are they just a well guarded secret? I found a few posts on the topic to this list in July last year (http://list.waikato.ac.nz/pipermail/nznog/2006-July/011929.html) but it didn't seem to go anywhere. If anyone knows of any others based in New Zealand (there are zillions elsewhere on the internet) I would greatly appreciate knowing where! Specifically I'm looking for traces from Orcon and Telecom / Xtra to 210.4.208.1, but the more data I can get to see why it seems that more traffic is coming in through our expensive upstream than we thought would the better :^) Cheers, Gerard

3 3

bind IPv6 configurator
by Matthew Poole 08 Mar '07

08 Mar '07

Does anyone know if there are any websites that will create a bind reverse zone file for a given IPv6 range? I can cope with creating the forward entries, but trying to work out the correct zone naming (not to mention the actual resource entries) for the reverse is more than my paw widdle bwain can cope with at present. -- Matthew Poole "Don't use force. Get a bigger hammer."

2 1

JABL announcement: dynablock & Spamhaus PBL
by Craig Whitmore 08 Mar '07

08 Mar '07

This came from the SPAM-L mailing list. If ppl are using RBL's on their mail servers they might want to read below. ------------------------------------------------------------------------- The following text was sent to list(a)njabl.org on Jan 19, 2007. Judging from the number of DNS queries still being handled for dynablock.njabl.org, the message doesn't seem to have made it to a wide enough audience. If you use or know people who use dynablock.njabl.org, this is important information: With the advent of Spamhaus's PBL (http://spamhaus.org/pbl/) dynablock.njabl.org has become obsolete. Rather than maintain separate similar DNSBL zones, NJABL will be working with Spamhaus on the PBL. Effective immediately, dynablock.njabl.org exists as a copy of the Spamhaus PBL. After dynablock users have had ample time to update their configurations, the dynablock.njabl.org zone will be emptied. Other NJABL zones (i.e. dnsbl, combined, bhnc, and the qw versions) will continue, business as usual, except that combined will eventually lose its dynablock component. If you currently use dynablock.njabl.org we recommend you switch immediately to pbl.spamhaus.org. If you currently use combined.njabl.org, we recommend you add pbl.spamhaus.org to the list of DNSBLs you use. You may also want to consider using zen.spamhaus.org, which is a combination zone consisting of Spamhaus's SBL, XBL, and PBL zones. ---------------- Thanks Craig

1 0

Re: [nznog] RFC822 (Identification of sender in email)
by Stoo Brighting 05 Mar '07

05 Mar '07

Hey, if you're going to quote me, at least quote me correctly. I didn't say it was unmonitored, we do monitor all bounces we get in order to process the NDR's (thousands each day) Like I said on the phone, our emails have completely valid envelope fields, and we update our database to "clean" out the bad email addresses that people often like to sign up with. This doesn't break any RFC that I know of. We'd just prefer that you don't reply to our CRM messages via SMTP, that's all - hence the "please do not reply to this" at the bottom of all our outbound emails, and the auto-responder if you do happen to send mail to these addresses. If this breaks an RFC, point me at the appropriate place, and I'll change things to fit them. As for being cocky, I can handle that, I've been called worse. Cheers, Stoo Misc small online company. -----Original Message----- From: John @ netTRUST [mailto:john(a)nettrust.net.nz] Sent: Tuesday, 6 March 2007 2:39 p.m. To: Craig Whitmore; nznog(a)list.waikato.ac.nz Subject: Re: [nznog] RFC822 (Identification of sender in email) I've just had a call from a rather cocky person at the company. They claim it is allright and common. I disagree, with the exception that it is common among spammers*. Hence why I'm asking other NZNOG members. Reply emails go to an auto responder which the company person says is unmonitored. This issue was bought to my attention when I wrote an email to this company, though as we handle (I estimate) several thousand emails per day from this company, I ahve decided to investigate the matter further. *I am in no way suggesting said company is a spammer, but we're under constant pressure from customers to increase the level of 'protection' and looking at their emails, they could quite possibly score a few bayes points. > > In investigating an issue involving a large online NZ company's outbound > > email - I read RFC822 which I have quoted below. > > > > I note that this company is currently making use of apparently > > unmonitored return addresses which generate an auto reply. > > Are you saying they are sending (MFROM) Addresses which don't exist (ie > cannot be bounced back to etc). Or MFROM a valid email address which no one > reads (ie noreply(a)XXXXX) > > Thanks > Craig _______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog

2 1

Re: [nznog] RFC822 (Identification of sender in email)
by John ＠ netTRUST 05 Mar '07

05 Mar '07

I've just had a call from a rather cocky person at the company. They claim it is allright and common. I disagree, with the exception that it is common among spammers*. Hence why I'm asking other NZNOG members. Reply emails go to an auto responder which the company person says is unmonitored. This issue was bought to my attention when I wrote an email to this company, though as we handle (I estimate) several thousand emails per day from this company, I ahve decided to investigate the matter further. *I am in no way suggesting said company is a spammer, but we're under constant pressure from customers to increase the level of 'protection' and looking at their emails, they could quite possibly score a few bayes points. > > In investigating an issue involving a large online NZ company's outbound > > email - I read RFC822 which I have quoted below. > > > > I note that this company is currently making use of apparently > > unmonitored return addresses which generate an auto reply. > > Are you saying they are sending (MFROM) Addresses which don't exist (ie > cannot be bounced back to etc). Or MFROM a valid email address which no one > reads (ie noreply(a)XXXXX) > > Thanks > Craig

2 1

RFC822 (Identification of sender in email)
by John ＠ netTRUST 05 Mar '07

05 Mar '07

Hello all- In investigating an issue involving a large online NZ company's outbound email - I read RFC822 which I have quoted below. I note that this company is currently making use of apparently unmonitored return addresses which generate an auto reply. Given that my reading of RFC822 would suggest this is contrary to this (and other relevant sections), and the obvious issues that this can cause for spam filtering mechanisms like TMDA, I would like to know whether others find this practice inappropriate, and if so, what action (if any) do they take against the perpetrators? Standard for ARPA Internet Text Messages Since the critical function served by the "Sender" field is identification of the agent responsible for sending mail and since computer programs cannot be held accountable for their behavior, it is strongly recommended that when a computer pro- gram generates a message, the HUMAN who is responsible for that program be referenced as part of the "Sender" field mail- box specification.

3 2

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

05 Mar '07

Dear Colleague, This is to notify you that some object(s) in NZRR database which you either maintain or are listed as to-be-notified have been added, deleted or changed. These objects are used to configure the various NZIX route servers (http://nzix.net/) so you can expect the relevant servers to be reloaded in the near future. The reloading of the servers is staggered over a period of time so that if you are peering with both servers at an exchange, you can maintain at least one BGP session at all times and consequently a full set of routes. --- PREVIOUS OBJECT: route-set: AS9439:RS-ROUTES:AS64597 descr: advertised to AS9439 by Araneo Limited - AS64597 members: 210.48.101.64/27^27-29, 210.48.109.224/27^27-29, 210.48.101.112/28^28-29, 210.48.101.240/28^28-29, 202.53.189.128/29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: info(a)araneo.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20060612 source: NZRR REPLACED BY: route-set: AS9439:RS-ROUTES:AS64597 descr: advertised to AS9439 by Araneo Limited - AS64597 members: 202.174.160.0/20^20-29, 210.48.101.64/27^27-29, 210.48.109.224/27^27-29, 210.48.101.112/28^28-29, 210.48.101.240/28^28-29, 202.53.189.128/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)araneo.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20070306 source: NZRR

1 0

APNIC membership fee discussion
by Elly Tawhai 27 Feb '07

27 Feb '07

Hi, I had some lively discussions about the APNIC membership fees with some of the attendees at the last NZnog in Hamilton. If you are an APNIC member, you may be interested in the APNIC fee discussions taking place at the APNIC 23 meeting in Bali this week. I encourage you all to have your say during the fee discussion working group sessions on Thursday and in the APNIC Member Meeting on Friday. Fee discussion sessions at APNIC 23: APNIC fees discussion Thursday 1 March 2007 9:00 - 12:30 (Bali time) http://www.apnic.net/meetings/23/programme/fees.html Fee discussions at the APNIC member meeting Friday 2 March 2007 14:15 - 15:30 (Bali time) http://www.apnic.net/meetings/23/programme/amm.html You can follow and participate in the fee discussions online via: - Jabber chat rooms - Live transcripts - Streaming video - Streaming audio Archives of the audio, video and transcripts will also be available soon after the fee discussion sessions have ended. For more information on how to participate online, go to: http://www.apnic.net/meetings/remote Kind regards, Elly APNIC

1 0

Remote participation in APNIC 23
by Elly Tawhai 26 Feb '07

26 Feb '07

Hi, You may be aware that APNIC 23 has started. You can participate remotely in discussions, ask the presenter questions, and voice your opinion. For more information on webcast, podcast, Jabber chat, and live transcript services please see: http://www.apnic.net/meetings/remote Some of the exciting topics being covered include: * Working group session to discuss a new membership fee structure * IPv4 count down proposal in the policy SIG * The EC election * Announcement of APNIC member survey results, and a review of the APNIC Secretariat new organisational structure * Review of the APNIC voting system For more information about the agenda please see: http://www.apnic.net/meetings/23/programme Kind regards, Elly APNIC

1 0

Notification of NZRR Database changes
by NZRR Database Notifications 25 Feb '07

25 Feb '07

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

1 0

Notification of NZRR Database changes
by NZRR Database Notifications 25 Feb '07

25 Feb '07

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

1 0

Fwd: Online voting open for APNIC Executive Council election
by Elly Tawhai 22 Feb '07

22 Feb '07

Apologies if you have already received this. Begin forwarded message: > From: secretariat(a)apnic.net > Date: 20 February 2007 6:01:47 PM > Subject: Online voting open for APNIC Executive Council election > > Dear colleagues > > Online voting for the APNIC Executive Council election is now open. > > where: https://my.apnic.net/voting > deadline: 9:00am UTC+8 (Bali time) on Wednesday 28 February 2007 > who: Only registered voting contacts may vote online > > Profiles of the candidates nominated for this election, along with > details for other voting methods are at: > > http://www.apnic.net/meetings/23/ec > > If you have any questions, please contact APNIC Secretariat at > helpdesk(a)apnic.net. > > > Regards, > > --------------------------------------------------------------------- > APNIC Secretariat email: secretariat(a)apnic.net > http://www.apnic.net sip: info(a)voip.apnic.net > phone: +61 7 3858 3100 > --------------------------------------------------------------------- > See you at APNIC 23! Bali, Indonesia, 26 February-2 March 2007 > http://www.apnic.net/meetings > --------------------------------------------------------------------- >

1 0

Notification of NZRR Database changes
by NZRR Database Notifications 20 Feb '07

20 Feb '07

Dear Colleague, This is to notify you that some object(s) in NZRR database which you either maintain or are listed as to-be-notified have been added, deleted or changed. These objects are used to configure the various NZIX route servers (http://nzix.net/) so you can expect the relevant servers to be reloaded in the near future. The reloading of the servers is staggered over a period of time so that if you are peering with both servers at an exchange, you can maintain at least one BGP session at all times and consequently a full set of routes. --- PREVIOUS OBJECT: route-set: AS9439:RS-ROUTES:AS4770 descr: advertised to AS9439 by ICONZ - AS4770 members: 131.203.0.0/16^16-29, 161.29.0.0/16^16-29, 161.65.0.0/16^16-29, 210.48.0.0/17^17-29, 210.185.0.0/18^18-29, 210.54.160.0/19^19-29, 202.50.208.0/20^20-29, 202.53.176.0/20^20-29, 202.55.96.0/20^20-29, 202.174.160.0/20^20-29, 202.191.32.0/20^20-29, 210.48.160.0/20^20-29, 210.56.32.0/20^20-29, 192.173.16.0/21^21-29, 202.12.248.0/21^21-29, 202.37.144.0/21^21-29, 202.37.224.0/21^21-29, 202.46.176.0/21^21-29, 202.50.200.0/21^21-29, 202.74.224.0/21^21-29, 202.78.240.0/21^21-29, 202.126.80.0/21^21-29, 203.190.208.0/21^21-29, 205.233.128.0/21^21-29, 202.36.36.0/22^22-29, 202.37.140.0/22^22-29, 202.37.200.0/22^22-29, 202.41.136.0/22^22-29, 202.50.52.0/22^22-29, 202.50.196.0/22^22-29, 202.59.4.0/22^22-29, 210.54.136.0/22^22-29, 210.55.24.0/22^22-29, 202.21.136.0/23^23-29, 202.36.44.0/23^23-29, 202.36.76.0/23^23-29, 202.37.86.0/23^23-29, 202.37.240.0/23^23-29, 202.37.252.0/23^23-29, 202.49.80.0/23^23-29, 202.50.246.0/23^23-29, 202.124.106.0/23^23-29, 205.233.136.0/23^23-29, 210.55.182.0/23^23-29, 192.88.85.0/24^24-29, 192.107.113.0/24^24-29, 192.133.31.0/24^24-29, 192.173.24.0/24^24-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.14.100.0/24^24-29, 202.20.6.0/24^24-29, 202.20.97.0/24^24-29, 202.21.130.0/24^24-29, 202.27.208.0/24^24-29, 202.36.119.0/24^24-29, 202.36.155.0/24^24-29, 202.36.183.0/24^24-29, 202.36.226.0/24^24-29, 202.37.76.0/24^24-29, 202.37.85.0/24^24-29, 202.37.136.0/24^24-29, 202.37.163.0/24^24-29, 202.37.197.0/24^24-29, 202.37.232.0/24^24-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.159.0/24^24-29, 202.49.249.0/24^24-29, 202.50.87.0/24^24-29, 203.97.5.0/24^24-29, 205.233.243.0/24^24-29, 210.54.140.0/24^24-29, 210.54.211.0/24^24-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: deon(a)iconz.net mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20070221 source: NZRR REPLACED BY: route-set: AS9439:RS-ROUTES:AS4770 descr: advertised to AS9439 by ICONZ - AS4770 members: 131.203.0.0/16^16-29, 161.29.0.0/16^16-29, 161.65.0.0/16^16-29, 210.48.0.0/17^17-29, 210.185.0.0/18^18-29, 210.54.160.0/19^19-29, 202.50.208.0/20^20-29, 202.53.176.0/20^20-29, 202.55.96.0/20^20-29, 202.174.160.0/20^20-29, 202.191.32.0/20^20-29, 210.48.160.0/20^20-29, 210.56.32.0/20^20-29, 192.173.16.0/21^21-29, 202.12.248.0/21^21-29, 202.37.144.0/21^21-29, 202.37.224.0/21^21-29, 202.46.176.0/21^21-29, 202.50.200.0/21^21-29, 202.74.224.0/21^21-29, 202.78.240.0/21^21-29, 202.126.80.0/21^21-29, 203.190.208.0/21^21-29, 205.233.128.0/21^21-29, 202.36.36.0/22^22-29, 202.37.140.0/22^22-29, 202.37.200.0/22^22-29, 202.41.136.0/22^22-29, 202.50.52.0/22^22-29, 202.50.196.0/22^22-29, 202.59.4.0/22^22-29, 210.54.136.0/22^22-29, 210.55.24.0/22^22-29, 202.21.136.0/23^23-29, 202.36.44.0/23^23-29, 202.36.76.0/23^23-29, 202.37.86.0/23^23-29, 202.37.240.0/23^23-29, 202.37.252.0/23^23-29, 202.49.80.0/23^23-29, 202.50.246.0/23^23-29, 202.124.106.0/23^23-29, 205.233.136.0/23^23-29, 210.55.182.0/23^23-29, 192.88.85.0/24^24-29, 192.107.113.0/24^24-29, 192.133.31.0/24^24-29, 192.173.24.0/24^24-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.14.100.0/24^24-29, 202.20.6.0/24^24-29, 202.20.97.0/24^24-29, 202.21.130.0/24^24-29, 202.27.208.0/24^24-29, 202.36.119.0/24^24-29, 202.36.155.0/24^24-29, 202.36.183.0/24^24-29, 202.36.226.0/24^24-29, 202.37.57.0/24^24-29, 202.37.76.0/24^24-29, 202.37.85.0/24^24-29, 202.37.136.0/24^24-29, 202.37.163.0/24^24-29, 202.37.197.0/24^24-29, 202.37.232.0/24^24-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.159.0/24^24-29, 202.49.249.0/24^24-29, 202.50.87.0/24^24-29, 203.97.5.0/24^24-29, 205.233.243.0/24^24-29, 210.54.140.0/24^24-29, 210.54.211.0/24^24-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: deon(a)iconz.net mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20070221 source: NZRR

1 0

Notification of NZRR Database changes
by NZRR Database Notifications 20 Feb '07

20 Feb '07

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:AS4770 descr: advertised to AS9560 by ICONZ - AS4770 members: 131.203.0.0/16^16-29, 161.29.0.0/16^16-29, 161.65.0.0/16^16-29, 210.48.0.0/17^17-29, 210.185.0.0/18^18-29, 210.54.160.0/19^19-29, 202.50.208.0/20^20-29, 202.53.176.0/20^20-29, 202.55.96.0/20^20-29, 202.174.160.0/20^20-29, 202.191.32.0/20^20-29, 210.48.160.0/20^20-29, 210.56.32.0/20^20-29, 192.173.16.0/21^21-29, 202.12.248.0/21^21-29, 202.37.144.0/21^21-29, 202.37.224.0/21^21-29, 202.46.176.0/21^21-29, 202.50.200.0/21^21-29, 202.74.224.0/21^21-29, 202.78.240.0/21^21-29, 202.126.80.0/21^21-29, 203.190.208.0/21^21-29, 205.233.128.0/21^21-29, 202.36.36.0/22^22-29, 202.37.140.0/22^22-29, 202.37.200.0/22^22-29, 202.41.136.0/22^22-29, 202.50.52.0/22^22-29, 202.50.196.0/22^22-29, 202.59.4.0/22^22-29, 210.54.136.0/22^22-29, 210.55.24.0/22^22-29, 202.21.136.0/23^23-29, 202.36.44.0/23^23-29, 202.36.76.0/23^23-29, 202.37.86.0/23^23-29, 202.37.240.0/23^23-29, 202.37.252.0/23^23-29, 202.49.80.0/23^23-29, 202.50.246.0/23^23-29, 202.124.106.0/23^23-29, 205.233.136.0/23^23-29, 210.55.182.0/23^23-29, 192.88.85.0/24^24-29, 192.107.113.0/24^24-29, 192.133.31.0/24^24-29, 192.173.24.0/24^24-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.14.100.0/24^24-29, 202.20.6.0/24^24-29, 202.20.97.0/24^24-29, 202.21.130.0/24^24-29, 202.27.208.0/24^24-29, 202.36.119.0/24^24-29, 202.36.155.0/24^24-29, 202.36.183.0/24^24-29, 202.36.226.0/24^24-29, 202.37.57.0/24^24-29, 202.37.76.0/24^24-29, 202.37.85.0/24^24-29, 202.37.136.0/24^24-29, 202.37.163.0/24^24-29, 202.37.197.0/24^24-29, 202.37.232.0/24^24-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.159.0/24^24-29, 202.49.249.0/24^24-29, 202.50.87.0/24^24-29, 203.97.5.0/24^24-29, 205.233.243.0/24^24-29, 210.54.140.0/24^24-29, 210.54.211.0/24^24-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: deon(a)iconz.net mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20061019 source: NZRR REPLACED BY: route-set: AS9560:RS-ROUTES:AS4770 descr: advertised to AS9560 by ICONZ - AS4770 members: 131.203.0.0/16^16-29, 161.29.0.0/16^16-29, 161.65.0.0/16^16-29, 210.48.0.0/17^17-29, 210.185.0.0/18^18-29, 210.54.160.0/19^19-29, 202.50.208.0/20^20-29, 202.53.176.0/20^20-29, 202.55.96.0/20^20-29, 202.174.160.0/20^20-29, 202.191.32.0/20^20-29, 210.48.160.0/20^20-29, 210.56.32.0/20^20-29, 192.173.16.0/21^21-29, 202.12.248.0/21^21-29, 202.37.144.0/21^21-29, 202.37.224.0/21^21-29, 202.46.176.0/21^21-29, 202.50.200.0/21^21-29, 202.74.224.0/21^21-29, 202.78.240.0/21^21-29, 202.126.80.0/21^21-29, 203.190.208.0/21^21-29, 205.233.128.0/21^21-29, 202.36.36.0/22^22-29, 202.37.140.0/22^22-29, 202.37.200.0/22^22-29, 202.41.136.0/22^22-29, 202.50.52.0/22^22-29, 202.50.196.0/22^22-29, 202.59.4.0/22^22-29, 210.54.136.0/22^22-29, 210.55.24.0/22^22-29, 202.21.136.0/23^23-29, 202.36.44.0/23^23-29, 202.36.76.0/23^23-29, 202.37.86.0/23^23-29, 202.37.240.0/23^23-29, 202.37.252.0/23^23-29, 202.49.80.0/23^23-29, 202.50.246.0/23^23-29, 202.124.106.0/23^23-29, 205.233.136.0/23^23-29, 210.55.182.0/23^23-29, 192.88.85.0/24^24-29, 192.107.113.0/24^24-29, 192.133.31.0/24^24-29, 192.173.24.0/24^24-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.14.100.0/24^24-29, 202.20.6.0/24^24-29, 202.20.97.0/24^24-29, 202.21.130.0/24^24-29, 202.27.208.0/24^24-29, 202.36.119.0/24^24-29, 202.36.155.0/24^24-29, 202.36.183.0/24^24-29, 202.36.226.0/24^24-29, 202.37.57.0/24^24-29, 202.37.76.0/24^24-29, 202.37.85.0/24^24-29, 202.37.136.0/24^24-29, 202.37.163.0/24^24-29, 202.37.197.0/24^24-29, 202.37.232.0/24^24-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.159.0/24^24-29, 202.49.249.0/24^24-29, 202.50.87.0/24^24-29, 203.97.5.0/24^24-29, 205.233.243.0/24^24-29, 210.54.140.0/24^24-29, 210.54.211.0/24^24-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: deon(a)iconz.net mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20070221 source: NZRR

1 0

Notification of NZRR Database changes
by NZRR Database Notifications 20 Feb '07

20 Feb '07

Dear Colleague, This is to notify you that some object(s) in NZRR database which you either maintain or are listed as to-be-notified have been added, deleted or changed. These objects are used to configure the various NZIX route servers (http://nzix.net/) so you can expect the relevant servers to be reloaded in the near future. The reloading of the servers is staggered over a period of time so that if you are peering with both servers at an exchange, you can maintain at least one BGP session at all times and consequently a full set of routes. --- PREVIOUS OBJECT: route-set: AS9439:RS-ROUTES:AS4770 descr: advertised to AS9439 by ICONZ - AS4770 members: 131.203.0.0/16^16-29, 161.29.0.0/16^16-29, 161.65.0.0/16^16-29, 210.48.0.0/17^17-29, 210.185.0.0/18^18-29, 210.54.160.0/19^19-29, 202.50.208.0/20^20-29, 202.53.176.0/20^20-29, 202.55.96.0/20^20-29, 202.174.160.0/20^20-29, 202.191.32.0/20^20-29, 210.48.160.0/20^20-29, 210.56.32.0/20^20-29, 192.173.16.0/21^21-29, 202.12.248.0/21^21-29, 202.37.144.0/21^21-29, 202.37.224.0/21^21-29, 202.46.176.0/21^21-29, 202.50.200.0/21^21-29, 202.74.224.0/21^21-29, 202.78.240.0/21^21-29, 202.126.80.0/21^21-29, 203.190.208.0/21^21-29, 205.233.128.0/21^21-29, 202.36.36.0/22^22-29, 202.37.140.0/22^22-29, 202.37.200.0/22^22-29, 202.41.136.0/22^22-29, 202.50.52.0/22^22-29, 202.50.196.0/22^22-29, 202.59.4.0/22^22-29, 210.54.136.0/22^22-29, 210.55.24.0/22^22-29, 202.21.136.0/23^23-29, 202.36.44.0/23^23-29, 202.36.76.0/23^23-29, 202.37.86.0/23^23-29, 202.37.240.0/23^23-29, 202.37.252.0/23^23-29, 202.49.80.0/23^23-29, 202.50.246.0/23^23-29, 202.124.106.0/23^23-29, 205.233.136.0/23^23-29, 210.55.182.0/23^23-29, 192.88.85.0/24^24-29, 192.107.113.0/24^24-29, 192.133.31.0/24^24-29, 192.173.24.0/24^24-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.14.100.0/24^24-29, 202.20.6.0/24^24-29, 202.20.97.0/24^24-29, 202.21.130.0/24^24-29, 202.27.208.0/24^24-29, 202.36.119.0/24^24-29, 202.36.155.0/24^24-29, 202.36.183.0/24^24-29, 202.36.226.0/24^24-29, 202.37.57.0/24^24-29, 202.37.76.0/24^24-29, 202.37.85.0/24^24-29, 202.37.136.0/24^24-29, 202.37.163.0/24^24-29, 202.37.197.0/24^24-29, 202.37.232.0/24^24-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.159.0/24^24-29, 202.49.249.0/24^24-29, 202.50.87.0/24^24-29, 203.97.5.0/24^24-29, 205.233.243.0/24^24-29, 210.54.140.0/24^24-29, 210.54.211.0/24^24-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: deon(a)iconz.net mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20061019 source: NZRR REPLACED BY: route-set: AS9439:RS-ROUTES:AS4770 descr: advertised to AS9439 by ICONZ - AS4770 members: 131.203.0.0/16^16-29, 161.29.0.0/16^16-29, 161.65.0.0/16^16-29, 210.48.0.0/17^17-29, 210.185.0.0/18^18-29, 210.54.160.0/19^19-29, 202.50.208.0/20^20-29, 202.53.176.0/20^20-29, 202.55.96.0/20^20-29, 202.174.160.0/20^20-29, 202.191.32.0/20^20-29, 210.48.160.0/20^20-29, 210.56.32.0/20^20-29, 192.173.16.0/21^21-29, 202.12.248.0/21^21-29, 202.37.144.0/21^21-29, 202.37.224.0/21^21-29, 202.46.176.0/21^21-29, 202.50.200.0/21^21-29, 202.74.224.0/21^21-29, 202.78.240.0/21^21-29, 202.126.80.0/21^21-29, 203.190.208.0/21^21-29, 205.233.128.0/21^21-29, 202.36.36.0/22^22-29, 202.37.140.0/22^22-29, 202.37.200.0/22^22-29, 202.41.136.0/22^22-29, 202.50.52.0/22^22-29, 202.50.196.0/22^22-29, 202.59.4.0/22^22-29, 210.54.136.0/22^22-29, 210.55.24.0/22^22-29, 202.21.136.0/23^23-29, 202.36.44.0/23^23-29, 202.36.76.0/23^23-29, 202.37.86.0/23^23-29, 202.37.240.0/23^23-29, 202.37.252.0/23^23-29, 202.49.80.0/23^23-29, 202.50.246.0/23^23-29, 202.124.106.0/23^23-29, 205.233.136.0/23^23-29, 210.55.182.0/23^23-29, 192.88.85.0/24^24-29, 192.107.113.0/24^24-29, 192.133.31.0/24^24-29, 192.173.24.0/24^24-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.14.100.0/24^24-29, 202.20.6.0/24^24-29, 202.20.97.0/24^24-29, 202.21.130.0/24^24-29, 202.27.208.0/24^24-29, 202.36.119.0/24^24-29, 202.36.155.0/24^24-29, 202.36.183.0/24^24-29, 202.36.226.0/24^24-29, 202.37.76.0/24^24-29, 202.37.85.0/24^24-29, 202.37.136.0/24^24-29, 202.37.163.0/24^24-29, 202.37.197.0/24^24-29, 202.37.232.0/24^24-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.159.0/24^24-29, 202.49.249.0/24^24-29, 202.50.87.0/24^24-29, 203.97.5.0/24^24-29, 205.233.243.0/24^24-29, 210.54.140.0/24^24-29, 210.54.211.0/24^24-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: deon(a)iconz.net mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20070221 source: NZRR

1 0

Notification of NZRR Database changes
by NZRR Database Notifications 20 Feb '07

20 Feb '07

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: AS38329 as-name: NZRR-AS38329 descr: Wellington City Council descr: WIX peering at '202.7.0.71' descr: see Citylink RT job #8509 admin-c: RPA1-NZRR tech-c: RPA1-NZRR import: from AS9439 accept ANY AND NOT fltr-bogons export: to AS9439 announce AS38329 notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: Robert.Flynn(a)wcc.govt.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20070221 source: NZRR --- OBJECT BELOW CREATED: route-set: AS9439:RS-ROUTES:AS38329 descr: Route set advertised to AS9439 by Wellington City Council - AS38329 members: 192.88.190.0/24^24-29, 192.190.108.0/24^24-29, 203.97.237.120/29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: Robert.Flynn(a)wcc.govt.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20070221 source: NZRR

1 0

Re: [nznog] ISP's Natting customer pools
by Martin Kealey 20 Feb '07

20 Feb '07

> Given the relative sizes of ISPs, it's probably also true to say "most DSL netizens use xtra". Them's fighting words... or they would be if I was in the marketing dept. Question: are there any (DSL?) CPE units for sale or in development that will do v6 to v4 translation, plus v6 pass-thru? -Martin -- Martin D Kealey, ihüg engineering

10 12

Re: [nznog] ISP's Natting customer pools
by Perry Lorier 20 Feb '07

20 Feb '07

(Reposted to the list *with* Simons permission): Simon Lyall wrote: >> If you looked at the "top ports" you'll see 135, 139, 445 make an >> appearance which are used by various windows worms, so obvious some >> users are infected with virii. However this isn't going to push peoples >> port counts up to the 1,000's like p2p will. > > Have you got numbers for each port as well as the combos? Something like: > > Port 25 - 70% > Port 80 - 75% > Port 443 - 56% > /--- Percentage of IP's that sent a packet on this port | /------ Port number v v 98.11 80/tcp 98.09 53/udp 95.64 443/tcp 73.63 110/tcp 60.43 25/tcp 41.83 123/udp 36.18 22/tcp <-- ! 33.89 7001/udp 33.62 1433/tcp 33.22 5900/tcp 32.81 6000/tcp 31.07 139/tcp 30.86 445/tcp 30.60 135/tcp 26.40 21/tcp 25.73 2967/tcp 25.42 8080/tcp 23.79 42/tcp 21.62 10000/tcp 20.84 9/udp <-- wtf? 19.62 6346/tcp 19.49 1863/tcp 17.31 1080/tcp 16.98 6346/udp 15.49 3389/tcp 15.14 10827/tcp 14.83 10929/tcp 13.94 26200/tcp 13.22 6348/udp 12.92 6348/tcp 12.48 15118/tcp 11.99 20000/tcp 11.41 12350/udp 11.32 8000/udp 11.21 6881/tcp 11.02 80/udp 10.84 5800/tcp 10.84 5000/tcp 10.62 7001/tcp

1 0

Re: [nznog] [Fwd: [pacnog] IPv4 exhaustion discussionsin Asia Pacific region]
by Jonathan Woolley 20 Feb '07

20 Feb '07

> Indeed one might speculate that the vast bulk of users in a very large > country using a complex language of their own might not miss the > english speaking world to any great extent. For those who found it a > problem (international traders) legitimate v4 addresses could be > allocated. I can see the headlines now: "[Vendor] charges [country] $[lots] to enable NAT on the great firewall. They decide to go with iptables instead" =)

26 91

[Fwd: Re: ISP's Natting customer pools]
by Gerard Creamer 20 Feb '07

20 Feb '07

Fascinating stuff - thanks for posting it. I find it most interesting that over 60% of DSL users systems know about and use more than 20 protocols. What is the sample size? Just approximate - 100s, 1000s, 10s of 000s ? I can understand if you didn't want to say, but it would help with rough deviation / error % Thanks, Gerard Perry Lorier wrote: > Well, I ran an analysis of DSL customers[1] over the space of 24 hours > [4] to see how many different protocols people were using. For each IP > I kept track of the number of unique "server ports"[2] were used.[3] >

2 1

Prime Minister heart attack trojan spam run
by matthew＠auscert.org.au 18 Feb '07

18 Feb '07

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 G'day all Have just released an alert on a(nother) trojan spam run at: AL-2007.0026 -- [Win] -- "Prime Minister heart attack" trojan http://www.auscert.org.au/7314 Basically there being emails currently in circulation with a variety of subject lines, including: "Current Australia's Prime Minister survived a hear attack" "The life of the Prime Minister is in grave danger" "Prime Minister survived a heard attack" with a link to malicious websites, including: h**p://www,austr-news,com/ h**p://www,theaunews,com/ h**p://www,theau-news,org/ Anyone seeing a lot of this? Perhaps targeting other heads of state? Might be worth keeping an eye out as we've seen similar to this before: AL-2006.0069 -- [Win] -- "John Howard tragedy" email attachment installs Torpig credential stealing trojan http://www.auscert.org.au/6645 with similar 'hooks' in that one appearing to be targeting Italy and the UK at least with messages of their government leaders' reported assassination. Feedback appreciated. Best regards, - -- Matthew McGlashan -- Coordination Centre Team Leader | Hotline: +61 7 3365 4417 Australian Computer Emergency Response Team | Direct: +61 7 3365 7924 (AusCERT) | Fax: +61 7 3365 7031 The University of Queensland | WWW: www.auscert.org.au Qld 4072 Australia | Email: auscert(a)auscert.org.au -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) Comment: http://www.auscert.org.au/render.html?it=1967 Comment: http://www.auscert.org.au/render.html?it=1967 iQCVAwUBRdlMDyh9+71yA2DNAQKhGwQAmY99YaXxm48qj5LqxSSYYeMlTTSjWIvm F1S/Qop5km5/e2ZrDNJHbojfVNpLg9YrXGG8AxtY5nTcD852ojBuTf9tBmHUwqwF ljnyc4L6zxZ4iFzFWEZhypXBcnN6AZEYU8++vnnqePCK6KPfZsNJkhgodq2L53n9 GimZG4XHaso= =/dMS -----END PGP SIGNATURE-----

1 0

[Fwd: [pacnog] IPv4 exhaustion discussions in Asia Pacific region]
by Andy Linton 18 Feb '07

18 Feb '07

Given our discussions on IPv4 and IPv6 at the recent nznog meeting some of you may be interested in this. -------- Original Message -------- Subject: [pacnog] IPv4 exhaustion discussions in Asia Pacific region Date: Mon, 12 Feb 2007 10:44:32 +1000 (EST) From: Elly Tawhai <elly(a)apnic.net> To: pacnog(a)pacnog.org Hi You are probably aware by now that the exhaustion of IPv4 address space is likely to occur in the next few years. You might be interested to know that a proposal to deal with IPv4 exhaustion has been put forward for discussion in the APNIC region. The proposal suggests five main principles: (1) Global synchronization: All five RIRs will proceed at the same time for measures on IPv4 address exhaustion. (2) Some Blocks to be left: Keep a few /8 stocks instead of distributing all. (3) Keeping current practices until the last moment: Maintain the current policy until the last allocation. (4) Separate discussions on "recycle" issue: Recovery of unused address space should be discussed separately For more information on the proposal, see: http://www.apnic.net/docs/policy/proposals/prop-046-v001.html This proposal affects the whole Internet community. I encourage you to read the proposal and have your say on the APNIC Policy SIG mailing list, or at the upcoming APNIC 23 meeting in Bali, Indonesia, 26 February - 2 March 2007. If you can't attend the meeting in person, you can still have your say by participating remotely via live chat. APNIC Policy SIG mailing list information: http://www.apnic.net/community/lists APNIC 23: http://www.apnic.net/meetings/23/ Kind regards, Elly APNIC

13 13

[Fwd: [pacnog] IPv4 exhaustion discussionsin Asia Pacific region]
by Patrick Jordan-Smith 18 Feb '07

18 Feb '07

> Which is a problem if we are reliant on the telco's to move to IPv6. > Why would any sane [NZ] telco spend serious money changing to a > technology which further relegates them to a common bit pusher? > There is an argument here that IPv4 exhaustion provides a technical > rational for telcos to provide walled garden, proxy-style services. I fully support this style of thinking. Infact, if I was an ISP I would be seriously considering NATing my entire customer base - except for those who were willing to pay $x/mo for a real IP. At the end of the day, with a few exceptions, most protocols work quite well from behind a nat. And it gives me another revenue stream, which if I am an ISP would be quite useful considering I am probably losing money on the DSL I am currently providing. Cheers, Patrick -- patpatnz(a)gmail.com

6 6

APNIC fee structure - Online voting period extended
by Elly Tawhai 18 Feb '07

18 Feb '07

Dear Colleagues Voting on the APNIC fee schedule questions has now been extended by one week. The APNIC Executive Council decided to extend the online vote due to the low number of responses so far. This is an important issue for all APNIC members, so we encourage you to have your opinions counted. The new deadline for votes is 14:00 UTC, Friday 23 February, 2007. To vote, or get more information about the process, please go to: https://my.apnic.net/voting Please note that only registered voting contacts are able to cast votes. If you have any questions about using MyAPNIC, please contact helpdesk(a)apnic.net. Kind regards, Elly ________________________________________________________________________ Elly Tawhai email: elly(a)apnic.net Internet Resource Analyst, APNIC sip: elly(a)voip.apnic.net http://www.apnic.net/helpdesk phone: +61 7 3858 3188 fax: +61 7 3858 3199 ________________________________________________________________________ See you at APNIC 23! Bali, 26 February - 2 March, 2007 http://www.apnic.net/meetings

1 0

Re: [nznog] [Fwd: [pacnog] IPv4 exhaustion discussionsin Asia Pacific region]
by Ewen McNeill 16 Feb '07

16 Feb '07

In message <2B310DEB-219F-4F70-9779-F27EDDEE60AA(a)ca.afilias.info>, Joe Abley writes: >On 16-Feb-2007, at 17:00, Nathan Ward wrote: >> End-to-end IP connectivity is so passe. > >But it's arguably what allowed the Internet to grow and flourish. If >the network controls the applications that users can deploy, then >[provider catchup or user disappointment or] >people will stop dreaming up new applications for users to run, and >will instead concentrate on packages they can sell to carriers and ISPs. Or, perhaps worse, all new applications will have an extra layer to "route around" this problem. The rise of application data over XML over HTTP (over SSL) over TCP over IP hints at what this world might be like. That's not exactly progress. The security folks aren't exactly keen on this either (even without the SSL, it's very hard to "pinhole" inspect what is going on in the midst of large XML payloads, and you don't get much of a service type indicator if it's all XML over HTTP). The "big win" of Skype, and Kazaa before it, is its ability to "route around" the NAT everywhere, firewall everywhere, world and overlay what is basically an end-to-end network again (at least bits of it created on demand). That's not exactly progress either. Some other possibilities have been suggested, such as smarter intermediate boxes (firewalls, NAT), with which one negotiates (as in a protocol to request) a path through to the end box. This is already starting to happen with, eg, STUN, but potentially could be formalised as part of connection setup, and done automatically rather than requiring per-application custom setup. One is left wondering if instead of inventing random ad-hoc "tunnel through intermediate boxes" protocols it may be that things converge on, eg, 6-over-4. At least, eg, application over TCP over IPv6 over IPv4 is still pretty transparent, and doesn't have _that_ much overheard (compared with, eg, XML over HTTP). And there's some eventual migration path which involves reducing layers (eventually when everything is 6-over-4 it makes sense to just get rid of the IPv4 bit). Ewen

1 0

Apropos addressing
by Juha Saarinen 16 Feb '07

16 Feb '07

Geoff Huston has something to say on that: http://www.circleid.com/posts/addressing_the_future_internet/ (Shamelessly nicked from Bill St Arnaud's CAnet news: http://www.canarie.ca/canet4/library/list.html) -- Juha Saarinen www.geekzone.co.nz/juha | Skype: juha_saarinen blogs.pcworld.co.nz/pcworld/techsploder www.computerworld.co.nz | MSN: juha_saarinen(a)msn.com Voice: +64 9 950 3023 Subtle recursive jokes in .sigs are not funny.

2 1

Notification of NZRR Database changes
by NZRR Database Notifications 13 Feb '07

13 Feb '07

Dear Colleague, This is to notify you that some object(s) in NZRR database which you either maintain or are listed as to-be-notified have been added, deleted or changed. These objects are used to configure the various NZIX route servers (http://nzix.net/) so you can expect the relevant servers to be reloaded in the near future. The reloading of the servers is staggered over a period of time so that if you are peering with both servers at an exchange, you can maintain at least one BGP session at all times and consequently a full set of routes. --- PREVIOUS OBJECT: route-set: AS9439:RS-ROUTES:AS38292 descr: Route set advertised to AS9439 by Zero One - AS38292 members: 210.48.94.0/24^24-29, 210.48.103.192/26^26-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: nick(a)01.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20070212 source: NZRR REPLACED BY: route-set: AS9439:RS-ROUTES:AS38292 descr: advertised to AS9439 by ZeroOne (NZ) Limited - AS38292 members: 202.174.6.0/23^23-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: noc(a)zeroone.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20070214 source: NZRR

1 0

NZNOG 2007: Sysadmin Miniconf: Slides available
by Ewen McNeill 11 Feb '07

11 Feb '07

For those that attended the Sysadmin Miniconf at NZNOG 2007 (or wished to but had conflicts), the slide sets from most of the talks at the miniconf are now online: http://nznog.miniconf.org/ Thank you to everyone who participated in the miniconf and helped make it a success, and especially to those who spoke at the miniconf. If anyone has anything else that they want linked to the Sysadmin Miniconf page please email it to <talks(a)nznog.miniconf.org>. Ewen

1 0

Notification of NZRR Database changes
by NZRR Database Notifications 11 Feb '07

11 Feb '07

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

1 0

Notification of NZRR Database changes
by NZRR Database Notifications 11 Feb '07

11 Feb '07

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

1 0

Notification of NZRR Database changes
by NZRR Database Notifications 11 Feb '07

11 Feb '07

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: AS38292 as-name: NZRR-AS38292 descr: Zero One descr: WIX peering at '202.7.1.17' descr: see Citylink RT job #245 admin-c: RPA1-NZRR tech-c: RPA1-NZRR import: from AS9439 accept ANY AND NOT fltr-bogons export: to AS9439 announce AS38292 notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: nick(a)01.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20070212 source: NZRR --- OBJECT BELOW CREATED: route-set: AS9439:RS-ROUTES:AS38292 descr: Route set advertised to AS9439 by Zero One - AS38292 members: 210.48.94.0/24^24-29, 210.48.103.192/26^26-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: nick(a)01.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20070212 source: NZRR

1 0

Off Topic - Woosh VoIP engineer please contact me off list..
by Chris Hodgetts 09 Feb '07

09 Feb '07

I had VoIP issues with Woosh awhile ago, and was advised by a tech there that they would start to support RFC2833 as opposed to INBAND DTMF on their VoIP system (when he spoke to me he advised in about 3 weeks, but this was well before Christmas) This is yet to happen, and I am still having issues calling a few IVR systems and would like to get it resolved if I can - or at least know of a date this might take place. Cheers, and apologies for taking this off topic, and because I don't drink I cant bring it back on topic..... but I am sure someone can drink enough for me. Cheers thanks again.

5 4

Notification of NZRR Database changes
by NZRR Database Notifications 07 Feb '07

07 Feb '07

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: AS17663 as-name: NZRR-AS17663 descr: Housing New Zealand Corporation descr: WIX peering at '202.7.0.149' descr: see Citylink RT job #8222 admin-c: RPA1-NZRR tech-c: RPA1-NZRR import: from AS9439 accept ANY AND NOT fltr-bogons export: to AS9439 announce AS17663 notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: ns(a)hnzc.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20070208 source: NZRR --- OBJECT BELOW CREATED: route-set: AS9439:RS-ROUTES:AS17663 descr: Route set advertised to AS9439 by Housing New Zealand Corporation - AS17663 members: 192.173.17.0/24^24-29, 202.37.197.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: ns(a)hnzc.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20070208 source: NZRR

1 0

A new policy proposal "IPv4 countdown policy proposal" - APNIC 23
by Miwa Fujii 06 Feb '07

06 Feb '07

Hi All, Thanks for the NZNOG 2007 committee's efforts to make successful NZNOG 2007. Thanks also for NZNOG community pple's warm hospitality to us. I very much enjoyed technical presentations, the panel discussion and both formal/informal social events. As we discussed in the panel discussion "Where to spend the money, IPv6, or somewhere else?", there were quite a few dimensions to discuss this topic. As NZNOG is a technical community, naturally, the discussion was drawn into technical details of IPv6. However, we briefly discussed about the relationship between IPv4 address exhaustion and IPv6. There is a policy proposal for the upcoming APNIC 23 in Bali, titled "IPv4 countdown policy proposal" http://www.apnic.net/docs/policy/proposals/prop-046-v001.html I think having a wider community's input to this proposal would be good. If you have any comment, please feel free to post it to the APNIC sig-policy mailing list. You can subscribe the mailing list from: http://www.apnic.net/community/lists/index.html Looking forward to hearing your view. miwa

1 0

Thursday night curry in Hamilton?
by Ian McDonald 06 Feb '07

06 Feb '07

Jayne and I have thought about this and decided that it's really time Hamilton got their act together on this one. Various people/groups have talked about this but no-one has done this yet (that I'm aware of) and we'd like to see this kick off. Since many of you from Hamilton probably met each other at NZNOG (shame I couldn't make it) I thought it'd be a good time to mention it while you still remember each other. If you're interested please email me off list. Also can whoever looks after the domain/server (Jamie Baddeley?) contact me to see how we can put Hamilton on. NB I'm not going to make token reference to beer as think networking (in the social sense) is quite a relevant topic. And more than token amount of beer might get consumed anyway! Ian -- Web: http://wand.net.nz/~iam4 Blog: http://iansblog.jandi.co.nz WAND Network Research Group

1 1

NZNOG Photos (Group and others)
by Lin Nah 05 Feb '07

05 Feb '07

HI all Group photo for NZNOG 2007 http://coders.meta.net.nz/~perry/inet/nznog-07/index.php?photo=4 If you are in this photo and have NOT been named, please click on your mouse button when a ? appears on your face. We have tried to identify as many as possible. People are not indentified due to many reasons. Please don't take it personally. Btw if you want to look at the nznog photo of other years I've added a link in the group photo secion at wiki.nznog.org or NZNOG 2006 http://coders.meta.net.nz/~perry/inet/nznog-06/index.php?photo=3 NZNOG 2005 http://coders.meta.net.nz/~perry/inet/nznog-05/index.php?photo=1 nznog 2004 http://coders.meta.net.nz/~perry/inet/nznog-05/index.php?photo=2 If you took photos, please add a link to this page http://wiki.nznog.org/index.cgi/Pictures Also if you blogged about it, add a link to http://wiki.nznog.org/index.cgi/Blogs regards lin

1 0

elevated icmp last couple of days?
by Anton Smith 05 Feb '07

05 Feb '07

Hi all, Just wondering if anyone else has noticed elevated ICMP levels. I'm seeing a lot of what looks like ICMP from infected machines, both coming into our network and leaving it. Always with the same sequence number and going to and from many different machines: e.g. 13:41:45.682360 IP 196.211.95.177 > 202.65.160.195: icmp 72: echo request seq 20041 13:41:45.682395 IP 196.211.95.177 > 202.65.160.195: icmp 72: echo request seq 20041 13:41:45.684098 IP 196.211.95.177 > 202.65.160.195: icmp 72: echo request seq 20041 13:41:45.684185 IP 196.211.95.177 > 202.65.160.195: icmp 72: echo request seq 20041 and 13:45:23.759952 IP 203.110.28.211 > 24.149.23.167: icmp 41: echo request seq 39506 13:45:23.764000 IP 203.110.28.211 > 24.149.63.81: icmp 41: echo request seq 39762 13:45:23.764046 IP 203.110.28.211 > 24.149.20.160: icmp 41: echo request seq 40018 13:45:23.764426 IP 203.110.28.211 > 24.149.134.141: icmp 41: echo request seq 40274 13:45:23.766189 IP 203.110.28.211 > 24.149.81.135: icmp 41: echo request seq 40530 Seems to be the same sequence number for the same destination host. There are hundreds/thousands of these every second and seems to be ongoing. Just wondering if it is just us. Regards, Anton

1 1

Could the mail admin for blakjak.net contact me off list?
by Juha Saarinen 05 Feb '07

05 Feb '07

SMTP error from remote mail server after RCPT TO:<@nzoss.org.nz>: host mx.blakjak.net [202.50.176.75]: 554 Service unavailable; Client host [NZ IP address] blocked using rbl.blakjak.net; Mail from China and Korea is not welcome here due to high SPAM volumes. Visit rbl.blakjak.net for information. It seems the Blakjak RBL needs tweaking if the NZOSS is to accept email from certain parts of the NZ Intarweb. Thanks. -- Juha Saarinen www.geekzone.co.nz/juha | Skype: juha_saarinen blogs.pcworld.co.nz/pcworld/techsploder www.computerworld.co.nz | MSN: juha_saarinen(a)msn.com Voice: +64 9 950 3023 Subtle recursive jokes in .sigs are not funny.

2 2

Jersey found at NZNOG
by Simon Lyall 03 Feb '07

03 Feb '07

Found in Miro hall on Saturday morning. A black zip up Jersey, size "M" left in the common room. Contact me directly to arrange return. -- Simon J. Lyall | Very Busy | Web: http://www.darkmere.gen.nz/ "To stay awake all night adds a day to your life" - Stilgar | eMT.

1 0

NZNOG '07 Accommodation
by Jonny Martin 27 Jan '07

27 Jan '07

Hi All. We've ended up with a couple of spare rooms for NZNOG '07 accommodation (Tue - Fri nights). So if you'd been hoping to secure some accommodation but didn't get it sorted before the deadline, here is your chance! Send your details through to dave(a)staff.inspire.net.nz if you wish to take advantage of this. See you in Palmerston North, Jonny.

1 0

Incorrect / missing WHOIS details
by John ＠ netTRUST 26 Jan '07

26 Jan '07

Do any members present have any feelings about domain names that have misleading or ommited core/required contact details? I refer to cults.co.nz - a controversial religious themed website - though the issue at hand here is their whois, not their content. This may be a breach of rule 7.1 of the DNC's publication "Registering, Managing and Cancelling domain names" which reads- 7.1 When registering a new domain name the registrar will supply the following data: * Domain name. * Name server list. * Registrant contact details. * Administrative contact details. * Technical contact details. * Billing term. Also the registrar involved may be in breach of section 8.1 which reads- 8.1 Registrars will be required to maintain the details of the domain names for which they are the registrar. They will be able to amend/update the following fields: 􀂃 Name Server List. 􀂃 Registrant Name. 􀂃 Registrant Contact Details. 􀂃 Registrant Customer ID. 􀂃 Administrative Contact Details. 􀂃 Technical Contact Details. 􀂃 Billing Term. While the specifics as to whether this is a technical breach or not should be determined by the DNC and what I have stated above is only an opinion,. this is still a practice I feel should not be permitted to take hold in New Zealand. The publication mentioned is located at: http://www.dnc.org.nz/content//registering_managing_cancelling.pdf

3 2

NZNOG 2007 on 31 January - 2 February 2007
by Lin Nah 25 Jan '07

25 Jan '07

Hi Reminder: The nznog meet this year is at Massey University Campus, Palmerston North starting on 31 January to 2 February 2007. InspireNet is hosting this year. To those of you already going, check out wiki.nznog.org I know there's a whole lot more ppl who are attending but not found the wiki yet. Don't worry about reading the rest of this email. To those not attending: I urge you to consider coming to the conference. It isn't too late to register for it. I hope no one was put off by the "deadlines" mentioned in earlier posts. Registrations are still being accepted. If you don't know much about it check out www.nznog.org The programme will include: * AS-Path analysis: Testing claims of "tier-1" status and examining BGP routing anomalies by Gaurab Upadhaya, Packet Clearing House (PCH) * Connecting the dots: Graph theory, Telecom Policy, & Internet Evolution by Tom Vest, UC San Diego Supercomputer Center (CAIDA) * Open Source VoIP Platform in Carrier Environments by James Jones, Virtual Realm Software * Dealing with Joe-jobs (spam backscatter attacks) by Simon Howard, DMZGlobal Ltd * Network Control Planes: Subscriber authentication, authorization, and accounting, network policy deployment and enforcement, and a look at solutions to do that by Alastair Johnson, Alcatel-Lucent On the Wednesday we have * APNIC Internet Resource Management Essentials tutorial. * Microtik RouterOS Training * MPLS and fixed access networks for beginners * Sysadmin Day for sysadmins who work at ISPs. Sessions will be recorded. There are plans to stream the sessions as well BUT one never knows when Murphy's law will strike. Information will be available on the wiki regarding the streams etc when we have the information. The conference is more than just the sessions. It is the people you meet and the links made for future cooperation. Attached is a document that will hopefully help anyone attempting to apply for permission to attend NZNOG at this stage. Perhaps one method is to compare the cost of attending NZNOG with attending training courses. Hopefully it isn't too late for you. Have a good weekend! regards lin

1 0

VoIP and NZ ENUM services
by Nick Larsen 25 Jan '07

25 Jan '07

Hey people, Does anyone know the outcome of the ENUM trial in NZ (by InternetNZ), or is it still going? I've researched it a bit, but it seems the trial has ended (or maybe I just haven't searched hard enough ;)). Any info on ENUM in New Zealand or a pointer in the right direction would be great. Cheers, Nick Larsen

3 3

NZNOG07 Transport Pooling: Auckland CBD - Auckland Airport
by Ian Batterbee 24 Jan '07

24 Jan '07

For those going down on NZ5077 departing Auckland at 1835, how many, if any, are intending to leave from the Auckland CBD ?

9 8

[Fwd: [Apnic-announce] New APNIC IPv4 address ranges] (fwd)
by Elly Tawhai 24 Jan '07

24 Jan '07

Apologies for duplicate postings -------- Original Message -------- Subject: [Apnic-announce] New APNIC IPv4 address ranges Date: Thu, 18 Jan 2007 16:00:03 +1000 From: helpdesk(a)apnic.net Reply-To: apnic-talk(a)apnic.net To: apnic-announce(a)apnic.net Dear colleagues APNIC received the following IPv4 address blocks from IANA in Jan 2007 and will be making allocations from these ranges in the near future: 116/8 APNIC 117/8 APNIC 118/8 APNIC 119/8 APNIC 120/8 APNIC APNIC has made this announcement to enable the Internet community to update network configurations, such as routing filters, where required. Routability testing of new prefixes will commence on Friday January 19 2007. The daily report will be published at the usual URL: http://www.ris.ripe.net/debogon/debogon.html For more information on the resources administered by APNIC, please see: http://www.apnic.net/db/ranges.html For information on the minimum allocation sizes within address ranges administered by APNIC, please see: http://www.apnic.net/db/min-alloc.html Kind regards Guangliang ________________________________________________________________ Guangliang Pan email: helpdesk(a)apnic.net Resources Services Manager sip: helpdesk(a)voip.apnic.net APNIC phone: +61 7 3858 3188 http://www.apnic.net/ fax: +61 7 3858 3199 ________________________________________________________________ _______________________________________________ Apnic-announce mailing list Apnic-announce(a)lists.apnic.net http://mailman.apnic.net/mailman/listinfo/apnic-announce

1 0

AMS-IX claims to be world's largest public 'net exchange
by Matthew Poole 23 Jan '07

23 Jan '07

http://www.theregister.co.uk/2007/01/19/ams_ix_record/ "The Amsterdam Internet Exchange (AMS-IX) is claiming to be the world's largest public Internet exchange, after setting a new traffic record earlier this month of 233Gbit/s. It says it now shifts more than 1.5 Petabytes a day, on behalf of over 250 ISPs and carriers." How do our IX's compare? Obviously we won't be even close, a state of affairs not aided in any way by certain policies of certain telcos, but it'd be interesting to know how much traffic does actually traverse, in particular, APE and WIX. -- Matthew Poole "Don't use force. Get a bigger hammer."

5 4

NZNOG 07 Wiki and other info
by Lin Nah 20 Jan '07

20 Jan '07

HI Getting to NZNOG If you are flying down from Auckland AND with to get there by the start of tutorials on Wed, the only way is to fly in on Tues evening. The first flight for Auckland - PN will mean you'll be a little bit late. Alternatively you can fly to Wellington and catch a ride from someone to PN (read below). NZNOG wiki I have set up a few wiki pages for NZNOG 07 to help people coordinate their activities. There was no point setting up a wiki just for these few days. I just used the auckland TNC wiki. Anyway start from: http://auckland.thursdaynightcurry.com/index.cgi?NZNOG07_Wiki Basically I have set up sections like Transport and Dinners. Set up your own pages if you want more pages. I have no idea if anyone will find it useful. It was worth trying this once. Transport * This is for people who want rides from anywhere to PN. * There's a page for people who can perhaps save $$ by sharing taxi from the airport to Massey. * I have started up pages for Wellington - PN and Auckland to PN. List there if you have space in your car or are looking for a ride * I've included in the transport page for AUckland to PN the link to the Thrifty car rental that has a good relocation deal. Ie you only pay petrol for hiring car from PN to Auckland. Wednesday Dinner http://auckland.thursdaynightcurry.com/index.cgi?Wednesday_Dinner We are having a curry dinner on Wed evening. If you can make it, add your name to it. This isn't restricted to nznog conference attendees only. Anyone who can make it is welcome. Tuesday Evening It appears a few people are arriving on Tuesday evening. So a page to list who is going to be around etc. regards lin

2 3

WISP Technology - Trango?
by Jack Pivac 20 Jan '07

20 Jan '07

Hi all, Currently planning on setting up a community wireless project in South Taranaki. Range is looking to be up to 10km from the AP's. At the moment I'm looking at using Trango Radio Units [1] and was after thoughts/comments on this choice... Cheers, Jack [1] http://www.trangobroadband.com/

6 6

Re: [nznog] WISP Technology - Trango?
by Jack Pivac 19 Jan '07

19 Jan '07

Hi Jon, Thankyou for that advice, I will ensure to take it onboard. I'm interested to hear your thoughts on the pro's and con's of Trango vs Motorola Canopy? At the moment while price is always something to keep in mind, ease of administration is going to be top priority as I want to keep the running-round-fixing-it-after-install to a minimum. Kind Regards, Jack Jonathan Brewer wrote: > Hi Jack, > > There are two popular off the shelf systems currently sold in New Zealand. > Trango is one, Motorola Canopy is the other. Both are available in > .9/2.4/5.3/5.8GHz frequency bands, and both have unique advantages and > drawbacks. You could also go down the path of Mikrotik or StarOS, or other > of the myriad wireless ethernet based systems. You might find these less > expensive in terms of hardware, and you might find them more expensive in > terms of administration. > > Whatever you choose, please assume that you'll be sharing spectrum with > other users, and plan accordingly. > > Here is some unsolicited planning advice for the new WISP. (Attention! This > advice is not from any company I may work with/work for/own shares in/go > drinking with, etc., read on at your own risk, and may peace and harmony be > with you.) > > Both Trango Fox and Motorola Canopy subscriber units can be purchased with > small parabolic reflectors. This tightens the subscriber beam width from > 30-60 degrees (by default spraying unwanted radio everywhere) down to 9-10 > degrees. Please use these reflectors, and remember to turn the subscriber > unit radio power down accordingly. Your network will run better, and your > neighbors' networks will run better. > > With any system you choose, use external base station antennas. Buy a good > quality sector antenna (slotted waveguide made from drain pipe does not > qualify) and ensure you have it physically tilted down. If your most distant > customer is 10km away, please make sure you're not pointing your antenna > where someone 30km away is going to hear your noise. This will benefit you > too - your AP will be hearing your subscriber units and not SUs from the > next town over. > > Good luck. > > Cheers, > > Jon > > > >> -----Original Message----- >> From: Jack Pivac [mailto:email(a)delphinus.co.nz] >> Sent: Friday, 19 January 2007 3:12 p.m. >> To: nznog(a)list.waikato.ac.nz >> Subject: [nznog] WISP Technology - Trango? >> >> Hi all, >> >> Currently planning on setting up a community wireless project >> in South Taranaki. >> Range is looking to be up to 10km from the AP's. >> >> At the moment I'm looking at using Trango Radio Units [1] and >> was after thoughts/comments on this choice... >> >> >> Cheers, >> Jack >> >> [1] http://www.trangobroadband.com/ >> >> _______________________________________________ >> NZNOG mailing list >> NZNOG(a)list.waikato.ac.nz >> http://list.waikato.ac.nz/mailman/listinfo/nznog >> >> > > > >

1 0

Auckland/PN "road trip" bus cancelled
by Martin Kealey 19 Jan '07

19 Jan '07

Hi folks We haven't had enough people to warrant hiring a bus (needed about a dozen minimum). Unless another 5 people jump up immediately, the proposal won't proceed... We might still look at using a smaller vehicle, but it won't be as much fun. Sorry folks... I was really looking forward to doing this. -Martin PS: no, there won't be another chance next year because the people I was getting the bus from are retiring and selling their buses.

3 2

Shocking iptables performance
by Jasper Bryant-Greene 19 Jan '07

19 Jan '07

We currently have a pair of Linux iptables firewall boxes that are being replaced in a month's time with a pair of Cisco ASA firewalls. Recently during testing we noticed transfer rates through the Ciscos (attached to the same Cisco routers on the other side) is over 30x faster than through the iptables firewalls. I know that iptables isn't hugely fast, there's a reason you pay for Ciscos etc etc, but the resources I have read usually indicate that iptables slowness is related to massive rulesets. We have 2415 rules, which I don't consider to be *that* many... The boxes aren't heavily loaded (about 10% system, 90% idle), and have plenty of free memory. They aren't swapping. I've tested turning off logging, which had virtually no effect. Anybody encountered anything similar? Is it likely to simply be related to the number of rules? Cheers Jasper -- _________________________________________ http://www.digiweb.co.nz Webhosting, Dedicated Servers, E-commerce Phone: (64 3) 351 6713 Fax: (64 3) 351 6705 Free: 0800 DIGIWEB (0800 344-493) Email: jasper(a)digiweb.co.nz PLEASE NOTE: The information contained in this email message and any attached files may be confidential and subject to privilege. The views expressed may not necessarily be the official view of Digiweb New Zealand Limited. All technical advice and opinions are offered on a 'no-liability' basis. If you are not the intended recipient, you are notified that any use, disclosure or copying of this email is unauthorised. If you have received this email in error, please notify us immediately by reply email and delete the original. Thank you.

12 16

NZNOG 2007: DRAFT Network Systems Miniconf Programme
by Ewen McNeill 18 Jan '07

18 Jan '07

For those of you that are wondering which tutorial stream to go to, here is the _draft_ Network Systems Miniconf Programme (subject to change, but hopefully close to what it will be like on the day). Ewen -=- cut here -=- 08:00-09:00 - Registration 09:00-09:15 - Welcome 09:15-10:00 - Martin Kealey: From routers to Unix: shell tips for the network admin (45 minutes) 10:00-10:30 - Spare (BOF discussion on using Unix shell for automation?) 10:30-11:00 - Morning Tea 11:00-11:45 - Jonny Martin: Asterisk by Example... Doing useful VoIP things (45 minutes) 11:45-12:30 - Ewen McNeill: 42 hosts in 1U: Using virtual machines (45 minutes) 12:30-13:30 - Lunch 13:30-14:15 - Andrew McMillan: Using Debian packages for system administration (45 minutes) 14:15-15:00 - Matt Brown: Configuration Automation using CFengine (45 minutes) 15:00-15:30 - Server configuration management BOF 15:30-16:00 - Afternoon Tea 16:00-16:45 - Sam Sargeant: DNS registration services, and the .govt.nz 2LD (45 minutes) 16:45-17:15 - Martin Kealey: Mail debugging: how to talk to SMTP, POP & IMAP servers (30 minutes) 17:15-17:45 - Mail Server Best Practices BOF -=- cut here -=-

1 0

Re: [nznog] WISP Technology - Trango?
by Alex Hague 18 Jan '07

18 Jan '07

Hi Jack, You may also wish to check out http://meraki.net/ - this is a commercialization of the MIT Roofnet project. Will probably be a lot cheaper than Trango. Cheers, Alex -----Original Message----- From: Jack Pivac [mailto:email(a)delphinus.co.nz] Sent: Friday, 19 January 2007 3:12 p.m. To: nznog(a)list.waikato.ac.nz Subject: [nznog] WISP Technology - Trango? Hi all, Currently planning on setting up a community wireless project in South Taranaki. Range is looking to be up to 10km from the AP's. At the moment I'm looking at using Trango Radio Units [1] and was after thoughts/comments on this choice... Cheers, Jack [1] http://www.trangobroadband.com/

1 0

WISP Technology - Trango?
by Russell Tester 18 Jan '07

18 Jan '07

If you are setting up a community wireless project the very least you should consider is an open standard (such as 802.11) for the wireless. This will make it much easier for others to join / extend the project as well as provide neumorous other benefits! Russell Tester Serverworks Ltd Tel +64 3 9771750 Cell 021 478 611 -----Original Message----- From: Jack Pivac [mailto:email(a)delphinus.co.nz] Sent: Friday, 19 January 2007 3:12 p.m. To: nznog(a)list.waikato.ac.nz Subject: [nznog] WISP Technology - Trango? Hi all, Currently planning on setting up a community wireless project in South Taranaki. Range is looking to be up to 10km from the AP's. At the moment I'm looking at using Trango Radio Units [1] and was after thoughts/comments on this choice... Cheers, Jack [1] http://www.trangobroadband.com/ _______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog

1 0

Re: [nznog] Shocking iptables performance
by Mark Seward 18 Jan '07

18 Jan '07

On 1/19/07, Jasper Bryant-Greene <jasper(a)digiweb.net.nz> wrote: > [root(a)firewall1 root]# mii-tool > eth0: negotiated 100baseTx-FD flow-control, link ok > eth1: negotiated 100baseTx-FD flow-control, link ok > > Looks ok to me. Fixing it with mii-tool -F 100baseTx-FD makes no > difference to transfer rates. What devices are connected to each interface on this firewall and what do they say about duplex and collisions / otherwise errored packets? 100Mb NICs and switches are notorious for misbehaving in ways that cripple throughput as you describe. Mark.

1 0

DNS problems yesterday?
by Patrick Mchale 18 Jan '07

18 Jan '07

Hey There, I was wondering if anyone noticed an odd external DNS problem happening yesterday, the National Library's main website was affected for several hours. We could resolve internally but nothing from outside would get resolved. Nothing was changed on our DNS servers. Vodafone seemed to be affected also. Default Server: planet.natlib.govt.nz Address: 192.122.171.130 > server 210.55.131.76 Default Server: jupiter.natlib.govt.nz Address: 210.55.131.76 > www Server: jupiter.natlib.govt.nz Address: 210.55.131.76 Name: slbweb.natlib.govt.nz Address: 210.55.131.96 Aliases: www.natlib.govt.nz > server defiant.netgate.net.nz Default Server: defiant.netgate.net.nz Address: 202.37.245.17 > www.natlib.govt.nz Server: defiant.netgate.net.nz Address: 202.37.245.17 Name: slbweb.natlib.govt.nz Address: 210.55.131.96 Aliases: www.natlib.govt.nz > server reliant.net.nz *** Can't find address for server reliant.net.nz: Non-existent host/domain > server reliant.netgate.net.nz Default Server: reliant.netgate.net.nz Address: 202.37.245.20 > www.natlib.govt.nz Server: reliant.netgate.net.nz Address: 202.37.245.20 Name: slbweb.natlib.govt.nz Address: 210.55.131.96 Aliases: www.natlib.govt.nz > server 203.96.152.4 Default Server: rachel.paradise.net.nz Address: 203.96.152.4 > www.natlib.govt.nz Server: rachel.paradise.net.nz Address: 203.96.152.4 *** rachel.paradise.net.nz can't find www.natlib.govt.nz: Non-existent host/domain > server 202.73.198.15 Default Server: isdn1ldv.vodafone.co.nz Address: 202.73.198.15 > www.natlib.govt.nz Server: isdn1ldv.vodafone.co.nz Address: 202.73.198.15 *** isdn1ldv.vodafone.co.nz can't find www.natlib.govt.nz: Non-existent host/domain Cheers Patrick McHale National Library of New Zealand.

8 11

Re: [nznog] DNS problems yesterday?
by Patrick Mchale 18 Jan '07

18 Jan '07

Thanks for the responses, We kinda thought there was a bit of fiddling going on but at to who and finding a definitive answer, this problem may be a total mystery forever. We are though inquiring into one particular DNS provider to check if anything went astray yesterday. The report was very interesting and a very useful website for finding out about a particular sites DNS issues and security. I need to read up more on the info it presented and sort out some changes. Cheers Patrick McHale >>> "Patrick Mchale" <Patrick.Mchale(a)natlib.govt.nz> 19/01/2007 9:26 a.m. >>> Hey There, I was wondering if anyone noticed an odd external DNS problem happening yesterday, the National Library's main website was affected for several hours. We could resolve internally but nothing from outside would get resolved. Nothing was changed on our DNS servers. Vodafone seemed to be affected also. Default Server: planet.natlib.govt.nz Address: 192.122.171.130 > server 210.55.131.76 Default Server: jupiter.natlib.govt.nz Address: 210.55.131.76 > www Server: jupiter.natlib.govt.nz Address: 210.55.131.76 Name: slbweb.natlib.govt.nz Address: 210.55.131.96 Aliases: www.natlib.govt.nz > server defiant.netgate.net.nz Default Server: defiant.netgate.net.nz Address: 202.37.245.17 > www.natlib.govt.nz Server: defiant.netgate.net.nz Address: 202.37.245.17 Name: slbweb.natlib.govt.nz Address: 210.55.131.96 Aliases: www.natlib.govt.nz > server reliant.net.nz *** Can't find address for server reliant.net.nz: Non-existent host/domain > server reliant.netgate.net.nz Default Server: reliant.netgate.net.nz Address: 202.37.245.20 > www.natlib.govt.nz Server: reliant.netgate.net.nz Address: 202.37.245.20 Name: slbweb.natlib.govt.nz Address: 210.55.131.96 Aliases: www.natlib.govt.nz > server 203.96.152.4 Default Server: rachel.paradise.net.nz Address: 203.96.152.4 > www.natlib.govt.nz Server: rachel.paradise.net.nz Address: 203.96.152.4 *** rachel.paradise.net.nz can't find www.natlib.govt.nz: Non-existent host/domain > server 202.73.198.15 Default Server: isdn1ldv.vodafone.co.nz Address: 202.73.198.15 > www.natlib.govt.nz Server: isdn1ldv.vodafone.co.nz Address: 202.73.198.15 *** isdn1ldv.vodafone.co.nz can't find www.natlib.govt.nz: Non-existent host/domain Cheers Patrick McHale National Library of New Zealand. _______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog

1 0

Malware used to spam pump and dump scams
by matthew＠auscert.org.au 17 Jan '07

17 Jan '07

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Greetings all, As above - anyone aware of what particular bit of malware is being used to spam pump and dump scams? Also seeing similar usage for mule recruitment. Subjects may have the stock symbol CBFE for the stock P&D or "Managers opened - GAPFG Co" for the mule recruitment. Any feedback appreciated. Thanks for your time, - -- Matthew McGlashan -- Coordination Centre Team Leader | Hotline: +61 7 3365 4417 Australian Computer Emergency Response Team | Direct: +61 7 3365 7924 (AusCERT) | Fax: +61 7 3365 7031 The University of Queensland | WWW: www.auscert.org.au Qld 4072 Australia | Email: auscert(a)auscert.org.au -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) Comment: http://www.auscert.org.au/render.html?it=1967 Comment: http://www.auscert.org.au/render.html?it=1967 iQCVAwUBRa7T0Ch9+71yA2DNAQLKHAP/U0x1SudRh4BRtg+mxxkry6YifNUPFD+J 6sYjwErVf1N4N+Y6WN5zmU9JuXO+HqrMf79JiZ9eff3fC/2xd7jK1wJWr1GzNO5w jw8jZmO0QAC/2UzrEQuC9q4eDbogk/mHCLzSpg2qyzY6+cdN6IFGcnmgnkL0ycUk eTRO+t+6PQE= =AijR -----END PGP SIGNATURE-----

1 0

IGMP testing - thanks
by Ian Batterbee 16 Jan '07

16 Jan '07

Thanks all for the suggestions. That C source code, (the setting of theIP_ADD_MEMBERSHIP socket option in particular), led me to this rather useful document: http://tldp.org/HOWTO/Multicast-HOWTO-7.html ...which describes how it is the kernel's task to send IGMP out for sockets set as above, and not the application's problem, which explains why there aren't many apps around that send IGMP. And using 'tcpdump -n igmp', on the client end, I can see that it's doing what it should be doing :) Thanks.

1 0

Re: [nznog] IGMP test tools
by chris＠chrishellberg.com 16 Jan '07

16 Jan '07

Hi Ian, What about using a media application like vlc (videolan) and joining a multicast group? I think you might be able to run it in command line mode, if you don't have an X server listening. This'll trigger your IGMP membership reports and respond to group queries. /Chris ----- Original Message ---- From: Ian Batterbee <ian.batterbee(a)aut.ac.nz> To: nznog(a)list.waikato.ac.nz Sent: Tuesday, January 16, 2007 10:45:30 PM Subject: [nznog] IGMP test tools Hi all, I'm looking for some linux test tools that I can run that will send IGMP join commands and that will respond to IGMP queries (to keep the group alive), that I can use to prove or disprove a sparse mode pim configuration. There's such a blatent lack of matches for anything like this on google that I wonder if I'm overlooking some basic utility that is already included with most distros or is built into the kernel, but I can't come up with anything on that front either. Using a Cisco router or switch as a multicast group member is a possibility, but I'd rather use linux hosts if I can do so. _______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog

2 1

IGMP test tools
by Ian Batterbee 16 Jan '07

16 Jan '07

Hi all, I'm looking for some linux test tools that I can run that will send IGMP join commands and that will respond to IGMP queries (to keep the group alive), that I can use to prove or disprove a sparse mode pim configuration. There's such a blatent lack of matches for anything like this on google that I wonder if I'm overlooking some basic utility that is already included with most distros or is built into the kernel, but I can't come up with anything on that front either. Using a Cisco router or switch as a multicast group member is a possibility, but I'd rather use linux hosts if I can do so.

3 2

Notification of NZRR Database changes
by NZRR Database Notifications 15 Jan '07

15 Jan '07

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

1 0

Hello all & a word on SPEWS DNS blackhole
by Michael Fincham 14 Jan '07

14 Jan '07

Hi everyone... Just wondering if anyone knows how prevalent checking against the (supposedly now defunct) SPEWS SPAM DNS blackhole list remains among NZ operators? Reason I ask is that our netblock seems to be inadvertently (and/or incorrectly) listed as an Aussie porn spam sender, and with the general unpleasantness involved in dealing with SPEWS combined with the apparent departure of their admins, I don't see any real resolution to this other than waiting for people to stop using SPEWS on their mail servers... Currently it looks like iServe's mail server is still using SPEWS as are the mail servers used by ISP amuri.net. These are the only two I have encountered so far since moving our mail server to its new home (202.6.116.105) -- --Michael Fincham Unleash Technology Solutions

3 2

Re: [nznog] Hello all & a word on SPEWS DNS blackhole
by Michael Fincham 14 Jan '07

14 Jan '07

> We do not use SPEWS though if you would kindly provide onlist a list > > of your > netblock addresses, myself and I'm sure others will check them against the > BL's we use and if neccessary whitelist accordingly. Hooray. Nothing like a post like that to restore my faith in humanity :^) We've got: 202.6.116.0/23 and for a short time longer, 210.55.104.0/26 - although that is technically assigned to Maxnet, not directly to us, and we are phasing out mailing from addresses in that range. Here's hoping I didn't break the threading with this post - I need to turn off digest mode :) -- --Michael Fincham Unleash Technology Solutions

2 1

Bus/Train to NZNOG
by Joel van Velden 14 Jan '07

14 Jan '07

Hi all The idea was floated at last weeks Curry in Auckland about hiring a bus to travel to NZNOG, as there would possibly be quite a number of people between Auckland and Palmerston North interested in a less stressful and cheaper means of getting there. I have no idea of what numbers would be required at this stage or what the cost would be. Obviously it would be cheaper than flying, but take longer to get there. The other alternative might be to group-book the train, which has tables, not sure about AC power, you can walk around, is apparently newly-refurbished, but probably takes a little longer than a bus, and possibly more expensive. Is anyone is interested? Contacting me off-list would be best. Regards, Joel van Velden

4 3

NZNOG Programme.
by Jonny Martin 14 Jan '07

14 Jan '07

Right, Neil and I have pretty much sorted the NZNOG programme. It's reasonably flexible, with a bit of room to slot things in if any important last minute talks pop up etc. It takes into account any preferences for days to talk on I have received. A couple of additions that have come up recently are for InternetNZ to have a talking slot to cover anti-spam legislation, copyright bills, and general telecommunications issues and how they impact ISPs. There is also a NZ internet history session slotted in. Richard Wood is writing a book on the subject for InternetNZ so will use this slot to gain some more content for this. Can someone give this a quick sanity check please? Dave will be throwing this on the website when he gets back in the office this afternoon. Cheers, Jonny.

3 2

[NZNOG 07 Conference] Registrations Close Today!
by Mark Foster 14 Jan '07

14 Jan '07

A gentle reminder that today is the last day for Conference registrations. If you havn't yet, but intended to, now is the time! I would imagine that ~3pm today is as late as anyone would want to dare leave it, as after that details of the registrations need to go out to our hosts, etc. (Registrations post today will continue to be accepted, but theres no guarantees around the availability of accomodation, for example.) Cheers Mark.

1 1

Old Newby
by Allister Clarke 11 Jan '07

11 Jan '07

Hello. I am back. Last posted while at Waikato uni in 2002. Hello Lindsay if you are still around? Al.

1 0

Notification of NZRR Database changes
by NZRR Database Notifications 10 Jan '07

10 Jan '07

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:AS17746 descr: advertised to AS9560 by Orcon Internet Ltd - AS17746 members: 60.234.0.0/16^16-29, 202.150.96.0/19^19-29, 203.99.0.0/19^19-29, 202.126.192.0/20^20-29, 203.96.192.0/20^20-29, 219.88.128.0/20^20-29, 219.88.240.0/20^20-29, 210.54.56.0/21^21-29, 210.54.148.0/22^22-29, 210.55.12.0/22^22-29, 202.37.82.0/23^23-29, 202.0.151.0/24^24-29, 202.36.170.0/24^24-29, 202.37.19.0/24^24-29, 202.37.78.0/24^24-29, 202.37.173.0/24^24-29, 202.37.194.0/24^24-29, 202.49.187.0/24^24-29, 202.49.233.0/24^24-29, 202.49.246.0/24^24-29, 202.50.164.0/24^24-29, 202.50.167.0/24^24-29, 202.50.246.0/24^24-29, 202.174.160.0/24^24-29, 203.86.200.0/24^24-29, 210.54.12.0/24^24-29, 210.55.1.0/24^24-29, 210.55.8.0/24^24-29, 210.55.199.0/24^24-29, 202.27.188.128/25^25-29, 210.55.0.0/25^25-29, 210.55.180.128/26^26-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: karl.skewes(a)team.orcon.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20060728 source: NZRR REPLACED BY: route-set: AS9560:RS-ROUTES:AS17746 descr: advertised to AS9560 by Orcon Internet Ltd - AS17746 members: 60.234.0.0/16^16-29, 202.150.96.0/19^19-29, 203.99.0.0/19^19-29, 203.96.192.0/20^20-29, 219.88.128.0/20^20-29, 219.88.240.0/20^20-29, 210.54.56.0/21^21-29, 202.127.8.0/22^22-29, 210.54.148.0/22^22-29, 210.55.12.0/22^22-29, 202.37.82.0/23^23-29, 202.36.170.0/24^24-29, 202.37.19.0/24^24-29, 202.37.173.0/24^24-29, 202.37.194.0/24^24-29, 202.49.187.0/24^24-29, 202.49.233.0/24^24-29, 202.49.246.0/24^24-29, 202.50.167.0/24^24-29, 202.50.246.0/24^24-29, 202.174.160.0/24^24-29, 203.86.200.0/24^24-29, 210.54.12.0/24^24-29, 210.55.1.0/24^24-29, 210.55.8.0/24^24-29, 210.55.199.0/24^24-29, 202.27.188.128/25^25-29, 210.55.0.0/25^25-29, 210.55.180.128/26^26-29, 210.55.193.64/27^27-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: thomas.salmen(a)team.orcon.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20070111 source: NZRR

1 0

Notification of NZRR Database changes
by NZRR Database Notifications 09 Jan '07

09 Jan '07

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:AS9889 descr: advertised to AS9560 by Maxnet - AS9889 members: 123.100.64.0/18^18-29, 202.89.32.0/19^19-29, 203.89.160.0/19^19-29, 202.55.96.0/20^20-29, 210.55.100.0/22^22-29, 210.55.104.0/22^22-29, 192.138.251.0/24^24-29, 202.6.5.0/24^24-29, 202.6.116.0/24^24-29, 202.27.204.0/24^24-29, 202.36.70.0/24^24-29, 202.36.227.0/24^24-29, 202.37.72.0/24^24-29, 202.37.181.0/24^24-29, 202.49.141.0/24^24-29, 202.150.102.0/24^24-29, 203.97.42.0/24^24-29, 210.54.13.0/24^24-29, 210.54.142.0/24^24-29, 210.55.169.0/24^24-29, 210.55.214.0/24^24-29, 210.55.230.0/24^24-29, 203.167.219.56/29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: simon.allard(a)maxnet.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20061011 source: NZRR REPLACED BY: route-set: AS9560:RS-ROUTES:AS9889 descr: advertised to AS9560 by Maximum Internet Ltd - AS9889 members: 123.100.64.0/18^18-29, 202.89.32.0/19^19-29, 203.89.160.0/19^19-29, 202.55.96.0/20^20-29, 210.55.100.0/22^22-29, 210.55.104.0/22^22-29, 192.138.251.0/24^24-29, 202.6.5.0/24^24-29, 202.6.116.0/24^24-29, 202.27.204.0/24^24-29, 202.36.70.0/24^24-29, 202.36.227.0/24^24-29, 202.37.72.0/24^24-29, 202.37.181.0/24^24-29, 202.49.141.0/24^24-29, 202.150.102.0/24^24-29, 203.12.15.0/24^24-29, 203.97.42.0/24^24-29, 210.54.13.0/24^24-29, 210.54.142.0/24^24-29, 210.55.169.0/24^24-29, 210.55.214.0/24^24-29, 210.55.230.0/24^24-29, 203.167.219.56/29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: noc(a)maxnet.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20070111 source: NZRR

1 0

Greylisting New Zealand whitelist
by Simon Lyall 08 Jan '07

08 Jan '07

Andy wrote: > You can see the routes advertised at the APE and WIX on the pages: > but it does provide a couple of lists that by some definition are in NZ. I don't know what "some definition" is but by most definitions there are quite a few non-NZ IPs there ( Specificly things like 203.59.0.0/17 that ihug advertising on behalf of iinet). Anyway, you don't want random IPs home luser IPs for greylisting, you want IPs that are sending you non-spam email. -- Simon J. Lyall | Very Busy | Web: http://www.darkmere.gen.nz/ "To stay awake all night adds a day to your life" - Stilgar | eMT.

9 13

[NZNOG 07 Conference] Registrations over the Holiday Period
by Mark Foster 08 Jan '07

08 Jan '07

Folks, Unfortunately it seems there was a glitch in the backend of nznog.org during the Christmas period. Anyone who registered for NZNOG during the holiday period _and did not receive an emailed confirmation__ - could you please re-register via http://www.nznog.org. If you are in any way in doubt, could you register again anyway. We'll be watching for duplicates. Sorry for the trouble. Regards Mark

2 1

Greylisting New Zealand whitelist
by Gerard Creamer 08 Jan '07

08 Jan '07

Hi there, Is there a list of NZ networks or mail hosts that are considered OK for whitelisting in an email greylisting implementation? I realise that there are trust issues etc etc but what I want to do is have domestic mail from known providers (ie ISPs and hosting providers) essentially unhindered by the usual time delay of greylisting. We're using qmail, and the greylisting options are a bit basic. If there isn't a list would I be correct in assuming that moving to postfix and using postgrey with its database learning / remembering option would be a smart move? I realise that this is verging on off topic, but my googling has netted ziltch. Regards, Gerard

4 3

[NZNOG 07 Conference] Registration Reminder
by Mark Foster 06 Jan '07

06 Jan '07

Good morning all, I imagine many of you are back at work now, so it seems timely... *** NZNOG Accommodation *** If at all possible, would people intending to attend NZNOG 07 who are looking to take advantage of the Hostel Accommodation please book _this week_. If you are unable to book this week for some reason but would still like to make use of the Hostel facility, could you please fillin the contact-us form ( http://www.nznog.org/contact.html ) and let us know what your requirements are likely to be, in order that we can plan around it. I would encourage people to make their bookings sooner rather than later, as this will greatly assist us in the planning of this event. The timing is unfortunate, and for this we apologise, but remember that conference is not far away... ! For further info check out http://www.nznog.org Cheers all, Mark For the Org Committee...

1 0

Network Systems Miniconference
by Nigel Roberts 03 Jan '07

03 Jan '07

The link for this is broken on nznog.org: http://www.nznog.org/networksystemsminiconference.html So those in the know, what's this all about then? Happy new year, Nigel

4 3

Re: [nznog] Bus/Train to NZNOG
by Martin Kealey 03 Jan '07

03 Jan '07

Darn, I'm going to have to get to Curry more often... this is much the same idea I had. Count me in, plus 2 others from Ihug. How many people have you heard from so far? I ask because we're hoping we can get Ihug to pay for a bus, which means it'll be very cheap for the individuals travelling. If we get enough we'll get a coach (in which case it WILL be cheap, because I'll be driving). As I see it, the only snag is agreeing on dates & times; my preference would be for a longer period -- go for the first tutorial, back after taking a weekend tour of the town (and visiting friends) -- but it's not essential. -Martin > -----Original Message----- > From: Joel van Velden [mailto:joel(a)tpnz.co.nz] > Sent: Tuesday, 19 December 2006 12:01 > To: nznog(a)list.waikato.ac.nz > Subject: [nznog] Bus/Train to NZNOG > > Hi all > > The idea was floated at last weeks Curry in Auckland about > hiring a bus > to travel to NZNOG, as there would possibly be quite a number > of people > between Auckland and Palmerston North interested in a less > stressful and > cheaper means of getting there. > > I have no idea of what numbers would be required at this stage or what > the cost would be. Obviously it would be cheaper than flying, but take > longer to get there. > > The other alternative might be to group-book the train, which has > tables, not sure about AC power, you can walk around, is apparently > newly-refurbished, but probably takes a little longer than a bus, and > possibly more expensive. > > Is anyone is interested? > Contacting me off-list would be best. > > Regards, > Joel van Velden > > _______________________________________________ > NZNOG mailing list > NZNOG(a)list.waikato.ac.nz > http://list.waikato.ac.nz/mailman/listinfo/nznog > >

1 0

Re: [nznog] Telstra's Outage
by jdmwoolley＠ihug.co.nz 31 Dec '06

31 Dec '06

Steve Wray wrote: > Redundancy isn't really what I mean; more > forward-thinking. So if a TelstraClear engineer thought about it really hard the truck would have missed the fibre? Personally, I don't think the power of prayer is a valid network protection scheme. Though when I used to work there, it was useful on occassion ;) > From what I've heard out of Telstra people -- and > thats just the faults and 'helpdesk' people, the > attitude seems to be that a 'truck hitting a > pole' is not something that could have been > foreseen and that therefore there was no point in > having a contingency plan to deal with it. > > To me, this just seems wrong-headed. > > My question for Telstra is, was there a plan? How > well did it work out? > If they didn't have a plan or if it didn't work out > well, how are they going to address this in future? > And the answers I've been getting back from Telstra > people are rather disconcerting. A quick talk about how things are done in a Telco may be in order. 1. You need money to do everything. This includes laying fibre, writing plans and taking a toilet break. 2. There are two types of money to be spent - OPEX and CAPEX (OPerational expenditure and CAPital expenditure). 3. OPEX is evil. Accountants see it as a black hole that money is thrown down. It is not an investment. It is paying some guy for something you already own. OPEX is constantly cut. Many things that should be done as OPEX are classed as CAPEX by squinting your eyes and with the aid of smoke and mirrors. 4. CAPEX is ok - it is investing money in something with the expectation of a return at some point in time. Dig a hole, lay a cable, charge people to use it, eventually they've paid you more than it cost you to lay - this is CAPEX. You need a business case to spend CAPEX. This will consist of all likely and unlikely costs and revenues; and consequently a best, worst and expected-case return on investment. If the company thinks this is the best way to spend it's money it will do it. If it thinks it can make a larger profit or the same profit in a shorter time frame elsewhere it will do that. This is The Way It Works(tm) for a Telco and most businesses. If you can write a business case showing that getting 1000 monks in Tibet to pray for the safety of TelstrClear's network will turn a profit then they will do it. If prayer wasn't what you meant by "forward-thinking", and redundancy wasn't it then I'm at a loss. What else could they do? Not lay the fibre there? That location was probably the place that brought the best return on investment to justify the CAPEX. Could there have been a better place to put it - probably. Do companies have the time to second guess every decision made? Or will someone else beat you to the punch if you do that? Sorry for the massive rant, but berating a company, any company, for doing their best to fix a fault caused by some truck driver who was likely high on P at the time just seems like cynical people trying to complain about nothing to me. Sure, if you were one of the people affected it must've really sucked. In the end them's the breaks. On a lighter note, Merry Christmas to everyone - try to shake off the cynicism and anger that accumulated through the year at the beach this summer! Jonathan

5 5

Virus alert
by Lesley Walker 28 Dec '06

28 Dec '06

Looks like there's a new email worm/virus epidemic on the go. We've quarantined over 1100 incoming emails since 2pm, and we normally only get a trickle. ClamAV reports "postcard.exe contains Trojan.Downloader-388", and the subject line is "Happy New Year". Just what we all need. :-( Lesley W (Happy to be running Ubuntu)

3 2

Re: [nznog] Telstra's Outage
by Steve Wray 28 Dec '06

28 Dec '06

(sorry about lack of threading etc, I clipped the text out of the web-based archive) Jonathan wrote: > David Robinson wrote: >> >> "For a start, it takes more than two fibre cuts in the > North Island to >> disrupt us" >> >> And also remember back early in the year when one slip on the Hutt >> motorway took out all services in Wellington. >> >> What is so wrong with Telstra's network that single events can affect >> so many people, when supposable it takes more than two fibre cuts to >> disrupt them? > > This post you've quoted was related to the core network - > i.e. the bits that connect Wellington to Auckland etc. This > is a fault in the access network i.e. the bit that connects > Mary and Bob (or in this case Kandallah) to the core > network. NO operator has full redundancy in the access > network for residential services. What amazes me is that Telstra maintain that a truck hitting a pole was a *completely* unforseeable event and that even in retrospect they could not have been expected to have forseen that *one* *day* a truck would hit a 'single-point-of-failure pole' and that they could not have been expected to have planned for it. I ask you, is that really reasonable? I thought that engineers were the types of folk would look at diagrams of such a network and say: "well this pole is a single point of failure and its right by a road. Sooner or later its going to get hit by something, we'd better plan for that". I don't get the feeling that TC *had* planned for it... though maybe they did and if they hadn't planned for it we'd be disconnected till the new year... Insights anyone? Also, is there anywhere which keeps a log of outages experienced by NZ ISP's, how long they last etc? Thanks

4 4

Connection reliability (was Re: Telstra's Outage)
by Matthew Poole 21 Dec '06

21 Dec '06

On Thu, 21 Dec 2006, David Robb wrote: > On Thu, 21 Dec 2006, Simon Allard wrote: > >> You can't expect good uptimes and run your business which requires high >> availability internet on a $39.95 DSL account. > > Good, Fast, Cheap. Pick any two. > Where Good==Reliable, I assume? Since the relative goodness of broadband products for most consumers is often associated with their fastness and cheapness, with reliability (provided one can actually pass packets, of course) being an unconsidered factor. I do agree with Dean that we know you can't reasonably expect multiple nines of reliability from a residential service, but we, as geeks, have far different expectations from the average consumer. Plus, with NZ's high incidence of home-based businesses, how many users have actually had ANY choice of carrier until quite recently? I can probably get Woosh at home, and we have a Telecom landline. What are my other choices? TCL is still delivering over TCNZ's cable, so that's a non-starter. I could maybe get hooked into Vector's fibre, though I don't think it comes quite far enough down Great South Rd. And I'm in a better position than a lot of residential users, who can't get Woosh and aren't even close to someone's fibre network. When people have no choice, is it any wonder that they expect the earth for nothing? Nobody's telling them about the limitations of the one service they can afford, and nobody's offering them anything with better reliability for a reasonable price - what would one pay for a 2Mbps frame connection that, while unquestionably giving better upstream performance, comes in, at best, at half the downstream speed of a DSL connection? Many, many multiples of $40/month, that's for sure. Total no-brainer. We can sneer at the great unwashed, but the reality is that the marketroids aren't offering anything to fill the gaping void between DSL and frame/ISDN (does anyone even use ISDN for data anymore?). PS: Why pay metric boatloads for something like frame when Telecom won't give you credit if their network fails? Nobody got a cent out of them after the rat and the errant backhoe took out much of the country for several hours, so what's the point in handing them extra? Pardon the pun. -- Matthew Poole "Don't use force. Get a bigger hammer."

16 20

Re: [nznog] Telstra's Outage
by Simon Allard 20 Dec '06

20 Dec '06

Actually, I think it's the other way around. The reason NZ has 3rd rate broadband, is customers expect the world for free. You can't expect good uptimes and run your business which requires high availability internet on a $39.95 DSL account. I agree with everything Dean said, and I bet I am not the only one. -----Original Message----- From: John @ netTRUST [mailto:john(a)nettrust.net.nz] Sent: Thursday, 21 December 2006 11:19 a.m. To: nznog(a)list.waikato.ac.nz Subject: Re: [nznog] Telstra's Outage > Nothing used to piss me off more than the cable customer who used to > compain (without logging trouble tickets BTW) that thier home business > was losing money because their cable modem was down.... > > You buy a residential service - thats what you get. This type of arrogance from a NOC is why NZ has 3rd rate broadband. ADSL and cable are widely marketed to businesses and indeed business connections usually makes up the lions share of revenuw generated by these services. Let's hopen they keep you, and others with the same opinion, in the back room as far from customers as possible -or- put another way you should be using your l33t skills to substantally improve the reliability rather then having too much time on your hands digging for excuses. _______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog

13 17

Re: [nznog] Telstra's Outage
by jdmwoolley＠ihug.co.nz 20 Dec '06

20 Dec '06

John @ netTRUST wrote: > antedotal evidence Erm, perhaps you meant anecdotal? http://www.m-w.com/dictionary/antedotal http://www.m-w.com/dictionary/anecdotal (sorry, couldn't resist - beer!)

1 0

Telstra's Outage
by David Robinson 20 Dec '06

20 Dec '06

Hi, With Telstra's outage taking out the Northern and Western suburbs of Wellington. For what I gather it was a single truck crash bringing down the overhead wires. A single truck crash is a single point of failure, but I remember this email http://list.waikato.ac.nz/pipermail/nznog/2005-June/010158.html which says: "For a start, it takes more than two fibre cuts in the North Island to disrupt us" And also remember back early in the year when one slip on the Hutt motorway took out all services in Wellington. What is so wrong with Telstra's network that single events can affect so many people, when supposable it takes more than two fibre cuts to disrupt them? David

6 5

Re: [nznog] Telstra's Outage
by jdmwoolley＠ihug.co.nz 20 Dec '06

20 Dec '06

David Robinson wrote: > > "For a start, it takes more than two fibre cuts in the North Island to > disrupt us" > > And also remember back early in the year when one slip on the Hutt > motorway took out all services in Wellington. > > What is so wrong with Telstra's network that single events can affect > so many people, when supposable it takes more than two fibre cuts to > disrupt them? This post you've quoted was related to the core network - i.e. the bits that connect Wellington to Auckland etc. This is a fault in the access network i.e. the bit that connects Mary and Bob (or in this case Kandallah) to the core network. NO operator has full redundancy in the access network for residential services. If you want that, you need to pay through the nose to get a business service, even then most services give you only a single copper pair/fibre/cable to your premises which is still a single point of failure. Jonathan

6 5

Re: [nznog] Telstra's Outage
by Scott Weeks 19 Dec '06

19 Dec '06

--- dave.robinson(a)gmail.com wrote: From: "David Robinson" <dave.robinson(a)gmail.com> With Telstra's outage taking out the Northern and Western suburbs of Wellington. For what I gather it was a single truck crash bringing down the overhead wires. A single truck crash is a single point of failure, but I remember this email http://list.waikato.ac.nz/pipermail/nznog/2005-June/010158.html which says: "For a start, it takes more than two fibre cuts in the North Island to disrupt us" And also remember back early in the year when one slip on the Hutt motorway took out all services in Wellington. What is so wrong with Telstra's network that single events can affect so many people, when supposable it takes more than two fibre cuts to disrupt them? ------------------------------------------------------------------- Both fibers are hanging on the same poles? ;-) scott ps. to be ontopic... beer :) _______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog

1 0

NZNOG 2007 conference registrations are now open
by Jonny Martin 19 Dec '06

19 Dec '06

(Apologies for duplicates...) Hi All. The New Zealand Network Operators Group (NZNOG) is holding it's annual conference from January 31st to February 2nd 2007 in Palmerston North, New Zealand. Registrations are now open at http://www.nznog.org/registernow.html We encourage you to register early. NZNOG conferences are always lively, educational, and offer a great chance to network with peers from both within NZ and See you there! Jonny.

3 2

International problems via Global-Gateway
by robbie.gernandt＠apn.co.nz 19 Dec '06

19 Dec '06

Hi there Anyone experiencing problems with International connectivity via Global-Gateway? We can't get to www.google.co.nz and a few other sites at the moment I'm still waiting for a response from Global-gateway... PS! International traffic via TelsraClear is fine regards Robbie ******************************************************************************** NOTICE This email and any attachments are confidential. They may contain privileged information or copyright material. If you are not an intended recipient, you should not read, copy, use or disclose the contents without authorisation and we request you contact us at once by return email. Please then delete the email and any attachments from your system. We do not accept liability in connection with computer viruses, data corruption, delay, interruption, unauthorised access or unauthorised amendment. Any views expressed in this email and any attachments do not necessarily reflect the views of the company. ********************************************************************************

4 3

Notification of NZRR Database changes
by NZRR Database Notifications 18 Dec '06

18 Dec '06

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

1 0

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

17 Dec '06

Dear Colleague, This is to notify you that some object(s) in NZRR database which you either maintain or are listed as to-be-notified have been added, deleted or changed. These objects are used to configure the various NZIX route servers (http://nzix.net/) so you can expect the relevant servers to be reloaded in the near future. The reloading of the servers is staggered over a period of time so that if you are peering with both servers at an exchange, you can maintain at least one BGP session at all times and consequently a full set of routes. --- PREVIOUS OBJECT: route-set: AS9439:RS-ROUTES:AS9503 descr: advertised to AS9439 by FX Networks - AS9503 members: 131.203.0.0/16^16-29, 161.29.0.0/16^16-29, 161.65.0.0/16^16-29, 202.53.176.0/20^20-29, 202.174.160.0/20^20-29, 202.191.32.0/20^20-29, 210.48.160.0/20^20-29, 202.46.176.0/21^21-29, 202.78.240.0/21^21-29, 203.190.208.0/21^21-29, 202.59.4.0/22^22-29, 202.124.106.0/23^23-29, 192.88.85.0/24^24-29, 192.133.31.0/24^24-29, 202.20.97.0/24^24-29, 202.27.208.0/24^24-29, 202.36.119.0/24^24-29, 202.36.183.0/24^24-29, 202.46.190.0/24^24-29, 202.50.247.0/24^24-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: noc-minor(a)fx.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20061010 source: NZRR REPLACED BY: route-set: AS9439:RS-ROUTES:AS9503 descr: advertised to AS9439 by FX Networks - AS9503 members: 131.203.0.0/16^16-29, 161.29.0.0/16^16-29, 161.65.0.0/16^16-29, 202.53.176.0/20^20-29, 202.174.160.0/20^20-29, 202.191.32.0/20^20-29, 210.48.160.0/20^20-29, 202.46.176.0/21^21-29, 202.78.240.0/21^21-29, 203.190.208.0/21^21-29, 202.37.48.0/22^22-29, 202.59.4.0/22^22-29, 202.124.106.0/23^23-29, 192.88.85.0/24^24-29, 192.133.31.0/24^24-29, 202.20.97.0/24^24-29, 202.27.208.0/24^24-29, 202.36.119.0/24^24-29, 202.36.183.0/24^24-29, 202.46.190.0/24^24-29, 202.50.247.0/24^24-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: noc-minor(a)fx.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20061218 source: NZRR --- PREVIOUS OBJECT: route-set: AS9439:RS-ROUTES:AS23655 descr: advertised to AS9439 by Snap Internet Limited - AS23655 members: 132.181.0.0/16^16-29, 202.124.96.0/19^19-29, 203.86.192.0/20^20-29, 210.5.48.0/21^21-29, 202.49.92.0/22^22-29, 202.50.104.0/22^22-29, 202.50.124.0/22^22-29, 202.27.186.0/23^23-29, 202.36.178.0/23^23-29, 202.36.218.0/23^23-29, 202.36.220.0/23^23-29, 202.37.100.0/23^23-29, 202.37.124.0/23^23-29, 202.49.90.0/23^23-29, 202.49.120.0/23^23-29, 210.55.30.0/23^23-29, 210.55.206.0/23^23-29, 192.156.225.0/24^24-29, 202.36.170.0/24^24-29, 202.49.115.0/24^24-29, 202.49.125.0/24^24-29, 202.49.187.0/24^24-29, 202.50.117.0/24^24-29, 202.50.169.0/24^24-29, 203.96.112.0/24^24-29, 210.54.15.0/24^24-29, 210.55.4.0/24^24-29, 210.55.7.0/24^24-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: noc(a)snap.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20061019 source: NZRR REPLACED BY: route-set: AS9439:RS-ROUTES:AS23655 descr: advertised to AS9439 by Snap Internet Limited - AS23655 members: 132.181.0.0/16^16-29, 123.255.0.0/18^18-29, 202.124.96.0/19^19-29, 203.86.192.0/20^20-29, 210.5.48.0/21^21-29, 202.49.92.0/22^22-29, 202.50.104.0/22^22-29, 202.50.124.0/22^22-29, 202.27.186.0/23^23-29, 202.36.178.0/23^23-29, 202.36.218.0/23^23-29, 202.36.220.0/23^23-29, 202.37.100.0/23^23-29, 202.37.124.0/23^23-29, 202.49.90.0/23^23-29, 202.49.120.0/23^23-29, 210.55.30.0/23^23-29, 210.55.206.0/23^23-29, 192.156.225.0/24^24-29, 202.36.170.0/24^24-29, 202.49.115.0/24^24-29, 202.49.125.0/24^24-29, 202.49.187.0/24^24-29, 202.50.117.0/24^24-29, 202.50.169.0/24^24-29, 203.96.112.0/24^24-29, 210.54.15.0/24^24-29, 210.55.4.0/24^24-29, 210.55.7.0/24^24-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: mark.petrie(a)snap.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20061218 source: NZRR

1 0

Notification of NZRR Database changes
by NZRR Database Notifications 13 Dec '06

13 Dec '06

Dear Colleague, This is to notify you that some object(s) in NZRR database which you either maintain or are listed as to-be-notified have been added, deleted or changed. These objects are used to configure the various NZIX route servers (http://nzix.net/) so you can expect the relevant servers to be reloaded in the near future. The reloading of the servers is staggered over a period of time so that if you are peering with both servers at an exchange, you can maintain at least one BGP session at all times and consequently a full set of routes. --- PREVIOUS OBJECT: route-set: AS9560:RS-ROUTES:AS24324 descr: advertised to AS9560 by - AS24324 members: 124.157.64.0/19^19-29, 202.49.128.0/21^21-29, 218.185.224.0/21^21-29, 202.27.83.0/24^24-29, 202.36.75.0/24^24-29, 202.36.154.0/24^24-29, 202.37.168.0/24^24-29, 202.49.183.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: smc(a)bclnz.com mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20061018 source: NZRR REPLACED BY: route-set: AS9560:RS-ROUTES:AS24324 descr: advertised to AS9560 by Kordia (former BCL) - AS24324 members: 124.157.64.0/19^19-29, 202.68.80.0/20^20-29, 202.20.0.0/21^21-29, 202.49.16.0/21^21-29, 202.49.128.0/21^21-29, 218.185.224.0/21^21-29, 202.27.88.0/23^23-29, 192.173.17.0/24^24-29, 202.27.83.0/24^24-29, 202.27.90.0/24^24-29, 202.36.75.0/24^24-29, 202.36.137.0/24^24-29, 202.36.154.0/24^24-29, 202.36.173.0/24^24-29, 202.37.168.0/24^24-29, 202.37.197.0/24^24-29, 202.49.106.0/24^24-29, 202.49.158.0/24^24-29, 202.49.183.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: smc(a)kordia.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20061214 source: NZRR

1 0

Notification of NZRR Database changes
by NZRR Database Notifications 13 Dec '06

13 Dec '06

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

1 0

Outside broadcast of broadband march on Parliament
by Andy Linton 13 Dec '06

13 Dec '06

Richard has asked me to post this - mail him if you think it's off topic! http://www.r2.co.nz/meta/videonow.asx

3 2

APNIC fee structure
by Elly Tawhai 13 Dec '06

13 Dec '06

Hi, The APNIC fee structure is currently under review. As the fee structure is determined by the membership, we would like to encourage the NZNOG community to share their thoughts on our mailing list: wg-apnic-fees(a)apnic.net We would like to acknowledge the valuable contribution Andy has already made to the APNIC fee discussion mailing list. We are aware that the topic has recently been raised on the NZNOG mailing list, and we urge any interested parties to also provide input to the APNIC discussion. Contributing to the APNIC fees mailing list will enable you to participate in the official fee structure policy review process. We look forward to hearing from the NZNOG community. Regards, Elly APNIC

3 3

Notification of NZRR Database changes
by NZRR Database Notifications 13 Dec '06

13 Dec '06

Dear Colleague, This is to notify you that some object(s) in NZRR database which you either maintain or are listed as to-be-notified have been added, deleted or changed. These objects are used to configure the various NZIX route servers (http://nzix.net/) so you can expect the relevant servers to be reloaded in the near future. The reloading of the servers is staggered over a period of time so that if you are peering with both servers at an exchange, you can maintain at least one BGP session at all times and consequently a full set of routes. --- PREVIOUS OBJECT: route-set: AS9439:RS-ROUTES:AS23754 descr: Route set advertised to AS9439 by Cafenet-Free - AS23754 members: 198.48.3.192/26^26-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)citylink.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20061122 source: NZRR REPLACED BY: route-set: AS9439:RS-ROUTES:AS23754 descr: advertised to AS9439 by CityLink - AS23754 members: 198.48.0.0/22^22-29, 202.8.44.0/22^22-29, 202.7.6.0/23^23-29, 97.64.46.0/24^24-29, 198.32.71.0/24^24-29, 202.7.5.0/24^24-29, 203.118.144.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: rpsl-admin(a)nzix.net mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20061214 source: NZRR

1 0

Vodafone Issues
by Ernest Cunningham 12 Dec '06

12 Dec '06

Hi all, If somebody from Vodafones mac savy tech department could contact me off list I need some help with an issue I am having with my MacBook Pro + HSDPA Express Card (connections are fine, it is a more technical issue I have to do with unexplained network activity). Ernest Cunningham

2 1

XTRA mail servers
by Tom 12 Dec '06

12 Dec '06

on 7/12/2006 2:10 PM Simon wrote: > We are having some major issues over the past week when forwarding > mail to xtra. Mainly: > > - delivery temporarily suspended: connect to mta.xtra.co.nz > - connect to mta.xtra.co.nz[210.54.141.1]: server dropped connection > without sending the initial SMTP greeting > > Has anyone seen any of these issues and knows anything about them? I've been seeing similar issues, such as 2006-12-07 14:13:36 1Gs4Fp-0000gi-Vv SMTP error from remote mail server after initial connection: host mta.xtra.co.nz [210.54.141.1]: 421 Service not available 2006-12-07 14:13:36 1Gs4Fq-0000hO-Ut mta.xtra.co.nz [210.54.141.1] Connection refused 2006-12-07 12:03:52 1Gs4YH-0002YT-Qz mx1.xtra.co.nz [210.54.141.1] Connection reset by peer 2006-12-07 12:34:26 1Gs4Ll-00049D-Hg Remote host mx1.xtra.co.nz [210.54.141.1] closed connection in response to initial connection same issues, mail isn't getting delivered until a force mail queue run is done, clients are moaning...as usual :( tom

6 5

APNIC member survey: Still open for participation
by Elly Tawhai 12 Dec '06

12 Dec '06

Apologies for duplicate postings -------- Original Message -------- Subject: [apnic-talk] [Apnic-announce] APNIC Member Survey Date: Fri, 1 Dec 2006 12:00:02 +1000 From: dg(a)apnic.net Reply-To: apnic-talk(a)apnic.net To: apnic-announce(a)apnic.net Dear APNIC members and friends, As you may know, since 1999 the APNIC Executive Council has commissioned a regular survey of the APNIC community. Three surveys have been held so far, providing crucial input on APNIC's performance, development and future direction. Today we are pleased to announce the fourth survey of APNIC members and stakeholders. As in the past, this survey will be conducted independently from the APNIC secretariat, by the international firm KPMG. In this manner the process is assured to be neutral and objective, ensuring the highest quality result. Once again Dr John Earls of KPMG has developed the survey format and questions, with input from a large group of selected validators from the APNIC community. Dr Earls will receive and process all survey responses, and will guarantee the anonymity of all respondents. His report will be presented at the APNIC Annual Members Meeting in March 2007. We hope that you will participate in this important exercise, whether or not you are an APNIC member, or have participated in a previous APNIC survey. To express our appreciation for your time and effort, APNIC will provide a special reward to 3 randomly picked respondents. This reward, an APNIC meeting fellowship package, will include complimentary meeting registration plus USD $500.00 towards expenses, and can be used at either of the APNIC Open Policy Meetings in 2007. To participate in the survey, please visit the APNIC website and follow the instructions at: http://www.apnic.net/survey/2007 With sincere thanks in advance for your assistance, Paul Wilson Director General Akinori Maemura Chair, Executive Council. ________________________________________________________________________ Paul Wilson email: pwilson(a)apnic.net Director General, APNIC sip: apnic(a)voip.apnic.net http://www.apnic.net phone: +61 7 3858 3100 ________________________________________________________________________

1 0

IPv4 Exhaustion
by Philip D'Ath 11 Dec '06

11 Dec '06

I attended a very interesting presentation today by Tony Bain, one of the key IETF IPv6 chairs. He says that the rate of /8's being allocated is increasing exponentially at that moment (22 were allocated in 18 months [till July 2005], leaving just 64 available worldwide), and the prior estimate of when IPv4 address was going to be exhausted of 2020 has been revised to 2009 - as in three years away, and that IPv4 address space is likely to take on a much more commercially tradable value as it becomes very rare (like oil). For existing players in the market this doesn't mean much. However for expanding networks this is going to put a serious crimp in their plans. I polled a lot of players in the NZ market about 6 months ago and plans for IPv6 deployment were almost non-existent. There is an older article he wrote here: http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_8-3/ipv4. html We really need large commercial transit players like Global Gateway, TelstraClear, AT&T, UUNet, AsiaNetCom, and Sprint to start offering dual stack IPv6 connections to downstream ISPs, and for ISPs to start allowing clients to connection via IPv6, including via DSL. We really need to get critical infrastructure, like DNS, fully IPv6 enabled. The .nz domain isn't even reachable via IPv6 addresses yet. Now I know the shared registry system has IPv6 support now, but it is limiting in that you must still supply IPv4 addresses. You can't supply only IPv6 glue records. What happens when you can't get IPv4 addresses to use for glue? Also the majority of the registries out their offer very poor IPv6 support - as in no IPv6 connected DNS servers, and an inability to easily add IPv6 AAAA records.

14 23

Moving DNS providers - best practice.
by Simon Lyall 10 Dec '06

10 Dec '06

After a few recent instances I am getting sick of companies who transfer their DNS/Servers from one provider to another and then wonder why the old data is still cached by 3rd parties for 24 hours (or whatever). How do people feel about a "best practice" document on this that we could encourage people to follow ( perhaps the DNC could publish) for people moving their domain between providers. Just the basics like, dropping the TTLs, getting all the servers data in the right order etc? Similar to this: http://www.onr.com/services/data_center/colocation/transfer_tips.html Thoguhts? -- Simon J. Lyall | Very Busy | Web: http://www.darkmere.gen.nz/ "To stay awake all night adds a day to your life" - Stilgar | eMT.

14 21

NO contact list
by Gerard Creamer 10 Dec '06

10 Dec '06

There now appear to be two versions of this list. http://www.tcn.bowenvale.co.nz/content/view/49/40/ and http://www.usenet.net.nz/noc/index.html We have recently been assigned a public AS and I thought we should probably go on the list - as we're growing our things breaking will have a wider impact and other NOs might want to get hold of us. I have no issue with being woken up in the middle of the night when our things break. I have a strong objection to being woken up when someone elses things break. Personally I like the (mostly) unlinked anonymity of the list at usenet.net.nz, as it's less likely to be some kid who has no idea what an AS is calling at 2am because the gaming server they're using in suddenly unreachable (probably due to some reason other than our network being broken). Sure, the kid might ultimately pay my wages, but they're sure as hell not my customer... I emailed Simon Lyall yesterday to ask to go on the list at usenet.net.nz - is this still going to be considered the NO list? I know there's no king and all that jazz, but some direction for a newbie AS NO would be appreciated... For the record, here's our guff: Name Netspace Services Limited Domains netspace.net.nz ASN(s) 9733 Phone Number(s) +64 4 917 8098, 0800 NETSPACE (0800 638 772) Clueful People Gerard Creamer Direct Email noc(a)netspace.net.nz Hours Office Thanks, Gerard

5 5

XTRA mail servers
by Simon 07 Dec '06

07 Dec '06

Hi There :) We are having some major issues over the past week when forwarding mail to xtra. Mainly: - delivery temporarily suspended: connect to mta.xtra.co.nz - connect to mta.xtra.co.nz[210.54.141.1]: server dropped connection without sending the initial SMTP greeting Has anyone seen any of these issues and knows anything about them? I just trying to contact XTRA's administrators, but no response. I have had a good response back from the corporate side of XTRA, which is assuring. Regards and Thanks, Simon

11 12

Re: [nznog] NZNOG 2007: CFP: Network Systems Administration MiniConf
by Ewen McNeill 07 Dec '06

07 Dec '06

In message <20061122214213.8BB2A43E17(a)wat.la.naos.co.nz>, Ewen McNeill writes: > Call for Presentations for > NZNOG 2007: Network Systems Administration Mini-Conference >[....] >Some possible topics: >- Email servers and spam filtering techniques >[....] >Please send all proposals and questions to <talks(a)nznog.miniconf.org> At the risk of distracting everyone from arguing about responsible use of the list, I'd just like to point out that we still have room for a couple more talks at the Sysadmin Miniconf (on the first day of NZNOG 2007). And that we'd particularly welcome a proposal on, eg, best practices in running a mail server, or coping with the ever increasing volume of spam without rejecting all the legitimate mail. Proposals of other relevant talks (see the original CFP) are also welcomed, but be quick as we'd like to finalise the programme before Christmas so the speakers know what their summer homework is. Ewen

1 0

Re: [nznog] Xtra Email Administrators
by Martin Kealey 07 Dec '06

07 Dec '06

<metoo/> Given that (apparently) along with many other ISPs, Ihug also seem to have trouble with Xtra's inbound mailservers, perhaps I should say "could someone from Xtra please contact me ON list". (Yes we're all on fire trying to deal with Image Spam, but refusing valid mail just makes it worse...) -Martin -- Martin D Kealey, ihüg Systems Engineer

7 7

Xtra Email Administrators
by Simon 06 Dec '06

06 Dec '06

Would someone from the xtra email team please be able to contact me offlist? Much appreciated. Simon

20 35

INFO: Contact for xtra email admins
by Lin Nah 06 Dec '06

06 Dec '06

IN case this is lost amongst the flurry of flames, here's who to contact. It does appear lost as someone did ask again about 20 mins after Ted posted this (mind you I have only date stamps to go by). Lots of you are still flaming about it. May I also point out that Ted has in the past responded to this list stating he's happy to be contacted about this. eg http://list.waikato.ac.nz/pipermail/nznog/2005-August/010430.html http://list.waikato.ac.nz/pipermail/nznog/2005-January/009460.html regards lin ---------- Forwarded message ---------- Date: Thu, 7 Dec 2006 13:52:23 +1300 From: Ted Grenfell <Ted.Grenfell(a)telecom.co.nz> To: Simon <greminn(a)gmail.com>, nznog(a)list.waikato.ac.nz Subject: Re: [nznog] Xtra Email Administrators So as always, you're all welcome to call me direct if you've an Xtra query that you don't want to send via postmaster etc. -- Kind Regards, Ted Grenfell Online Services Mgr (acting) T +64 9 359 5854 (extn 93254) F +64 9 377 0781 M +64 27 443 5455 E ted.grenfell(a)telecom.co.nz W www.telecom.co.nz Level 11, Telecom House, 8 Hereford Street, Private Bag 92028, Auckland CBD, New Zealand ________________________________ "This communication, including any attachments, is confidential. If you are not the intended recipient, you should not read it - please contact me immediately, destroy it, and do not copy or use any part of this communication or disclose anything about it. Thank you. Please note that this communication does not designate an information system for the purposes of the Electronic Transactions Act 2002." > -----Original Message----- > From: Simon [mailto:greminn(a)gmail.com] > Sent: Thursday, 7 December 2006 12:42 p.m. > To: nznog(a)list.waikato.ac.nz > Subject: [nznog] Xtra Email Administrators > > Would someone from the xtra email team please be able to contact me > offlist? > > Much appreciated. > > Simon > > _______________________________________________ > NZNOG mailing list > NZNOG(a)list.waikato.ac.nz > http://list.waikato.ac.nz/mailman/listinfo/nznog _______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog

1 0

Re: [nznog] XTRA mail servers
by James Tolchard 06 Dec '06

06 Dec '06

On 07/12/2006, at 2:10 PM, Simon wrote: > We are having some major issues over the past week when forwarding > mail to xtra. Mainly: > > - delivery temporarily suspended: connect to mta.xtra.co.nz > - connect to mta.xtra.co.nz[210.54.141.1]: server dropped connection > without sending the initial SMTP greeting > > Has anyone seen any of these issues and knows anything about them? We are also seeing issues since late November. I emailed postmaster(a)xtra from elsewhere on 1 December, with no response so far. Typical log: Dec 7 14:19:26 skinner postfix/smtp[19226]: connect to mta.xtra.co.nz [210.54.141.1]: server dropped connection without sending the initial greeting (port 25) Typical telnet: $ telnet mta.xtra.co.nz 25 Trying 210.54.141.1... Connected to mta.xtra.co.nz. Escape character is '^]'. Connection closed by foreign host. $ The above is the most common behaviour, but apparently the connection does stay open properly from time to time (I had to send a bunch in a row to get this): Dec 7 14:28:34 skinner postfix/smtp[19322]: 187FFA9EF2B: to=<jkhhlkhkjh(a)xtra.co.nz>, relay=mta.xtra.co.nz[210.54.141.1], delay=27, status=bounced (host mta.xtra.co.nz[210.54.141.1] said: 550 Invalid recipient: <jkhhlkhkjh(a)xtra.co.nz> (in reply to RCPT TO command)) We also sometimes get "421 Service not available" before it drops the connection, and sometimes we even get connection refused. But when we're really lucky: 220 mta01.xtra.co.nz ESMTP server ready Thu, 7 Dec 2006 14:41:34 +1300 220 mta06.xtra.co.nz ESMTP server ready Thu, 7 Dec 2006 14:43:01 +1300 So, yeah, it looks like something might be up. Cheers -- James Tolchard System Administrator Christ's College Canterbury Phone: +64 3 364 6806

1 0

Null route on AT9812T router
by James Neil Tyson 06 Dec '06

06 Dec '06

If anyone knows how to add a null static route on an Allied Telesyn AT9812T router please email me offlist. I hate these damn things.

1 0

Re: [nznog] CHIX
by Stewart Fleming 05 Dec '06

05 Dec '06

DPE is also up and running in Dunedin and has first connections from January 2007. We requested a name change to DIX so that we could hook up CHIX with DIX, but the request was again denied.

2 1

Re: [nznog] Charging for IPv6
by Alex Hague 05 Dec '06

05 Dec '06

David Zanetti wrote: > I just don't see anything today I would bother demanding native v6 > transit for. So long as that't the case, I can live with tunnels for the > lab/play phase of things. How about an IPv6 wireless mesh as a reason to adopt... this is purely hypothetical, but say in the Auckland (/ Wellington / where ever) CBD there was an IPv6 wireless mesh, peered locally on the IPv6 peering exchange. New sources of local content may begin to appear such as bands providing live streams via the mesh of their gigs at the local bars / pubs / clubs etc. Current non-internet content providers such as radio stations might decide to provide their own streams. ISPs wishing to be WISPs would need to adopt v6. The benefits from what I know of IPv6 (which I'm still doing my homework on - so turn the flame jets down a notch) would be that all addresses on the mesh could be internet routable, and because of the local nature of the mesh most content would probably have local relevance rather than anything further a field, so with good local peering (which is relatively inexpensive) it would be completely feasible to deliver high speed local content. While I know that this is hypothetical, do you think it might provide an incentive for people to start using IPv6 to access the content? Furthermore, people might actually have a reason to request v6 from ISPs and ISPs wishing to provide services to mesh users would have a reason to go v6 ($$$)... Cheers, Alex -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.409 / Virus Database: 268.15.6/568 - Release Date: 4/12/2006

3 2

Any mail admins from sbc.sbcglobal.net on here?
by Paul Adshead 05 Dec '06

05 Dec '06

Please contact me off list.

1 0

CHIX
by Russell Tester 04 Dec '06

04 Dec '06

Does anyone know if CHIX is alive, was it ever alive or are there any plans to revive it in the future? Regards, Russell Tester Severworks Ltd

4 3

Re: [nznog] CHIX - who'd sign up tomorrow?
by Erin Salmon 04 Dec '06

04 Dec '06

Hi, Last I heard (about 2 years ago) it was to be hosted between Snap Internet and University of Canterbury. We have been eager to peer since before a chix was ruminated, and remain so. Unleash would be happy to put forth a small amount of rackspace for the purpose if others want to get some informal peering going. We also have tall buildings at our disposal for those out there who are wirelessly inclined. My motivation is to eliminate costly backhaul to other main centres and create a marketplace, if you will, for bandwidth down here. Christchurch could use some life breathed into its Internet. Expressions of interest? Erin -----Original Message----- From: "Nathan Ward" <nznog(a)daork.net> To: nznog(a)list.waikato.ac.nz Sent: 6/12/06 12:24 a.m. Subject: Re: [nznog] CHIX http://nzix.net/ The following exchanges are under construction: * Christchurch Internet Exchange * Southland Internet Exchange The "Who uses .." list shows nothing. Also, your sig is misspelt. On 6/12/2006, at 12:19 AM, Russell Tester wrote: > Does anyone know if CHIX is alive, was it ever alive or are there any > plans to revive it in the future? > > Regards, > > Russell Tester > Severworks Ltd > > _______________________________________________ > NZNOG mailing list > NZNOG(a)list.waikato.ac.nz > http://list.waikato.ac.nz/mailman/listinfo/nznog > > !DSPAM:22,457555d3143831749460768! > > > _______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog

1 0

FW:Electricity Reforms Act and Diesel Generators
by Jeremy Simons 02 Dec '06

02 Dec '06

Statement from TeamTalk Kordia supplies services to TeamTalk and we have a longstanding relationship with Kordia. They are one of our preferred suppliers and we are happy with our commercial arrangements. TeamTalk did not authorise the release of any Kordia material. The statement in question was sent to a junior member of TeamTalk's staff who contrary to company policy copied it to Jonathan Brewer of Araneo. We are treating the matter very seriously and are taking steps to ensure that such a breach of policy does not occur again. It is important to note that the item quoted was one paragraph from a complex 25-page document and was taken out of context. We value our relationship with Kordia and regret that this incident has occurred Jeremy Simons General Manager - Operations TeamTalk Limited ____________________________________________ Jeremy Simons General Manager - Operations TeamTalk Limited How Work Gets Done Phone: ++64 4 802 1478 Mobile: ++64 21 715 390 Fax: ++64 4 802 1490 <mailto:jsimons(a)teamtalk.co.nz> Mail to: jsimons(a)teamtalk.co.nz Disclaimer: The information in this electronic mail message is confidential and may be legally privileged. It is intended solely for the addressee. Access to this Internet electronic mail message by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. TeamTalk Limited accepts no responsibility for any effects this email message or attachments has on the recipient network or computer system.

7 7

Re: [nznog] FW: Electricity Reforms Act and Diesel Generators
by Dean Pemberton 29 Nov '06

29 Nov '06

> List moderator, is it possible to remove this list from the archives? I think we've been through this before, and the answer is no. There is all sorts of things in the archives that people would like to have removed. The answer has always been no. Infact way back in time there was a HUGE argument about it. Where people offered to just make alternative, REAL versions of the archives with the removed posts. It got really nasty. Dean (In his ad-hoc role as NZNOG historian)

5 4

FW: Electricity Reforms Act and Diesel Generators
by Jonathan Brewer 29 Nov '06

29 Nov '06

Hi Folks, I'm afraid my question may have breached a confidentiality agreement and we are getting angry phone calls from our supplier, so please disregard my email earlier today and delete any references to it from your inbox if that is possible. List moderator, is it possible to remove this list from the archives? Thanks, Jonathan Brewer > ______________________________________________ > From: Jonathan Brewer [mailto:jon.brewer(a)araneo.net.nz] > Sent: Thursday, 30 November 2006 9:42 a.m. > To: 'nznog(a)list.waikato.ac.nz' > Subject: Electricity Reforms Act and Diesel Generators > > Hi Folks, > > We telehouse at a number of facilities throughout New Zealand. We > typically provide our own batteries and contract for use of an on-site > diesel generator. At most sites we are not able to put in our own > generator. > > We were recently informed by Kordia (BCL) that they can no longer allow us > to use standby generator power at their sites due to the Electricity > Reforms Act. > > "BCL is deemed to be a Line Company under the Electricity Reforms Act and > therefore is unable to also be classified as a Generator. On that basis, > BCL is no longer able to provide you with Standby Generator Power for > upgrades to existing or new services." > > This effectively bars us from providing carrier grade telecommunications > services from BCL sites. > > One might say "use different sites" or "build your own towers", but these > are not options as these towers were built by the government before the > times of the Resource Management Act in unique locations where new towers > cannot be built. > > Can they do this? Are they doing this to everyone, or just us? > > Thanks, > > Jonathan Brewer

3 2

Re: [nznog] THE SKY IS FALLING ( was Re: IPv4 Exhaustion)
by Scott Weeks 29 Nov '06

29 Nov '06

: The past 10+ years of work on IPv6 nee IPng have taught : many lessons about what will and will not work (and more : importantly what will be accepted or not). Exactly. I NEED to multihome. I won't accept not being able to do that. No provider is going to be good enough that I trust ALL of my connectivity with them and no one else. That settles it right there. A protocol should not dictate my business practice. : ps - the 100-million number likely came from Alain Durand's : presentation "Managing 100+ Million IP Addresses" WRT "Managing 100+ Million IP Addresses", I see the following chart. (apologies for the formatting. It's on page 6 at www.nanog.org/mtg-0606/pdf/alain-durand.pdf >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Triple Play Effect on the Use of IP Addresses 2005 2006+ HSD only Triple Play Cable Modem 1(private only) 1 Home Computer/Router 1 1 eMTA (Voice adaptor) 0 1 – 2 Set Top Box (STB) 0 2 Total number of IP addresses(assume 2.5 1 – 2 8 – 9 STB per household) >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> What STB needs 2 IPs per box? The way we're doing it is one private IP per STB and one STB per television set, so that's 2-3 private IPs per household. One public IP per customer for Internet and we're not going for VoIP until later. Perhaps they have one STB per household no matter the number of television sets? Also, I see they have 20-30 ASNs. Are all 20M customers going to be in one AS? I wouldn't expect that. Finally, with VPRNs addresses could be reused. Just put the customers in different VPRNs and duplicate the address scheme. It's 'divide and conquer' methodology. I'm a noobie to VPRNs, so flame me if this isn't feasible. I have doused my flameproof underpants with beer, so I'm protected... :-) scott --- jejs+lists(a)sahala.org wrote: From: "joshua sahala" <jejs+lists(a)sahala.org> To: nznog(a)list.waikato.ac.nz Subject: [nznog] THE SKY IS FALLING ( was Re: IPv4 Exhaustion) Date: Wed, 29 Nov 2006 10:42:35 +1300 (NZDT) I find it slightly ironic that those screaming the loudest for IPv6 seem to have the most poorly researched assertions regarding the death of IPv4. (I am of course ignoring the obvious stupidity of things like IPv8/9/16) Who are the loudest proponents of IPv6? I tend to agree with the evaluation presented in Todd Underwood's blog: vendors, consultants, and the protocol designers themselves... (http://www.renesys.com/blog/2006/03/bashing_ipv6_at_telecomnext.shtml) If IPv6 is the answer, what was the question again? Perhaps it is time to accept that IPv6 is the wrong answer (or we need to start asking better questions), take the lessons learned from its failure, and start again. The past 10+ years of work on IPv6 nee IPng have taught many lessons about what will and will not work (and more importantly what will be accepted or not). There are many fundamental problems with the protocol that no amount of marketecture or hand-waving will fix; the least of which is a lack of end-users calling for a v6 address for their toaster/television/mechanical tie rack. These issue must be addressed, either in IPv6 (not likely), or in IPng-NG :) </soapbox> /joshua ps - the 100-million number likely came from Alain Durand's presentation "Managing 100+ Million IP Addresses" (it says ~20-million customers + kit == 100-million) -- A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools. - Douglas Adams - _______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog

9 15

Electricity Reforms Act and Diesel Generators
by Jonathan Brewer 29 Nov '06

29 Nov '06

Hi Folks, We telehouse at a number of facilities throughout New Zealand. We typically provide our own batteries and contract for use of an on-site diesel generator. At most sites we are not able to put in our own generator. We were recently informed by Kordia (BCL) that they can no longer allow us to use standby generator power at their sites due to the Electricity Reforms Act. "BCL is deemed to be a Line Company under the Electricity Reforms Act and therefore is unable to also be classified as a Generator. On that basis, BCL is no longer able to provide you with Standby Generator Power for upgrades to existing or new services." This effectively bars us from providing carrier grade telecommunications services from BCL sites. One might say "use different sites" or "build your own towers", but these are not options as these towers were built by the government before the times of the Resource Management Act in unique locations where new towers cannot be built. Can they do this? Are they doing this to everyone, or just us? Thanks, Jonathan Brewer

3 2

[Fwd: Re: Charging for IPv6]
by Gerard Creamer 29 Nov '06

29 Nov '06

On 30/11/2006 11:36 a.m., Andy Linton wrote: > For us having this address space from APNIC pushes us into the next tier of > membership and costs us an additional US$2500 a year. We have had a very > serious discussion here about returning this to APNIC and getting a reduction > in our charges. We recently got our first allocation from APNIC, and I was surprised that we had to choose 4 or 6 and had to pay more for both - as Andy says, are we being encouraged to do this or not? We are still small, so the additional cost is prohibitive. I would have thought there would be an associated IP6 allocation with every IP4 allocation, but I guess I was naive. Gerard

1 0

Re: [nznog] Charging for IPv6
by jdmwoolley＠ihug.co.nz 29 Nov '06

29 Nov '06

> A rough eyeball of the DSC stats for the last day or so > seems to indicate a little over 50% A queries and about > 10% AAAA. > Now THAT is an interesting statistic. Correct me if I'm wrong, but it means that a fair proportion of the queries coming in are TRYING to use v6, but presumably either aren't given a v6 address back or are unable to access it once obtained. Given that Vista will default to using v6 and fall back to v4 and the above statistic, one could surmise that if v6 was deployed, it would almost immediately get a fair portion of traffic. Indeed, when I tried pinging between two boxes at home that I had put Vista RC1 on I got a reply from a v6 address. Even though I'd specified the v4 address in the ping command Jonathan

1 0

Re: [nznog] THE SKY IS FALLING ( was Re: IPv4 Exhaustion)
by Scott Weeks 29 Nov '06

29 Nov '06

--- mjl(a)luckie.org.nz wrote:----------------------- From: Matthew Luckie <mjl(a)luckie.org.nz> > This was discussed earlier in the recent flurry of email on the > subject. Also, this is why I was asking about VPRNs. However, I > missed the part on why STBs need unique IPs or why they need 2 per > box. : http://www.nanog.org/mtg-0606/real/100million.ram : : the answer to the second question is about a minute in. ---------------------------------------------------- Geez, I'm trying to listen, but the quality is so bad I can hardly understand it. Does anyone know where a 'clean' copy of the speech is? scott

2 1

Re: [nznog] IPv4 Exhaustion
by Scott Weeks 29 Nov '06

29 Nov '06

> The major driver will be customer demand (read: $$$$), or the network : Funnily enough, I was reading this only yesterday: : : http://www.microsoft.com/technet/windowsvista/network/ipv6wv.mspx : : Have a look a the "Business Drivers" section especially. It's just funny numbers: "A recent report from NIST3 estimates that IPv6 could provide a US$10 billion per year benefit to the U.S. and the Japanese government estimates that IPv6 could generate a value of US$1.55 trillion." They give a reference to footnote 3. I searched footnote 3 (www.microsoft.com/technet/windowsvista/network/ipv6wv.mspx) for the word trillion and only get one match: "The 128-bit address header in IPv6, in contrast, provides approximately 3.4x1038 addresses, enough to assign trillions of addresses to each person now on earth or even to every square inch of the earth’s surface." So, to segway into pet peeve of mine, this is the reason to allocate very large (for example: allocation of IPv4 /8 blocks to everyone that asked in the not so distant past) blocks of v6 space. Heck, no one will EVER need that much IP space! <8-) Show me the money, not funny numbers... scott Oops, I forgot: beer :-)

18 27

Another Topic
by Peter Youngquest 29 Nov '06

29 Nov '06

Hey All I am personally bored with the IPV4-6 discussion, but while everyone is up and talking. What is everyones opinion in regard to PBT. Does this have a place, can it work happily as a feeder into an MPLS cloud or will it remove the need for MPLS. Rgds Peter

4 5

Re: [nznog] THE SKY IS FALLING ( was Re: IPv4 Exhaustion)
by Scott Weeks 29 Nov '06

29 Nov '06

--- richardn(a)cs.waikato.ac.nz wrote:---------------------- From: Richard Nelson <richardn(a)cs.waikato.ac.nz> While not wanting to spoil a good discussion with facts, there is a presentation on Comcast's plans for IPv6 from a recent NANOG here: http://www.nanog.org/mtg-0606/durand.html The summary is 20 million customers * 2.5 set-tops/customer * 2 IPs/box = 100million IPs. The network design requires unique IPs. The ran out of 10net in 2005 and have got a large part of 73net from ARIN. Their long term solution (new services = more IPs/customer) is IPv6. ----------------------------------------------------------- This was discussed earlier in the recent flurry of email on the subject. Also, this is why I was asking about VPRNs. However, I missed the part on why STBs need unique IPs or why they need 2 per box. scott

3 2

Re: [nznog] THE SKY IS FALLING ( was Re: IPv4 Exhaustion)
by Scott Weeks 29 Nov '06

29 Nov '06

--- aj(a)sneep.net wrote: From: Alastair Johnson <aj(a)sneep.net> Scott Weeks wrote: : Finally, with VPRNs addresses could be reused. Just put : the customers in different VPRNs and duplicate the address : scheme. It's 'divide and conquer' methodology. I'm a : noobie to VPRNs, so flame me if this isn't feasible. I have : doused my flameproof underpants with beer, so I'm protected... :-) :: Oh yes. This is a valid methodology. Also, you don't :: really need every subscriber to be uniquely addressed across :: your entire network - to the closest PoP site or Super-PoP site :: is sufficient, depending on your topology. :: :: Of course, from your Ethernet switch/DSLAM/FTTx node/whatever, :: you know where and who the subscriber is, so you're not reliant :: on IP addressing to authorize content access, either.... Thanks for the answer. So, it seems that all customer's STBs could be put in as many VPRNs as necessary to divide them into groups such that RFC1918 space is never exhausted and each customer could get one (or as many as they request) IP address that's publically routable for their internet connectivity. Thus, if the Very Giant ISPs designed their network in this manner, IPv4 would take them as far as they need. Yes? scott

3 2

Re: [nznog] THE SKY IS FALLING ( was Re: IPv4 Exhaustion)
by Scott Weeks 29 Nov '06

29 Nov '06

--- gerard(a)face.co.nz wrote: From: Gerard Creamer <gerard(a)face.co.nz> On 30/11/2006 7:41 a.m., Scott Weeks wrote: > Thanks for the answer. So, it seems that all customer's STBs could be put in as many VPRNs as necessary to divide them into groups such that RFC1918 space is never exhausted and each customer could get one (or as many as they request) IP address that's publically routable for their internet connectivity. Excuse my ignorance, but I'm having trouble finding useful information on what a VPRN (Virtual Private Remote Network) is - I could guess, based on my understanding of VPNs and NAT (as it appears to be used as a NAT replacement in context??), but that might be dangerous - any pointers to useful resources would be appreciated. ---------------------------------------------- My apologies, it stands for Virtual Private Routed Network. It's also known by many other names: RFC2547bis, IP Based Virtual Private Network; BGP/MPLS VPNs, Layer 3 VPNs, etc. Here's a link that looks good, though I haven't read it yet: www.spirentcom.com/documents/760.pdf scott

1 0

VPRN
by Gerard Creamer 29 Nov '06

29 Nov '06

On 30/11/2006 7:41 a.m., Scott Weeks wrote: > Thanks for the answer. So, it seems that all customer's STBs could be > put in as many VPRNs as necessary to divide them into groups such that > RFC1918 space is never exhausted and each customer could get one (or > as many as they request) IP address that's publically routable for > their internet connectivity. Excuse my ignorance again, but I'm having trouble finding useful information on what a VPRN (Virtual Private Remote Network) is - I could guess, based on my understanding of VPNs and NAT (as it appears to be used as a NAT replacement in context??), but that might be dangerous - any pointers to useful resources would be appreciated. Thanks, Gerard

1 0

Re: [nznog] THE SKY IS FALLING ( was Re: IPv4 Exhaustion)
by chris＠chrishellberg.com 28 Nov '06

28 Nov '06

My mail app doesn't do quoting sorry :( Peter, Agree, it's not black and white and you raise many pertinent questions. But one of the governing factors should be that a shortage of addresses[1] shouldn't restrict my network design. Not saying that you need to be wasteful. Just that NAT or some proxy equivalent shouldn't be the the solution to the address squeeze[1]. /Chris [1] maybe there is an address shortage, maybe there isn't..not terribly important for this point. ----- Original Message ---- From: Peter Youngquest <peter(a)mynetworks.co.nz> To: NZNOG <nznog(a)list.waikato.ac.nz> Sent: Wednesday, November 29, 2006 8:50:35 PM Subject: Re: [nznog] THE SKY IS FALLING ( was Re: IPv4 Exhaustion) As much as I find this topic boring :-) I doubt the answer is as black and white as some would like. Exposing the evolving subscriber premise to the "world" as such may reduce some problems but obviously increases others. I think it is fair to say alot of this is a balancing game. If you expose the subscriber premise to the service core (CSCF sort of area) you increase loading at the service core. This is not a good thing considering the stability of these pieces of the network at this stage. No vendor rants to that statement pls. IMS/SIP gateways are being developed that reduce Service Core loading but still how much of the home is exposed and how much isn't. Also there are a number of initiatives working currently to further define the home, how the CPE will interact with upstream - each other, QoS on the home segment etc etc If the subscriber premise is exposed to network and as Dave pointed out earlier there are a number of less than trivial considerations. Address management, device management, Security,introducing new devices to the home (another Dick Smith VoIP phone), point of demarcation etc etc. Also is there a need to expose all the devices globally. STBs would only need visibility to the service providers, VoIP phones to the SBC/SBG, fridge to the mail server :-D Also there are the various styles of network connectivity: - single pipe, MUX UNI that will have impact on the addressing schemes. To state that having "20million subs and requiring v6 for management" as a poster child for v6 is not a good look. There are other ways of approaching this - distribution and hierarchy to me sounds feasible. Last time I looked the sky is above us. What is happening is we are moving into an interesting time where the evolution of the subscriber premise will very much determine how the networks will look. Rgds Peter

3 2

Re: [nznog] THE SKY IS FALLING ( was Re: IPv4 Exhaustion)
by chris＠chrishellberg.com 28 Nov '06

28 Nov '06

I quite like the idea of being able to give every device behind a CPE a globally routable address. If there is a way to avoid NAT in the first place (also 1918 if that's how you're forced to do CPE management), v6 seems like an obvious alternative. Unless I'm mistaken that the RIR would happily allocate enough addresses for a /29 per household? The content is what drives the business decisions, so if the problem of accessing V4 content were magic-ed away, I'm not seeing why the bashing on V6. Should I come to more nznogs for the answer? /Chris ----- Original Message ---- From: Alastair Johnson <aj(a)sneep.net> To: nznog(a)list.waikato.ac.nz Sent: Wednesday, November 29, 2006 1:50:24 PM Subject: Re: [nznog] THE SKY IS FALLING ( was Re: IPv4 Exhaustion) Philip D'Ath wrote: > I don't know how more obvious it can be made. > > It's solving the looming problem of the IPv4 address pool being > exhausted in the next 3 to 6 years. > > Is not complete lack of Internet connectivity for new customers not a > good enough reason? I think the subject line says it all, on that particular topic. V6 seems to largely be a problem looking for a solution at this point in time. Need to support 25 million CPE devices? There are ways to do that, and many vendors are falling over themselves to help you. STBs? No problem. Triple/quad/quinta-plays? Got it covered. While I don't doubt that IPv6 will eventually become the widespread protocol, do you REALLY see that happening before 2020-ish? At which point the carriers will be able to make a premium selling v4 service, because by gosh there will be a lot of legacy networks out there needing it. But that's a completely separate topic. aj. _______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog

2 1

Posting and quoting
by Ian Batterbee 28 Nov '06

28 Nov '06

Hi everyone, It would be greatly appreciated if everyone posting would make the effort to remove any unnecessary quoted text from their reply before hitting send, as it is quite hard to spot the bits that are new when reading the list in digest form, with the same paragraphs repeating again and again at the end of postings. I realise some people are already doing this. Feel free to flame me for making a such a request, but address such flames to /dev/null Thanks

1 0

Re: [nznog] IPv4 Exhaustion
by Scott Weeks 28 Nov '06

28 Nov '06

--- andrew(a)etc.gen.nz wrote: : There are some DSL providers in some Asian countries : who are very interested in IPv6 because they've almost : exhausted 10/8 and weren't able to receive a public /8.[1] I can't imagine any Asian country's ISP that has used 16777216 IPs. Even so, they could still have 1114112 more IPs by using 192.168/16 and 172.16/12. Do you have a pointer to which provider this is? scott --- andrew(a)etc.gen.nz wrote: From: Andrew Ruthven <andrew(a)etc.gen.nz> To: nznog(a)list.waikato.ac.nz Subject: Re: [nznog] IPv4 Exhaustion Date: Wed, 29 Nov 2006 09:17:18 +1300 On Wed, 2006-11-29 at 08:12 +1300, Robert Gray wrote: > Philip D'Ath wrote: > > > I think the board of directors will flip, and tell you to find a > > solution, as not growing the business will not be considered an option. There are some DSL providers in some Asian countries who are very interested in IPv6 because they've almost exhausted 10/8 and weren't able to receive a public /8.[1] > I'd check that the board were happy that your customers won't be able to > host web sites or email servers that can be seen in v4 space or even run > p2p apps with v4 customers. > > When I looked at v6 some 10 years ago (I bought a book) it seemed to me > that the world all had to change together and that's not a cutover I can > see working too well. There is an education network in Catalonia that is IPv6 only[2]. They are using proxies to allow access to the traditional IPv4 Internet for specific applications. So there is no need for the entire world to cutover at once. And as Philip says, dual-stack is probably the method that a lot of companies that are transitioning will use. Cheers! [1] This was in March in this year, so they've probably exhausted it by now. [2] http://www.iepg.org/november2004/deploying_5000_ipv6_sites.pdf - This slideshow is from 2004, but Jordi was saying during March that they had rolled out the network. I haven't been able to find anything to back this up... -- Andrew Ruthven, Wellington, New Zealand At home: andrew(a)etc.gen.nz | This space intentionally | left blank. _______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog

2 1

Re: [nznog] THE SKY IS FALLING ( was Re: IPv4 Exhaustion)
by Scott Weeks 28 Nov '06

28 Nov '06

Thanks Joe, I must've misunderstood other mailing list's discussions. I thought small-fry ISPs were forced to have only one upstream and only the biggies were able to have more than one. I mean to multi-home to many different providers and an IX or two just like I do today, BTW. Thanks for setting me on the right thought-path and apologies to the list for any confusion. scott --- jabley(a)ca.afilias.info wrote: From: Joe Abley <jabley(a)ca.afilias.info> To: surfer(a)mauigateway.com Cc: <nznog(a)list.waikato.ac.nz> Subject: Re: [nznog] THE SKY IS FALLING ( was Re: IPv4 Exhaustion) Date: Tue, 28 Nov 2006 19:10:53 -0500 Scott! On 28-Nov-2006, at 18:07, Scott Weeks wrote: > : The past 10+ years of work on IPv6 nee IPng have taught > : many lessons about what will and will not work (and more > : importantly what will be accepted or not). > > Exactly. I NEED to multihome. I won't accept not being able to do > that. No provider is going to be good enough that I trust ALL of > my connectivity with them and no one else. That settles it right > there. A protocol should not dictate my business practice. You can multi-home in v6 in precisely the same way as you do in v4 if you're an ISP, under all RIR policies. This also goes for anybody who qualified for v4 PI assignments in the ARIN region (so, end users too, at least those who qualify for sufficient addresses to want to multi-home with PI v4 space). Other regions will presumably follow suit if their respective memberships want that to happen. The ability to multi-home using PA v6 space (as is commonly done in the v4 network) depends on deployed filtering practice. Currently, it doesn't work very well; however, if there was pressure from an actual customer base, it could well be that it would work more often. Neither of these require any additional protocol development or implementation effort, and both ought to be very familiar to anybody who is multi-homed using v4. Nothing until this sentence has had anything to do with shim6, for example. There are lots of arguments for why v6 won't/shouldn't/can't succeed as a replacement for v4, but multi-homing is barely one of them. Joe

1 0

Re: [nznog] IPv4 Exhaustion
by Scott Weeks 28 Nov '06

28 Nov '06

--- pid(a)ifm.net.nz wrote: From: Philip D'Ath <pid(a)ifm.net.nz> : : 17 million addresses is simply not enough for a country the size of the : US (and many others). They already have 100 million set top box's : deployed. :-) RFC1918 space is used within a network only. Not across networks. So, one network's IPTV customer can have the same STB IP address as another's when the RCF1918 space is used. You stream from your head-end to your customers only, so there's no need for public IP addressing. The traffic stays within a particular network. That is, unless you're talking about broadcasting on the internet to any STB in the world, or something like that. : Sorry, didn't realise you intended the email to be private. It seemed : of a nature that would interest other people in this thread. It's ok. I was unsure if everyone wanted to hear my non-beer-goggled responses. Responses are so much more interesting when typed while one's beer-goggled... ;-) scott -----Original Message----- From: Scott Weeks [mailto:surfer(a)mauigateway.com] : The release of IP based set top box's and : the like is going to make the problem worse. :: Do you mean for IPTV? I use 1918 space for them and :: a public IP for the DSL router. I haven't used extra :: IPs for triple play stuff. --- pid(a)ifm.net.nz wrote: From: Philip D'Ath <pid(a)ifm.net.nz> : : Think 20 years down the track. : : Mobile phones and IP set top boxes are likely to : EXCEED the size of the RFC1918 address space. : There simply wont be enough of it. Well, I guess I don't mind a private email going public... There're about 17891328 RFC1918 IPs. Let's say you're going to use 7891328 IPs for internal addressing issues. That still leaves 10 million STB IP addresses for your network. scott --- pid(a)ifm.net.nz wrote: From: Philip D'Ath <pid(a)ifm.net.nz> To: surfer(a)mauigateway.com Cc: nznog(a)list.waikato.ac.nz Subject: RE: [nznog] IPv4 Exhaustion Date: Wed, 29 Nov 2006 07:47:59 +1300 Think 20 years down the track. Mobile phones and IP set top boxes are likely to EXCEED the size of the RFC1918 address space. There simply wont be enough of it. -----Original Message----- From: Scott Weeks [mailto:surfer(a)mauigateway.com] Sent: Wednesday, 29 November 2006 7:24 a.m. To: Philip D'Ath Subject: Re: [nznog] IPv4 Exhaustion Hello, : The release of IP based set top box's and : the like is going to make the problem worse. Do you mean for IPTV? I use 1918 space for them and a public IP for the DSL router. I haven't used extra IPs for triple play stuff. scott --- pid(a)ifm.net.nz wrote: From: Philip D'Ath <pid(a)ifm.net.nz> To: jamie.baddeley(a)vpc.co.nz Cc: nznog(a)list.waikato.ac.nz Subject: Re: [nznog] IPv4 Exhaustion Date: Tue, 28 Nov 2006 21:33:07 +1300 The number of mobile devices with IP addresses now exceeds the number of traditional internet hosts. The gap between these two is growing. Mobile carriers have a more urgent need to use IPv6. The release of IP based set top box's and the like is going to make the problem worse. -----Original Message----- One question that I'd have is how much of that IPv4 space is used, planned to be used, or will never be used? And then I'd ask that same question to APNIC members in NZ who've got IPv4 assignments. And then I'd ask the cellular providers who shall remain unnamed that recently started announcing a /16 of v4 what their expectations of that v4 assignment lifetime is. That's 'the canary in the mine' IMHO. > > Notwithstanding, its still pretty hard to find an upstream provider offering > end to end IPv6 in or from NZ. > > Some of the debate on IPv4 exhaustion is pretty abstract, with some > alarmists saying the end is nigh, others saying that shortage of space will > lead to a secondary and valuable market for selling the space etc. > > It occurs to me that IPv6 is inevitable, its not a question of if, but a > question of when. I agree. Though there comes a point where the When is so far away, it starts to look like an If :-) > > To that end, is there an enthusiasm within the NOG for NZ to be leaders, or > are we content to be followers in the transition? That's a fair question. Whilst there's seems to be no real solid business case to deploy it in the short term or a reason to entertain the idea, frankly at this point in proceedings being a watcher, or follower as you put it, is probably a sensible thing to do for *some* operators. Now if we could convince *the rest of the world* to pay NZ to be a self contained, network of networks v6 test-bed that is an entirely different matter. That would certainly be worth leading on, and I'd be fairly excited about that. jamie _______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog _______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog _______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog

5 4

Re: [nznog] Fwd: RE: IPv4 Exhaustion
by Scott Weeks 28 Nov '06

28 Nov '06

--- ender(a)paradise.gen.nz wrote: From: David Robb <ender(a)paradise.gen.nz> On Tue, 28 Nov 2006, Scott Weeks wrote: > Comcast has all of them in one AS? Similarly, China will have all 1B > customers in one AS? If not, they can use the same 1918 space in each > one. Also, Comcast are not going to have 100M IPTV subscribers. I got > this from www.ncta.com/ContentView.aspx?contentId=2685 : Which is more complicated? Managing overlapping address blocks, : probably in a system which was never designed to do that, or : moving to a unique IP address per endpoint? (Also probably in a : system which was never designed for IPv6) I would think moving a network that supports many tens of millions of customers to IPv6 would be more complicated than readdressing 1918 space (probably via DHCP) to be non-overlapping. scott

1 0

Fwd: RE: IPv4 Exhaustion
by Scott Weeks 28 Nov '06

28 Nov '06

Oops, I didn't send this one to the list. scott --- pid(a)ifm.net.nz wrote: : Let's take a specific example. Comcast have 100 million : customers on their own, in their one single network. : This is a single operator. : : Lets assume that in 10 years time China has 1 billion : set top box's. : : RFC1918 is not big enough. IPv4 is barely big enough. : It has to go to IPv6. Comcast has all of them in one AS? Similarly, China will have all 1B customers in one AS? If not, they can use the same 1918 space in each one. Also, Comcast are not going to have 100M IPTV subscribers. I got this from www.ncta.com/ContentView.aspx?contentId=2685 "In 2001, partly in response to those demands, AT&T agreed to fold its cable systems with those of Comcast Corp., creating the largest ever cable operator with more than 22 million customers." "Cable’s high-speed Internet service ended the quarter (Third Quarter of 2005) with 24.3 million subscribers, and the number of digital cable customers had grown to 27.6 million." This is in the US only, though. scott -----Original Message----- From: Scott Weeks [mailto:surfer(a)mauigateway.com] Sent: Wednesday, 29 November 2006 8:59 a.m. To: Philip D'Ath Cc: nznog(a)list.waikato.ac.nz Subject: RE: [nznog] IPv4 Exhaustion --- pid(a)ifm.net.nz wrote: From: Philip D'Ath <pid(a)ifm.net.nz> : : 17 million addresses is simply not enough for a country the size of the : US (and many others). They already have 100 million set top box's : deployed. :-) RFC1918 space is used within a network only. Not across networks. So, one network's IPTV customer can have the same STB IP address as another's when the RCF1918 space is used. You stream from your head-end to your customers only, so there's no need for public IP addressing. The traffic stays within a particular network. That is, unless you're talking about broadcasting on the internet to any STB in the world, or something like that. : Sorry, didn't realise you intended the email to be private. It seemed : of a nature that would interest other people in this thread. It's ok. I was unsure if everyone wanted to hear my non-beer-goggled responses. Responses are so much more interesting when typed while one's beer-goggled... ;-) scott -----Original Message----- From: Scott Weeks [mailto:surfer(a)mauigateway.com] : The release of IP based set top box's and : the like is going to make the problem worse. :: Do you mean for IPTV? I use 1918 space for them and :: a public IP for the DSL router. I haven't used extra :: IPs for triple play stuff. --- pid(a)ifm.net.nz wrote: From: Philip D'Ath <pid(a)ifm.net.nz> : : Think 20 years down the track. : : Mobile phones and IP set top boxes are likely to : EXCEED the size of the RFC1918 address space. : There simply wont be enough of it. Well, I guess I don't mind a private email going public... There're about 17891328 RFC1918 IPs. Let's say you're going to use 7891328 IPs for internal addressing issues. That still leaves 10 million STB IP addresses for your network. scott --- pid(a)ifm.net.nz wrote: From: Philip D'Ath <pid(a)ifm.net.nz> To: surfer(a)mauigateway.com Cc: nznog(a)list.waikato.ac.nz Subject: RE: [nznog] IPv4 Exhaustion Date: Wed, 29 Nov 2006 07:47:59 +1300 Think 20 years down the track. Mobile phones and IP set top boxes are likely to EXCEED the size of the RFC1918 address space. There simply wont be enough of it. -----Original Message----- From: Scott Weeks [mailto:surfer(a)mauigateway.com] Sent: Wednesday, 29 November 2006 7:24 a.m. To: Philip D'Ath Subject: Re: [nznog] IPv4 Exhaustion Hello, : The release of IP based set top box's and : the like is going to make the problem worse. Do you mean for IPTV? I use 1918 space for them and a public IP for the DSL router. I haven't used extra IPs for triple play stuff. scott --- pid(a)ifm.net.nz wrote: From: Philip D'Ath <pid(a)ifm.net.nz> To: jamie.baddeley(a)vpc.co.nz Cc: nznog(a)list.waikato.ac.nz Subject: Re: [nznog] IPv4 Exhaustion Date: Tue, 28 Nov 2006 21:33:07 +1300 The number of mobile devices with IP addresses now exceeds the number of traditional internet hosts. The gap between these two is growing. Mobile carriers have a more urgent need to use IPv6. The release of IP based set top box's and the like is going to make the problem worse. -----Original Message----- One question that I'd have is how much of that IPv4 space is used, planned to be used, or will never be used? And then I'd ask that same question to APNIC members in NZ who've got IPv4 assignments. And then I'd ask the cellular providers who shall remain unnamed that recently started announcing a /16 of v4 what their expectations of that v4 assignment lifetime is. That's 'the canary in the mine' IMHO. > > Notwithstanding, its still pretty hard to find an upstream provider offering > end to end IPv6 in or from NZ. > > Some of the debate on IPv4 exhaustion is pretty abstract, with some > alarmists saying the end is nigh, others saying that shortage of space will > lead to a secondary and valuable market for selling the space etc. > > It occurs to me that IPv6 is inevitable, its not a question of if, but a > question of when. I agree. Though there comes a point where the When is so far away, it starts to look like an If :-) > > To that end, is there an enthusiasm within the NOG for NZ to be leaders, or > are we content to be followers in the transition? That's a fair question. Whilst there's seems to be no real solid business case to deploy it in the short term or a reason to entertain the idea, frankly at this point in proceedings being a watcher, or follower as you put it, is probably a sensible thing to do for *some* operators. Now if we could convince *the rest of the world* to pay NZ to be a self contained, network of networks v6 test-bed that is an entirely different matter. That would certainly be worth leading on, and I'd be fairly excited about that. jamie _______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog _______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog _______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog

2 1

Re: [nznog] IPv4 Exhaustion
by Scott Weeks 27 Nov '06

27 Nov '06

-----Original Message----- From: Scott Weeks [mailto:surfer(a)mauigateway.com] : The release of IP based set top box's and : the like is going to make the problem worse. :: Do you mean for IPTV? I use 1918 space for them and :: a public IP for the DSL router. I haven't used extra :: IPs for triple play stuff. --- pid(a)ifm.net.nz wrote: From: Philip D'Ath <pid(a)ifm.net.nz> : : Think 20 years down the track. : : Mobile phones and IP set top boxes are likely to : EXCEED the size of the RFC1918 address space. : There simply wont be enough of it. Well, I guess I don't mind a private email going public... There're about 17891328 RFC1918 IPs. Let's say you're going to use 7891328 IPs for internal addressing issues. That still leaves 10 million STB IP addresses for your network. scott --- pid(a)ifm.net.nz wrote: From: Philip D'Ath <pid(a)ifm.net.nz> To: surfer(a)mauigateway.com Cc: nznog(a)list.waikato.ac.nz Subject: RE: [nznog] IPv4 Exhaustion Date: Wed, 29 Nov 2006 07:47:59 +1300 Think 20 years down the track. Mobile phones and IP set top boxes are likely to EXCEED the size of the RFC1918 address space. There simply wont be enough of it. -----Original Message----- From: Scott Weeks [mailto:surfer(a)mauigateway.com] Sent: Wednesday, 29 November 2006 7:24 a.m. To: Philip D'Ath Subject: Re: [nznog] IPv4 Exhaustion Hello, : The release of IP based set top box's and : the like is going to make the problem worse. Do you mean for IPTV? I use 1918 space for them and a public IP for the DSL router. I haven't used extra IPs for triple play stuff. scott --- pid(a)ifm.net.nz wrote: From: Philip D'Ath <pid(a)ifm.net.nz> To: jamie.baddeley(a)vpc.co.nz Cc: nznog(a)list.waikato.ac.nz Subject: Re: [nznog] IPv4 Exhaustion Date: Tue, 28 Nov 2006 21:33:07 +1300 The number of mobile devices with IP addresses now exceeds the number of traditional internet hosts. The gap between these two is growing. Mobile carriers have a more urgent need to use IPv6. The release of IP based set top box's and the like is going to make the problem worse. -----Original Message----- One question that I'd have is how much of that IPv4 space is used, planned to be used, or will never be used? And then I'd ask that same question to APNIC members in NZ who've got IPv4 assignments. And then I'd ask the cellular providers who shall remain unnamed that recently started announcing a /16 of v4 what their expectations of that v4 assignment lifetime is. That's 'the canary in the mine' IMHO. > > Notwithstanding, its still pretty hard to find an upstream provider offering > end to end IPv6 in or from NZ. > > Some of the debate on IPv4 exhaustion is pretty abstract, with some > alarmists saying the end is nigh, others saying that shortage of space will > lead to a secondary and valuable market for selling the space etc. > > It occurs to me that IPv6 is inevitable, its not a question of if, but a > question of when. I agree. Though there comes a point where the When is so far away, it starts to look like an If :-) > > To that end, is there an enthusiasm within the NOG for NZ to be leaders, or > are we content to be followers in the transition? That's a fair question. Whilst there's seems to be no real solid business case to deploy it in the short term or a reason to entertain the idea, frankly at this point in proceedings being a watcher, or follower as you put it, is probably a sensible thing to do for *some* operators. Now if we could convince *the rest of the world* to pay NZ to be a self contained, network of networks v6 test-bed that is an entirely different matter. That would certainly be worth leading on, and I'd be fairly excited about that. jamie _______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog _______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog

2 1

Re: [nznog] IPv4 Exhaustion
by Philip D'Ath 27 Nov '06

27 Nov '06

Think 20 years down the track. Mobile phones and IP set top boxes are likely to EXCEED the size of the RFC1918 address space. There simply wont be enough of it. -----Original Message----- From: Scott Weeks [mailto:surfer(a)mauigateway.com] Sent: Wednesday, 29 November 2006 7:24 a.m. To: Philip D'Ath Subject: Re: [nznog] IPv4 Exhaustion Hello, : The release of IP based set top box's and : the like is going to make the problem worse. Do you mean for IPTV? I use 1918 space for them and a public IP for the DSL router. I haven't used extra IPs for triple play stuff. scott --- pid(a)ifm.net.nz wrote: From: Philip D'Ath <pid(a)ifm.net.nz> To: jamie.baddeley(a)vpc.co.nz Cc: nznog(a)list.waikato.ac.nz Subject: Re: [nznog] IPv4 Exhaustion Date: Tue, 28 Nov 2006 21:33:07 +1300 The number of mobile devices with IP addresses now exceeds the number of traditional internet hosts. The gap between these two is growing. Mobile carriers have a more urgent need to use IPv6. The release of IP based set top box's and the like is going to make the problem worse. -----Original Message----- One question that I'd have is how much of that IPv4 space is used, planned to be used, or will never be used? And then I'd ask that same question to APNIC members in NZ who've got IPv4 assignments. And then I'd ask the cellular providers who shall remain unnamed that recently started announcing a /16 of v4 what their expectations of that v4 assignment lifetime is. That's 'the canary in the mine' IMHO. > > Notwithstanding, its still pretty hard to find an upstream provider offering > end to end IPv6 in or from NZ. > > Some of the debate on IPv4 exhaustion is pretty abstract, with some > alarmists saying the end is nigh, others saying that shortage of space will > lead to a secondary and valuable market for selling the space etc. > > It occurs to me that IPv6 is inevitable, its not a question of if, but a > question of when. I agree. Though there comes a point where the When is so far away, it starts to look like an If :-) > > To that end, is there an enthusiasm within the NOG for NZ to be leaders, or > are we content to be followers in the transition? That's a fair question. Whilst there's seems to be no real solid business case to deploy it in the short term or a reason to entertain the idea, frankly at this point in proceedings being a watcher, or follower as you put it, is probably a sensible thing to do for *some* operators. Now if we could convince *the rest of the world* to pay NZ to be a self contained, network of networks v6 test-bed that is an entirely different matter. That would certainly be worth leading on, and I'd be fairly excited about that. jamie _______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog _______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog

1 0

[semi-ot] 0800 number ownership
by Jasper Bryant-Greene 27 Nov '06

27 Nov '06

Hi all, excuse the OT post, but not sure where else to turn. Not really something the helpdesks wish to help with. I currently have 0800 service provided by a company called Supra Limited, run by a certain airline-company-hoax-monger from Nelson [1]. I have serious concerns about the stability of this company. Given that this company does not answer its phones at any time of day or night, does not return emails, and the owner appears to be an 18-year-old who has disappeared off the face of the earth, is there a way to get my 0800 number back? It's still working, but as far as I'm concerned these guys could stop paying the bills at any time, and then it will be down while I sort things out. Any ideas, anyone that can help? Replies off-list. Once again, excuse the OT post. [1] http://www.google.co.nz/search?q=Lamar+Hargreaves should provide some hilarity. -- Jasper Bryant-Greene Director Album Limited jasper(a)albumltd.co.nz +64 21 708 334 / 0800 425 286 http://www.albumltd.co.nz/

3 2

Re: [nznog] Observation
by Martin Kealey 26 Nov '06

26 Nov '06

> > Just an observation: if ISPs are planning on introducing measures such > > as hardware spam filters that drop connections without the standard SMTP > > response code, or greylisting, or similar measures likely to have > > widespread effect, a simple post to this list detailing what is about to > > happen would probably save a lot of people a lot of time :) LARTs will be applied in appropriate places... :-) > And/or they could just answer postmaster@, like good little > mail admins. As of my arrival, that is being done here at Ihug; I apologise on behalf of my predecessors for not doing so. And now that I've cleared out the 119000 messages in the postmaster mailbox, you might get some answers. :-) -Martin

1 0

Observation
by Jasper Bryant-Greene 26 Nov '06

26 Nov '06

Just an observation: if ISPs are planning on introducing measures such as hardware spam filters that drop connections without the standard SMTP response code, or greylisting, or similar measures likely to have widespread effect, a simple post to this list detailing what is about to happen would probably save a lot of people a lot of time :) -- Jasper Bryant-Greene Director Album Limited jasper(a)albumltd.co.nz +64 21 708 334 / 0800 425 286 http://www.albumltd.co.nz/

2 1

Ihug mail admins
by TreeNet Admin 26 Nov '06

26 Nov '06

Could one of you in charge of the ihug mail servers please contact me. You may need to use abuse(a)treenetnz.com. AYJ Treehouse Networks Ltd.

3 2

Searching For ...
by David Farrar 26 Nov '06

26 Nov '06

To keep this slightly on-topic I'll promise to shout a beer at the next NZNOG Conference to anyone who can supply an e-mail address or other contact details for any of the people below. Rex Croft, ex Wai Uni Alan Marsden, ex pl.net Chris Tyler, ex-Xtra Peter Whimp, ex Tuia Patrick O'Brien, ex Domainz Tim & Nick Wood, ex Ihug Responses directly to me would be great. Many thanks David Farrar

3 2

Xtra mail admin
by Jasper Bryant-Greene 25 Nov '06

25 Nov '06

Can a mail admin from Xtra please contact me off list. Thanks -- Jasper Bryant-Greene Director Album Limited jasper(a)albumltd.co.nz +64 21 708 334 / 0800 425 286 http://www.albumltd.co.nz/

1 0

Re: [nznog] [Fwd: [Computer-support] Greylisting - one day after]
by Richard 23 Nov '06

23 Nov '06

Hi Russell Russell Fulton wrote: > This might be of interest to NZNOG members -- we have just > implemented grey listing for some addresses and the results have been > dramatic to say the least... Likewise, I've been using greylisting on my various domains, some of which have been receiving spam for many years, for a year or so now. The initial results were staggering, but in recent months I've started to get a trickle comiag through again - looks like the scum are searching for open relays again. Still, at least *that* problem isn't as big as it once was. Cheers Richard -- Richard Stevenson Freelance Unix geek 027 285 5873

7 7

ihug email
by Jasper Bryant-Greene 22 Nov '06

22 Nov '06

Could someone from ihug please contact me off-list regarding your email servers. Thanks -- Jasper Bryant-Greene Director Album Limited jasper(a)albumltd.co.nz +64 21 708 334 / 0800 425 286 http://www.albumltd.co.nz/

1 0

Government changes 2.3 GHz rules (and other bands)
by Ian McDonald 22 Nov '06

22 Nov '06

>From http://www.beehive.govt.nz/ViewDocument.aspx?DocumentID=27807 Government promotes wireless broadband investment The government's decision to reallocate spectrum for wireless broadband is another essential step in providing New Zealanders with better, more competitive access to broadband, says Communications Minister David Cunliffe. The decision will see spectrum in the 2.3 GHz range – suitable for such emerging wireless broadband applications as WiMAX – put up for auction in early 2007. While current right-holders do not have to give up their rights before they expire in 2010, some may choose to do so. It is expected that some of the 2.3 GHz spectrum could be available for development immediately after the auction, enabling early development of new broadband wireless services. Other decisions include making a 16MHz block as a "managed park" suitable for local and regional broadband operations, and developing policies to facilitate future use of other spectrum suitable for broadband wireless access (BWA). Along with the other recent measures to develop a vibrant, competitive ICT sector, the availability of additional broadband wireless spectrum will help unlock the potential of these new technologies, and aid New Zealand's economic transformation into an innovative and creative knowledge-based economy. "This decision reflects the fairest and most effective way of giving new and existing wireless broadband services providers the opportunity to develop this very important spectrum for broadband in New Zealand," Mr Cunliffe said. "BWA technology for this band is only just starting to become available. It is critical that we create the right conditions for its future deployment by giving a wide range of players the opportunity and the certainty they need to make a long-term investment." "How we run the process and allocate the rights will obviously be critical. A spectrum cap of 30 MHz per operator – which generally accepted industry standards indicate would be ample – would ensure at least three separate lots of spectrum will be on offer. Successful purchasers will be required to implement services within a specified period." This announcement reaffirms a 2004 government decision that existing rights would not be renewed when they expire in 2010. It follows public consultation in which industry feedback showed strong support for immediate reallocation of this spectrum. Background information: Summary of decisions Allocation of the 2.3 GHz spectrum Up to eight 10 MHz-wide management rights in the 2.3 GHz band will be reallocated by auction as soon as is practicable. A 16 MHz block will be made available as a managed spectrum park from 2010, or earlier if available. The Ministry of Economic Development expects to conduct the auction in the first quarter of 2007, with the following conditions: * a spectrum cap of 30 MHz per operator will apply for two years from the date of allocation; and * right-holders will be required to implement services within a specified period or face revocation. Subject to discussions with right-holders for early relinquishment of their current 2.3 GHz spectrum rights, some of the auctioned spectrum rights will be available for use immediately after the auction, while a smaller amount may not become available until current rights expire in 2010. Transition plan for 2.5 GHz spectrum Spectrum at 2.5 GHz is suitable for BWA technology in a manner equivalent to the 2.3 GHz band, but the band is currently used for television outside broadcasting (e.g. linking back to the studio). The ministry will develop and implement a transition plan, in consultation with stakeholders, to make this band available for future BWA allocation, once technical parameters have been determined at the World Radio Conference in 2007. New General User Licences at 5.4 GHz and 60 GHz The ministry intends to create a general user licence ('public park' licence) to facilitate the deployment of BWA services at 5.4 GHz by June 2007, subject to suitable protection for existing radar applications in the band. A general user licence will also be issued for BWA services at 60 GHz by June 2007, with conditions that balance technical neutrality with spectrum utility and efficiency. 70, 80, 90 GHz and other bands There are at present no policies for licensing of the 70, 80 and 90 GHz bands, but interest in using these bands for BWA is becoming evident. In anticipation of future demand, the ministry is developing policy proposals for these bands. There is some interest in other bands, including projected changes to the existing 921 to 929 MHz general user licence and the 10.5 GHz bands. Policy and technical work for these bands is continuing. -- Ian McDonald Web: http://wand.net.nz/~iam4 Blog: http://imcdnzl.blogspot.com WAND Network Research Group Department of Computer Science University of Waikato New Zealand

1 0

NZNOG 2007: CFP: Network Systems Administration MiniConf
by Ewen McNeill 22 Nov '06

22 Nov '06

Call for Presentations for NZNOG 2007: Network Systems Administration Mini-Conference In conjunction with the NZNOG 2007 conference (http://www.nznog.org/) we will be holding a network systems administration mini-conference on the tutorial day, Wednesday 2007-01-31. The NZNOG 2007 conference will be held in Palmerston North between 2007-01-31 and 2007-02-02. Registration at the NZNOG 2007 conference is a mandatory prerequisite for attendence at the mini-conference; we expect there will be no additional charge. The mini-conference's focus is on "Layer 7" issues to do with network and ISP operations, including providing customer services (email, DNS, etc) and provisioning and management topics. We are now seeking proposals for presentations at the mini-conference. We have openings for: - 50-60 minute full presentations - 25-30 minute half presentations - 5-10 minute "lightning talks" Presentations are expected to be directed at a technical audience, and focused on a system administration area related to network or ISP operations. Some possible topics: - Email servers and spam filtering techniques - DNS servers, registry systems - server security and best sysadmin practices in an internet provider environment - VoIP servers - network management / monitoring tools - RADIUS/TACACS - Netflow, routing, and traffic analysis tools - server tuning for high performance networking - provisioning tools - honeypots and other security techniques - network based storage - high availability and disaster recovery for network services - virtual machine technology for network services - *nix based routing and fire-walling - tools you need that you may not know about We are happy to discuss the suitability of other topics with intending presenters. Timeline: - proposals due by 2006-12-04 - selection advised by 2006-12-11 - draft program published by 2006-12-18 - presentations 2007-01-31 Please send all proposals and questions to <talks(a)nznog.miniconf.org> Simon Lyall and Ewen McNeill, Conveeners

1 0

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

21 Nov '06

Dear Colleague, This is to notify you that some object(s) in NZRR database which you either maintain or are listed as to-be-notified have been added, deleted or changed. These objects are used to configure the various NZIX route servers (http://nzix.net/) so you can expect the relevant servers to be reloaded in the near future. The reloading of the servers is staggered over a period of time so that if you are peering with both servers at an exchange, you can maintain at least one BGP session at all times and consequently a full set of routes. --- PREVIOUS OBJECT: aut-num: AS23754 as-name: NZRR-AS23754 descr: CityLink admin-c: RPA1-NZRR tech-c: RPA1-NZRR import: from AS9560 accept ANY AND NOT fltr-bogons export: to AS9560 announce AS23754 import: from AS9439 accept ANY AND NOT fltr-bogons export: to AS9439 announce AS23754 import: from AS24385 accept ANY AND NOT fltr-bogons export: to AS24385 announce AS23754 import: from AS7657 accept {0.0.0.0/0} export: to AS7657 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 20050801 source: NZRR REPLACED BY: aut-num: AS23754 as-name: NZRR-AS23754 descr: CityLink descr: WIX peering at '202.7.0.32' descr: see Citylink RT job #7338 admin-c: RPA1-NZRR tech-c: RPA1-NZRR import: from AS9560 accept ANY AND NOT fltr-bogons export: to AS9560 announce AS23754 import: from AS9439 accept ANY AND NOT fltr-bogons export: to AS9439 announce AS23754 import: from AS24385 accept ANY AND NOT fltr-bogons export: to AS24385 announce AS23754 import: from AS7657 accept {0.0.0.0/0} export: to AS7657 announce AS23754 import: from AS9439 accept ANY AND NOT fltr-bogons export: to AS9439 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 20061122 source: NZRR --- PREVIOUS OBJECT: route-set: AS9439:RS-ROUTES:AS23754 descr: advertised to AS9439 by CityLink - AS23754 members: 198.48.0.0/22^22-29, 202.8.44.0/22^22-29, 202.7.6.0/23^23-29, 97.64.46.0/24^24-29, 198.32.71.0/24^24-29, 202.7.5.0/24^24-29, 203.118.144.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 20061116 source: NZRR REPLACED BY: route-set: AS9439:RS-ROUTES:AS23754 descr: Route set advertised to AS9439 by Cafenet-Free - AS23754 members: 198.48.3.192/26^26-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)citylink.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20061122 source: NZRR

1 0

Re: [nznog] [Fwd: Re: [Fwd: [Computer-support] Greylisting - one day after]
by Russell Fulton 15 Nov '06

15 Nov '06

> > -------- Original Message -------- > Subject: Re: [nznog] [Fwd: [Computer-support] > Greylisting - one day after] > Date: Thu, 16 Nov 2006 14:08:46 +1300 > From: Jasper Bryant-Greene <jasper(a)albumltd.co.nz> > Organisation: Album Limited > To: Richard <richard(a)alternativeuniverse.net> > CC: Russell Fulton <r.fulton(a)auckland.ac.nz>, > nznog(a)list.waikato.ac.nz > References: <2.1.1-1800921-393-A-OEWW(a)222.154.242.106> > > > > Question around this - we are currently looking at > implementing it, but > we have three mail servers behind a load balancer. The software we're > looking at is postgrey (as we use Postfix), but it uses BDB database > files... > > Which means each server has an individual greylisting > database, and mail > could potentially (worst case) be bounced three times before getting > through. Has anyone solved this problem already? With BDB database files you really don't have a lot (any?) options. You could put the file on a NFS share and let all 3 servers use it, but locking issues and overall BDB speed would probably impact your performance greatly. The best solution in this case would be to bring a new server that will run a real database (MySQL, Oracle). If you use a greylisting package that supports these databases (gld does), you can have all servers point to this server and use one central greylisting database. Of course, this way you have a single point of failure (while gld will allow e-mails to flow if the database is not available, you loose greylisting, of course). We at the moment have local MySQL databases on each server. This means that the greylisting delay could be longer, but as we don't have real load balancer but use DNS only, so far this hasn't been the case. As far as I can see, actually, remote MTAs always came back to exactly the same server they were originally greylisted on, probably due to DNS caching on their side. Bojan

2 1