- NZNOG - lists.nznog.org

[RIR] Deprecation of ip6.int Scheduled for June 1, 2006
by bmanning＠vacation.karoshi.com 01 Jun '06

01 Jun '06

On Thu, Mar 02, 2006 at 09:19:56AM -0500, Member Services wrote: > In August 2005, RFC 4159 Deprecation of ip6.int was published as Best > Current Practice. This RFC noted that maintenance of ip6.int is no > longer required and that the Regional Internet Registries adopt a > schedule for cessation of ip6.int. All the RIRs have agreed to deprecate > ip6.int on June 1, 2006. Further note that ARIN no longer modifies any > of the zones it administers under ip6.int effective December 7, 2005. > > Ginny Listman > Director of Engineering > American Registry for Internet Numbers and: On Tue, 16 May 2006 11:09:10 +0200, Andrei Robachevsky wrote: > Below is the proposed plan of ip6.int deprecation. Could you please > check if it is detailed enough to be properly coordinated, or if it > misses something. > > Andrei > > ip6.int deprecation plan > ------------------------- > > Advance Work: > > Contact Bill Manning at bmanning(a)vacation.karoshi.com and > hostmaster(a)ep.net before the 25th of May and ask him to schedule the > following: > > o June 1st 12:00 GMT: Remove all delegations within the 2.ip6.int zone. > > RIR Plan (common) > > o May 30th 12:00 GMT: Drop TTL on authoritative NS records within the > ip6.int zones to 3600. > > o June 1st 12:00 GMT: All delegations within the ip6.int zone are > removed. No RIR Action needed, other than checking. > > o June 1st 13:00 GMT - 23:59 GMT: All RIR's remove their respective > ip6.int zones from their servers. ........ while i noted the following: not all the zones or data in ip6.int are being removed.... so no, i am not changing the TTLs. the delegations that the RIR's have asked to be removed are scheduled for automatic removal. I will check on the process when i wake up roughly 3.5 hours later. I will be glad to send you email at that time to confirm removal. --bill ....... that being said, the RIR requested delegations have been removed from the IP6.INT zone. what remains is: # dig 2.ip6.int. axfr @::1 ; <<>> DiG 9.3.2 <<>> 2.ip6.int. axfr @::1 ; (1 server found) ;; global options: printcmd 2.ip6.int. 86400 IN SOA dot.ep.net. hostmaster.ep.net. 1999061700 10800 900 604800 129600 2.ip6.int. 86400 IN NS z.ip6.int. 2.ip6.int. 86400 IN NS dot.ep.net. 2.ip6.int. 86400 IN NS flag.ep.net. 0.0.1.0.0.2.ip6.int. 86400 IN NS z.ip6.int. 0.0.1.0.0.2.ip6.int. 86400 IN NS dot.ep.net. 0.0.1.0.0.2.ip6.int. 86400 IN NS flag.ep.net. 1.0.1.0.0.2.ip6.int. 86400 IN NS z.ip6.int. 1.0.1.0.0.2.ip6.int. 86400 IN NS dot.ep.net. 1.0.1.0.0.2.ip6.int. 86400 IN NS flag.ep.net. 2.0.0.2.ip6.int. 86400 IN NS z.ip6.int. 2.0.0.2.ip6.int. 86400 IN NS dot.ep.net. 2.0.0.2.ip6.int. 86400 IN NS flag.ep.net. 2.ip6.int. 86400 IN SOA dot.ep.net. hostmaster.ep.net. 1999061700 10800 900 604800 129600 ;; Query time: 4 msec ;; SERVER: ::1#53(::1) ;; WHEN: Thu Jun 1 06:44:20 2006 ;; XFR size: 14 records (messages 14) --bill

1 0

Notification of NZRR Database changes
by NZRR Database Notifications 31 May '06

31 May '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:AS18353 descr: Route set advertised to AS9439 by HDS - AS18353 members: 202.55.96.176/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: kenneth.liew(a)hdsnz.com mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20051006 source: NZRR REPLACED BY: route-set: AS9439:RS-ROUTES:AS18353 descr: advertised to AS9439 by Revera - AS18353 members: 202.55.99.0/24^24-29, 202.55.96.176/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: Marc.Nienkemper(a)revera.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20060601 source: NZRR

1 0

FW: GGIS Service Message : Major
by Paul Adshead 31 May '06

31 May '06

