- NZNOG - lists.nznog.org

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

13 Mar '05

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

1 0

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

13 Mar '05

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

1 0

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

11 Mar '05

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

2 1

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

10 Mar '05

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

1 0

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

10 Mar '05

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

4 6

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

08 Mar '05

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

4 4

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

08 Mar '05

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

2 1

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

08 Mar '05

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

4 4

Telecom ADSL Testing equipment
by neil gardner 07 Mar '05

07 Mar '05

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

1 0

WorldxChange Prefix List Update
by Gordon Smith 07 Mar '05

07 Mar '05

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

1 0

DNS entries
by Webmaster 07 Mar '05

07 Mar '05

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

2 1

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

06 Mar '05

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

1 0

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

06 Mar '05

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

1 0

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

06 Mar '05

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

1 0

telstra clear
by Garrett Stoupe 06 Mar '05

06 Mar '05

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

2 2

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

05 Mar '05

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

2 2

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

05 Mar '05

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

1 0

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

03 Mar '05

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

1 0

tradme etc
by Simon Lyall 03 Mar '05

03 Mar '05

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

7 6

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

03 Mar '05

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

2 1

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

03 Mar '05

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

13 20

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

03 Mar '05

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

3 2

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

03 Mar '05

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

1 0

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

02 Mar '05

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

4 3

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

02 Mar '05

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

3 2