- NZNOG - lists.nznog.org

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

05 Aug '08

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

21 33

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

04 Aug '08

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

1 0

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

04 Aug '08

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

4 4

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

03 Aug '08

Dear Colleague, This is to notify you that one or more objects in which you are designated for notification have been modified in the NZRR routing registry database. These objects are used to configure the various NZIX route servers (http://nzix.net/) so you can expect the relevant servers to be reloaded in the near future. The reloading of the servers is staggered over a period of time so that if you are peering with both servers at an exchange, you can maintain at least one BGP session at all times and consequently a full set of routes. Diagnostic output: ------------------------------------------------------------ --- PREVIOUS OBJECT: route-set: AS9560:RS-ROUTES:AS23755 descr: Route set advertised to AS9560 by MediaNET - AS23755 members: 202.7.4.0/22^22-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: rpsl-admin(a)nzix.net mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20060222 source: NZRR REPLACED BY: route-set: AS9560:RS-ROUTES:AS23755 descr: advertised to AS9560 by Citylink - AS23755 members: 202.7.4.0/22^22-29, 202.8.44.208/28^28-29, 202.8.47.64/28^28-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: dylan(a)citylink.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20080804 source: NZRR ------------------------------------------------------------

1 0

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

03 Aug '08

Dear Colleague, This is to notify you that one or more objects in which you are designated for notification have been modified in the NZRR routing registry database. These objects are used to configure the various NZIX route servers (http://nzix.net/) so you can expect the relevant servers to be reloaded in the near future. The reloading of the servers is staggered over a period of time so that if you are peering with both servers at an exchange, you can maintain at least one BGP session at all times and consequently a full set of routes. Diagnostic output: ------------------------------------------------------------ --- PREVIOUS OBJECT: route-set: AS9439:RS-ROUTES:AS23755 descr: Route set advertised to AS9439 by MediaNET - AS23755 members: 202.7.4.0/22^22-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: rpsl-admin(a)nzix.net mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20060222 source: NZRR REPLACED BY: route-set: AS9439:RS-ROUTES:AS23755 descr: advertised to AS9439 by Citylink - AS23755 members: 202.7.4.0/22^22-29, 202.8.44.208/28^28-29, 202.8.47.64/28^28-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: dylan(a)citylink.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20080804 source: NZRR ------------------------------------------------------------

1 0

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

03 Aug '08

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

2 1

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

02 Aug '08

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

3 2

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

31 Jul '08

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

1 0

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

30 Jul '08

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

13 13

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

30 Jul '08

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

1 0

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

30 Jul '08

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

3 2

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

28 Jul '08

Dear Colleague, This is to notify you that one or more objects in which you are designated for notification have been modified in the NZRR routing registry database. These objects are used to configure the various NZIX route servers (http://nzix.net/) so you can expect the relevant servers to be reloaded in the near future. The reloading of the servers is staggered over a period of time so that if you are peering with both servers at an exchange, you can maintain at least one BGP session at all times and consequently a full set of routes. Diagnostic output: ------------------------------------------------------------ --- PREVIOUS OBJECT: route-set: AS9560:RS-ROUTES:AS24324 descr: advertised to AS9560 by Kordia - AS24324 members: 118.148.0.0/15^15-29, 124.157.64.0/18^18-29, 58.84.224.0/20^20-29, 114.134.0.0/20^20-29, 116.89.224.0/20^20-29, 202.56.32.0/20^20-29, 202.68.80.0/20^20-29, 203.144.32.0/20^20-29, 116.90.128.0/21^21-29, 117.104.176.0/21^21-29, 123.108.144.0/21^21-29, 202.20.0.0/21^21-29, 202.49.16.0/21^21-29, 202.49.128.0/21^21-29, 202.56.48.0/21^21-29, 202.137.240.0/21^21-29, 218.185.224.0/21^21-29, 202.6.116.0/23^23-29, 202.27.88.0/23^23-29, 202.65.160.0/23^23-29, 202.174.190.0/23^23-29, 203.110.28.0/23^23-29, 192.173.17.0/24^24-29, 202.21.130.0/24^24-29, 202.27.34.0/24^24-29, 202.27.83.0/24^24-29, 202.27.90.0/24^24-29, 202.36.75.0/24^24-29, 202.36.137.0/24^24-29, 202.36.154.0/24^24-29, 202.36.173.0/24^24-29, 202.37.168.0/24^24-29, 202.37.197.0/24^24-29, 202.49.158.0/24^24-29, 202.49.183.0/24^24-29, 203.30.174.0/24^24-29, 203.92.25.0/24^24-29, 203.171.4.0/24^24-29, 203.174.26.0/24^24-29, 203.97.62.200/29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: smc(a)kordia.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20080630 source: NZRR REPLACED BY: route-set: AS9560:RS-ROUTES:AS24324 descr: advertised to AS9560 by Kordia Ltd - AS24324 members: 118.148.0.0/15^15-29, 124.157.64.0/18^18-29, 58.84.224.0/20^20-29, 114.134.0.0/20^20-29, 116.89.224.0/20^20-29, 202.56.32.0/20^20-29, 202.68.80.0/20^20-29, 203.144.32.0/20^20-29, 116.90.128.0/21^21-29, 117.104.176.0/21^21-29, 123.108.144.0/21^21-29, 202.20.0.0/21^21-29, 202.49.16.0/21^21-29, 202.49.128.0/21^21-29, 202.56.48.0/21^21-29, 202.137.240.0/21^21-29, 218.185.224.0/21^21-29, 202.6.116.0/23^23-29, 202.27.88.0/23^23-29, 202.49.164.0/23^23-29, 202.65.160.0/23^23-29, 202.174.190.0/23^23-29, 203.110.28.0/23^23-29, 192.173.17.0/24^24-29, 202.21.130.0/24^24-29, 202.27.34.0/24^24-29, 202.27.83.0/24^24-29, 202.27.90.0/24^24-29, 202.36.75.0/24^24-29, 202.36.137.0/24^24-29, 202.36.154.0/24^24-29, 202.36.173.0/24^24-29, 202.37.168.0/24^24-29, 202.37.197.0/24^24-29, 202.49.158.0/24^24-29, 202.49.168.0/24^24-29, 202.49.183.0/24^24-29, 203.30.174.0/24^24-29, 203.92.25.0/24^24-29, 203.171.4.0/24^24-29, 203.174.26.0/24^24-29, 203.97.62.200/29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: praneel.prasad(a)kordia.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20080729 source: NZRR ------------------------------------------------------------

1 0

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

28 Jul '08

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

1 0

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

28 Jul '08

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

1 0

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

28 Jul '08

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

1 0

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

28 Jul '08

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

1 0

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

27 Jul '08

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

2 1

DNS Cache Poisoning
by Paul McKitrick 27 Jul '08

27 Jul '08

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

4 4

Christchurch 5756
by Stan Rivett 27 Jul '08

27 Jul '08

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

1 0

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

24 Jul '08

Dear Colleague, This is to notify you that one or more objects in which you are designated for notification have been modified in the NZRR routing registry database. These objects are used to configure the various NZIX route servers (http://nzix.net/) so you can expect the relevant servers to be reloaded in the near future. The reloading of the servers is staggered over a period of time so that if you are peering with both servers at an exchange, you can maintain at least one BGP session at all times and consequently a full set of routes. Diagnostic output: ------------------------------------------------------------ --- PREVIOUS OBJECT: route-set: AS9439:RS-ROUTES:AS64595 descr: Route set advertised to AS9439 by Learning Media - AS64595 members: 210.55.244.160/28^28-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: gary(a)learningmedia.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20040702 source: NZRR REPLACED BY: route-set: AS9439:RS-ROUTES:AS64595 descr: advertised to AS9439 by LearningMedia - AS64595 members: 203.167.252.112/28^28-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: terry.moore(a)learningmedia.co.nz notify: gary.jarvis(a)learningmedia.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20080725 source: NZRR ------------------------------------------------------------

1 0

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

24 Jul '08

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

1 0

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

24 Jul '08

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

1 0

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

23 Jul '08

Dear Colleague, This is to notify you that one or more objects in which you are designated for notification have been modified in the NZRR routing registry database. These objects are used to configure the various NZIX route servers (http://nzix.net/) so you can expect the relevant servers to be reloaded in the near future. The reloading of the servers is staggered over a period of time so that if you are peering with both servers at an exchange, you can maintain at least one BGP session at all times and consequently a full set of routes. Diagnostic output: ------------------------------------------------------------ --- PREVIOUS OBJECT: route-set: AS9439:RS-ROUTES:AS65531 descr: Route set advertised to AS9439 by parliament - AS65531 members: 202.22.16.0/23^23-29, 202.22.18.0/24^24-29, 202.22.23.0/24^24-29, 202.22.30.0/24^24-29, 202.49.210.0/24^24-29, 202.49.213.0/24^24-29, 203.97.200.0/24^24-29, 203.97.232.80/28^28-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: john.howell(a)parliament.govt.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20051102 source: NZRR REPLACED BY: route-set: AS9439:RS-ROUTES:AS65531 descr: advertised to AS9439 by Parliamentary Service - AS65531 members: 202.22.16.0/21^21-29, 202.49.208.0/21^21-29, 202.22.24.0/22^22-29, 202.22.28.0/23^23-29, 202.22.30.0/24^24-29, 203.97.232.80/28^28-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: John.Howell(a)parliament.govt.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20080724 source: NZRR ------------------------------------------------------------

1 0

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

23 Jul '08

Dear Colleague, This is to notify you that one or more objects in which you are designated for notification have been modified in the NZRR routing registry database. These objects are used to configure the various NZIX route servers (http://nzix.net/) so you can expect the relevant servers to be reloaded in the near future. The reloading of the servers is staggered over a period of time so that if you are peering with both servers at an exchange, you can maintain at least one BGP session at all times and consequently a full set of routes. Diagnostic output: ------------------------------------------------------------ --- PREVIOUS OBJECT: route-set: AS9560:RS-ROUTES:AS17705 descr: advertised to AS9560 by InspireNet - AS17705 members: 203.114.128.0/18^18-29, 121.79.192.0/19^19-29, 192.138.251.0/24^24-29, 203.92.25.0/24^24-29, 210.7.46.0/24^24-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: brenden(a)staff.inspire.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20080411 source: NZRR REPLACED BY: route-set: AS9560:RS-ROUTES:AS17705 descr: advertised to AS9560 by InspireNet - AS17705 members: 203.114.128.0/18^18-29, 121.79.192.0/19^19-29, 140.200.248.0/22^22-29, 192.138.251.0/24^24-29, 203.92.25.0/24^24-29, 203.174.26.0/24^24-29, 210.7.46.0/24^24-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: brenden(a)staff.inspire.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20080724 source: NZRR ------------------------------------------------------------

1 0

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

23 Jul '08

Dear Colleague, This is to notify you that one or more objects in which you are designated for notification have been modified in the NZRR routing registry database. These objects are used to configure the various NZIX route servers (http://nzix.net/) so you can expect the relevant servers to be reloaded in the near future. The reloading of the servers is staggered over a period of time so that if you are peering with both servers at an exchange, you can maintain at least one BGP session at all times and consequently a full set of routes. Diagnostic output: ------------------------------------------------------------ --- PREVIOUS OBJECT: route-set: AS9439:RS-ROUTES:AS17705 descr: advertised to AS9439 by InspireNet - AS17705 members: 203.114.128.0/18^18-29, 121.79.192.0/19^19-29, 192.138.251.0/24^24-29, 203.92.25.0/24^24-29, 210.7.46.0/24^24-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: brenden(a)staff.inspire.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20080410 source: NZRR REPLACED BY: route-set: AS9439:RS-ROUTES:AS17705 descr: advertised to AS9439 by InspireNet - AS17705 members: 203.114.128.0/18^18-29, 121.79.192.0/19^19-29, 140.200.248.0/22^22-29, 192.138.251.0/24^24-29, 203.92.25.0/24^24-29, 203.174.26.0/24^24-29, 210.7.46.0/24^24-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: brenden(a)staff.inspire.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20080724 source: NZRR ------------------------------------------------------------

1 0