FYI -----Original Message----- From: noc(a)global-gateway.net.nz [mailto:noc(a)global-gateway.net.nz] Sent: Thursday, 1 June 2006 00:28 To: global-gateway outage contacts Subject: GGIS Service Message : Major GGIS Backbone Update Global-Gateway Internet is currently experiencing service disruption which began at 21:40 hrs, 31/05/06date You are likely to experience major international congestion of your service until this problem is resolved. A cable fault has been identified in the USA near San Francisco. Currently, we are have no expected time for restoration. GGIS apologises for any inconvenience to you or your customers, and an update will follow within 2 hours. Logged by Andrew Murray on Thu Jun 1 00:27:59 2006

3 2

Police Hoax Email
by Keith Davidson 30 May '06

30 May '06

Just a heads up for anyone not aware of this... Keith Davidson www.police.govt.nz/news/release/2445.html Hoax police email 10:03am 31 May 2006 A hoax email is circulating within New Zealand which purports to be a notification from NZ Police. The email has this subject line - "Notification from Police New_Zealand" The email is clearly a hoax but is causing some concern in the public with callers contacting police for clarification. The email suggests that recipients are "under suspicion of financial machination." It then asks receivers to fill in details and fax or email details. Police are investigating the email which does contain a trojan virus. The virus will be filtered out so long as computers have anti-virus software on their machines. Members of the public who are receiving the email with the subject line - "Notification from Police New_Zealand" - should simply delete it and do not need to contact Police about the matter. ENDS

1 0

wireline.co.nz domain
by Grant Zanetti 30 May '06

30 May '06

Can anyone at telecom tell me why they're sending emails from this domain (wireline.co.nz) when it has no useful DNS? Where is my mail system supposed to send bounces etc?

1 0

Podcasting Heads Up
by Webmaster 29 May '06

29 May '06

Operators should be aware that due to increased demand on our podcasting service, and the number of requests we've had to increase the quality of the files, we'll be increasing the data rates of all files offered from our US mirror. At the moment all US files have the same names as NZ hosted files, but are actually lower rates. Over the next 2 weeks this will change, with the US server becoming a full mirror. The data rates of files will double (from 24k to 48k) to match those hosted in NZ. We've been able to do this because we have extra capacity in the US and can serve the extra traffic at no additional cost to us. At present NZ bound traffic from the US server sits at 10-15 Mb/s during the day. Local operators who do not peer with our NZ servers will see an increase in international inbound traffic (about double) from the US mirror over the next two weeks. After that you should allow for an increase of 10-15% per week - our current growth rate. Those who peer with our servers in New Zealand are not affected by this change. regards, Richard Hulse Radio NZ

1 0

[Fwd: APNIC ip6.int services to end 1 June 2006]
by Andy Linton 29 May '06

29 May '06

Not that this isn't because the IPv6 camp are giving up and going home. (:-) andy -------- Original Message -------- Subject: APNIC ip6.int services to end 1 June 2006 Date: Mon, 29 May 2006 21:31:42 +1000 From: sanjaya(a)apnic.net To: asjl(a)citylink.co.nz Dear colleagues, APNIC will cease all ip6.int reverse delegation services at approximately 10:00 UTC+10 (00:00 UTC) on 1 June 2006. At that time, APNIC will withdraw the delegations for the following sub-domains under 1.0.0.2.ip6.int: 2.0.1.0.0.2.ip6.int 3.0.1.0.0.2.ip6.int c.0.1.0.0.2.ip6.int d.0.1.0.0.2.ip6.int e.0.1.0.0.2.ip6.int f.0.1.0.0.2.ip6.int 4.4.1.0.0.2.ip6.int 5.4.1.0.0.2.ip6.int 8.1.0.0.2.ip6.int 9.1.0.0.2.ip6.int a.1.0.0.2.ip6.int All ip6.int delegations within these sub-domains will then cease to be recognised by most DNS resolvers (although cached delegation information may take some time to expire). APNIC will back-up all whois objects associated with these sub-domains and will continue to monitor DNS traffic during this period to review behaviour. However, as the IETF has formally deprecated ip6.int for reverse-DNS, re-delegation is not expected to occur. Regards, Sanjaya ______________________________________________________________________ Technical Services Manager <sanjaya(a)apnic.net> APNIC ph +61 7 3858 3100 http://www.apnic.net fx +61 7 3858 3199 ______________________________________________________________________

3 2

(no subject)
by Russell STREET 25 May '06

25 May '06

Hello.. . TelstraClear hosts this NZ root name server replica on its infrastructure. We are physically moving the servers that run this name server this weekend. This will cause an outage to ns4.dns.net.nz at around 6AM Saturday 27th May 2006 for around 2 minutes, when we migrate the routing for the name server from one site to the new site. Russell (TelstraClear IS Operations)

1 0

Re: [nznog] Cell Tax
by Mark Seward 25 May '06

25 May '06

Interesting numbers. After a few weeks of bad performance on an Internet feed I look after I was drawn back to an issue I thought was long buried. This circuit was dropping 4-5% of its traffic at well below advertised capacity. The delivery method was ethernet over ATM/AAL5 (RFC1483). The usual suspects were rounded up and shot (duplex and error counters, purple switches, the cleaning lady). The next question was overhead for cell tax and encapsulation. 12% seems to be the allowance by our supplier. IIRC this is the same as was used 10 years ago for ATM VCs delivered directly to routers (no ethernet involved); nanog has a few dusty posts about this number. It seems this is no longer enough. Perhaps average packet sizes have changed since then if 12% was ever a reasonable number. In the end our supplier ramped overhead to about 20% and the pipe has performed nicely since. For an ethernet service, I don't understand why they don't simply provision the VC (VBR) as large as the customer bearer can handle and let the end devices do the shaping. Michael's numbers including AAL5 padding give this new figure some context: Upstream: cell tax = 14.84% (18.09% AAL5) Downstream: cell tax = 18.35% (23.43% AAL5) Is anyone aware of a recent study of packet size distribution on Internet traffic? CAIDA have some information from the AIX in 1999, NLANR from '97, and Sprint do a semi-regular dump from their ipmon project. http://www.caida.org/analysis/AIX/plen_hist http://www.nlanr.net/NA/Learn/packetsizes.html http://ipmon.sprint.com/packstat/packetoverview.php >From netflow stats on this link, I see a similar story with 64, 576 and 1536B being the points of most interest. The percentage of 1536B packets (~25) I think is larger now than previously. Has anyone had similar frustrations with PVC dimensioning? Does anyone else still use ATM? :) Mark. On 5/23/06, Michael Newbery < Michael.Newbery(a)team.telstraclear.co.nz> wrote: > > Prompted by Mark Seward, we have had a look at the cell tax incurred for > our > customers, in those cases where we are unfortunate enough to have to > transit > an ATM pipe. Which has not been the usual case on our network but becomes > interesting for things like UBS. > > This enables us to answer the question: for a pipe of x bps sufficient to > carry pure IP, how much bigger must the ATM PVC be to carry the same load? > > > IP_bw = x > ATM_bw = ceiling(x/48)*53 > Diff = ATM_bw - IP_bw > Cell_tax = Diff/IP_bw > > For a sample SAMP, we calculate the mean cell tax as > (sum(ceiling( SAMP/48)*53) - sum(SAMP))/sum(SAMP) > > Looking at a 24 hour sample, we get: > Upstream: cell tax = 14.84% > Downstream: cell tax = 18.35% > > I understand that this is somewhat at variance with the standard > provisioning rules applied by another provider. > -- > Michael Newbery IP Architect TelstraClear Limited > Tel: +64-4-920 3102 Mobile: +64-29-920 3102 Fax: +64-4-920 3361 > > > _______________________________________________ > NZNOG mailing list > NZNOG(a)list.waikato.ac.nz > http://list.waikato.ac.nz/mailman/listinfo/nznog > >

2 1

InternetNZ Internet Governance Positions
by Keith Davidson 25 May '06

25 May '06

Pardon the intrusion and slightly off topic subject: Interested in Internet governance? InternetNZ is recruiting directors to sit on the Board of its subsidiary company, New Zealand Domain Name Registry Ltd (trading as .nz Registry Services or "NZRS"); and members to sit on the .nz Oversight Committee ("NZOC"), which has stewardship of the .nz domain name space. These positions provide an exciting opportunity to contribute to the good governance of the .nz domain name space. Company directors and those with general governance skills are encouraged to apply for the appropriate positions. The retiring incumbents are eligible for reappointment. Complete descriptions and application details for both roles can be found online at www.internetnz.net.nz/vacancy. More information on the Office of the Domain Name Commissioner can be found at www.dnc.org.nz; and about the registry company at www.nzrs.net.nz. Applications by email to vacancy(a)internetnz.net.nz are invited from suitably qualified people, and close at midnight on Saturday 3 June. Please follow the links above for further details. If you are aware of anyone who you feel would be appropriate for one of the vacancies, we would be most grateful if you could forward this information to them. Furthermore, it is coming up to AGM time for InternetNZ and we are always on the lookout for enthusiastic people to serve on our Council and various committees and working groups. Links to further details on these positions are at www.internetnz.net.nz/vacancy. Any successful recruitment from a connection with NZNOG will result in a reward of provision of beer to all associated. Regards Keith Davidson Executive Director - InternetNZ

1 0