- NZNOG - lists.nznog.org

Broadband connectivity
by Andy Linton 03 Dec '04

03 Dec '04

While we debate the merits (?) of DSL connectivity and how to handle modem pools here's an example of a service available in Japan. The last couple of pictures tell the story! > Got my 100Mb fiber optic installed yesterday...the connection is > humming. I found the whole process very interesting and think that it > is just amazing. The actual fiber is thinner than a human hair and its > just fantastic. > free install, free for two months, unlimited traffic and no more than > $100 NZD/month. > > I am one happy man : ) > > http://www.jesse-taylor.com/new/misc_images/100mb_install/index.htm

8 8

APRICOT 2005 in Kyoto, Japan
by Philip Smith 03 Dec '04

03 Dec '04

Hi everyone, This is to let you know that the registration for APRICOT 2005 in Kyoto, Japan, from 18th to 25th February 2005 is now open. APRICOT is the Asia Pacific region's Internet operations and technology conference, and consists of workshops, tutorials, conference, as well as the 6 monthly APNIC meeting. Full information about APRICOT 2005 can be had at www.2005.apricot.net. Registration and accommodation information is at: www.2005.apricot.net/registration.html www.2005.apricot.net/accommodation.html You are encouraged to register as soon as possible as the early bird registration discount finishes on the 12th of January. Hope to see you in Kyoto early next year! philip --

1 0

Dialup / Radius
by Blair Harrison 02 Dec '04

02 Dec '04

Hi People, After all the hubbub of DSL activity of late, has anyone been having any issues with Dialup? If you are, are your upstream dialup providers putting priority into solving any dialup issues? I've talked to a few people and it seems that Telecom's IPNet dialup service seems to suffer missing RADIUS Stop records and that this activity seems to have been going on for a long time.. Has anyone ever managed to get an answer out of Telecom as to why this occurs? I'm also wondering how many missing records we're talking about here, does anyone have any actual numbers? Has it increased over the last couple of months? Missing RADIUS records seem to have been just a "fact of life" for most ISPs I know of for some time now, but I'm just wondering to what extent this occurs elsewhere.. Lately we've been noticing a somewhat increased number of missing stop records- to the point that some of our RADIUS-dependant services are suffering a few "errors" .. requiring some extra "fixes" to get around the issue.. One would think that being such a core service, every RADIUS issue ever concieved should have been eliminated years ago.. Obviously some of our national providers think otherwise.. Comments? Please feel free to reply to me offlist. Regards, Blair Harrison Systems Administrator WISE Net | http://wise.net.nz

5 5

[Fwd: IOS and Growing BGP tables]
by Andy Linton 02 Dec '04

02 Dec '04

I've not seen this discussed on nznog. ---------- Forwarded message ---------- Date: Thu, 2 Dec 2004 14:39:01 +1000 From: David J. Hughes <bambi(a)Hughes.com.au> To: Oz-ISP Mailing list <aussie-isp(a)aussie.net>, isp-australia(a)isp-australia.com Subject: [Oz-ISP] IOS and Growing BGP tables Hi, I'm posting this in an attempt to raise a bit of support. I've been arguing for a feature enhancement for IOS that will prolong the life of most Cisco routers that take a full BGP table. The growth of the table is causing concern for many major providers who can see the RAM on their lower end 7200's running out in the near future. Their default solution is not to upgrade the boxes, but to filter out the /24 advertisements. However, for many years in Australia, a /24 was the normal allocation. If they blindly filter out all the /24's then lots of networks in Australia (and other countries) will become unreachable. The proposed features allows you to filter a prefix if there is a less specific prefix already in your table (with various tuneable knobs with respect to next hop etc). Some guys at Cisco have taken this on and filed a bug / feature request for this. The more people that open a TAC case and have it linked to this bug ID the higher the priority of this request will become. It's being supported on the Cisco-NSP mailing list but I thought it worth "rattling the cage" on these lists as well. The more voices the better. The Cisco Bug ID is "CSCsa45474 : Ability to block overlapping BGP prefixes from being installed in RIB". Some history of the discussions is included below. If you have a TAC account and are so inclined, please open a new case and ask the engineer to link it to this bug ID. Thanks Bambi ... Begin forwarded message: > From: David J. Hughes <bambi(a)Hughes.com.au> > Date: 1 December 2004 10:26:18 AM > To: 'cisco-nsp' <cisco-nsp(a)puck.nether.net> > Subject: Re: [c-nsp] Growing BGP tables > > > I hope that most people on this list would open a case to try to get a > feature like this included in upcoming IOS releases. It's about the > only thing that will extend the life of your "RAM limited" routers > without breaking connectivity to historically legitimate /24 > allocations. > > > David > ... > > > On 01/12/2004, at 9:40 AM, Rodney Dunn wrote: > >> For those that have the ability to open a TAC case and they think >> this is something they could use, open a case and have the TAC >> engineer attach the case to this bug: >> >> CSCsa45474 >> Externally found enhancement defect: New (N) >> Ability to block overlapping BGP prefixes from being installed in RIB > ------ Begin forwarded message: Anything that reduces the consumption of RIB and FIB resources as a result of de-aggregation etc would be a very welcome step in the right direction. Thanks for looking into this Rodney. David ... On 24/11/2004, at 3:33 AM, Rodney Dunn wrote: > My point was that you can't do it with BGP > because you don't have a way to request a > re-advertisement from a peer when the > less specific goes away. > > There is a possiblity we could keep the > more specifics out of the RIB which would > save memory there and in the FIB. > > That being said the best that can > be done currently appears to block > the routes from going in the RIB. > We are looking to see how complex that > would be to do. > > Rodney > > > On Tue, Nov 23, 2004 at 11:11:52AM -0600, Brian Feeny wrote: >> >> >> I like this, basically all your doing is getting rid of the redundant >> information which serves no purpose other than taking up space in the >> RIB/FIB anyways. And if someone should further deaggregate or make a >> change, then the new update is going to run its algorithm against the >> current RIB all over again. >> >> >> On Nov 22, 2004, at 4:16 PM, David J. Hughes wrote: >> >>> >>> Hey Rodney, >>> >>> How about ... >>> >>> for each prefix received in update >>> for each more specific prefix in RIB >>> if RIB prefix ge /24 and same next hop as update prefix >>> drop RIB prefix >>> if update prefix ge /24 >>> for each less specific prefix in RIB >>> if RIB next hop same as update next hop >>> drop update prefix >>> >>> something like that would filter during the update and wouldn't >>> require another full copy of the table to be held. I'm sure you >>> guys could come up with something more efficient but the basic idea >>> would work wouldn't it? >>> >>> >>> David >>> ... ---- email "unsubscribe aussie-isp" to majordomo(a)aussie.net to be removed.

1 0

Re: Rescue from alligators in the swamp - note from APNIC
by John Tran 02 Dec '04

02 Dec '04

Hello all, This is a follow up to my previous email. Assignments within the blocks listed below have been restored to the public APNIC Whois Database. If you wish to make any of these assignments private or if you have any questions or concerns please do not hesitate to contact APNIC helpdesk at <helpdesk(a)apnic.net> or phone +61-7-3858-3180. Kind regards, Son > > > 5) Next steps > > > ------------- > > > Under the database privacy policy, all non-portable assignments and > > > non-portable sub-allocations that have not been specifically marked as > > > public have now been made private. However, because some allocations > > > and assignments within certain ranges appear to have been considered > > > 'portable' by default from earlier practices in New Zealand, APNIC > > > will restore the affected ranges from private to public. The ranges > > > in question are: > > > - 202.27.0./16 > > > - 202.36.0.0/16 > > > - 202.37.0.0/16 > > > - 202.49.0.0/16, and > > > - 202.50.0.0/16 > > > > > > Anyone holding addresses from these ranges that they wish to be made > > > private, should contact APNIC helpdesk. The update will be done this > > > week.

1 0

Re: [nznog] Rescue from alligators in the swamp - note from APNIC (fwd)
by John Tran 02 Dec '04

02 Dec '04

Dear Mathew, >*SNIP* a really interesting e-mail > >First, John, that was most enlightening. Thanks. > I am very pleased to read that it was helpful. Thanks. >One point that was raised in this discussion is that, for many NZ (and >other pacific-based) organisations, a /21 is a huge requirement. A lot >of companies can justify a /24, maybe even a /23, or a /22 at a stretch, >but a /21 is just out of the realms of possibility, probably ever. There will always be a balance between aggregation in the routing table and conservation. Not everyone can have portable address space. However as the years have progressed the trend in the community has been to agree to smaller sized initial allocations, recognising that there are those out there with smaller requirements. To qualify for a /21 allocation an organisation needs to demonstrate that they need /23 immediately and /22 in 12 months time. By "allocation" I mean that the organisation has customers that they wish to assign non-portable address space to. If an organisation does not qualify under this policy and is multi-homed or about to be multi-homed, they can apply for an address assignment under the "Small Multi-homing policy". By "assignment" I mean that they will use the address space on their own network and it will not be delegated to customers. There is no minimum or maximum size under this policy. You can find more information on both at: http://www.apnic.net/docs/policy/add-manage-policy.html >APNIC policies seem to be more biased towards the A than the P, even >with >the change from /20 to /21. I do recognise what you are saying. Indeed APNIC has appointed 'liaison officers' for both the Pacific and for South Asia to try to ensure that needs and voices are heard. At the same time there are many ISPs or organisations throughout the entire region with smaller requirements , and perhaps you are observing that it is the large guys who tend to get involved. You need only think of Nepal, Laos, Thailand, Indonesia...... there are many others of course. >... Obviously a country could set up an NIR to >do >smaller allocations, but a lot of the little islands out there are >unlikely to have the infrastructure to run their own NIR with any kind >of >reliability. Not to mention that their sub-allocation requirements >wouldn't justify the resources and expense. The best place to raise these concerns are on the Policy SIG mailing list. I would recommend that you subscribe. More information is at: http://www.apnic.net/community/lists >With this in mind, is there anything that can be done to create >something >like a sub-RIR under APNIC to better serve the needs of the large number The only sub-structures currently within the membership structure are the NIRs and LIRs. NIRs are obligated to follow the policies of APNIC, so that the minimum size will be the same. However they are free to develop some policies that are specific to local conditions. >can >suggest policy, but the actual voting is weighted towards large In policy making there is no voting. (In determining fee structures there is as this is deemed a membership issue). The principle observed is 'consensus'. This means that the majority has to agree. One hand is raised for each person in the room and we try to include those that are participating remotely. It is not necessary for you to turn up to have a voice. Aside from the remote participation facilities (jabber, webcast) there are also periods before (one month) and after (2 months) the meeting where policies are sent to the mailing lists for further comment. The aim of all this is to try to maximise the input across the region, recognising that not everyone can make it to the meeting or can comment at the appropriate time. I hope this helps. Kind regards Son

1 0

Blackholing rfc1918 queries
by Simon Lyall 02 Dec '04

02 Dec '04

Does anyone know the current correct way to blackhole queries for rfc1918 reverses using Bind9? I had a look at as112.net (and 192.0.32.18/31) and googled a bit but I can't seem to find anything. I'm sure somebody was going on about it a year or so back and encouraging everybody to but a certain config in. -- Simon J. Lyall | Very Busy | Web: http://www.darkmere.gen.nz/ "To stay awake all night adds a day to your life" - Stilgar | eMT.

2 1

Re: [nznog] makana.co.nz spam ?
by Mark Foster 01 Dec '04

01 Dec '04

Their Pri NS appears to have IP 202.27.187.82, which based on traceroute is carried via Telstraclear to Snap. Further, if you whois you'll see that its clearly Snap aka Netaccess Christchurch. You may like to try abuse(a)snap.net.nz as a guess. But i've not heard of them before, if it helps. Mark. On Thu, 02 Dec 2004 13:27:08 +1300, Simon Byrnand <simon(a)igrin.co.nz> wrote : > Hi All, > > Has anyone else receved spam from "Makana Confections" <sales(a)makana.co.nz> > recently ? (Or in the past) > *snipped*

1 0

makana.co.nz spam ?
by Simon Byrnand 01 Dec '04

01 Dec '04

Hi All, Has anyone else receved spam from "Makana Confections" <sales(a)makana.co.nz> recently ? (Or in the past) They seem to be at it again, sending unsolicited "promotions" of their products despite previous complaints. Back in April this year they spammed hundreds of our customers (including me personally) with almost identical material to this latest batch, and at the time I forwared abuse complaints to the only relevant email addresses I could find, including soa(a)saraden.co.nz, postmaster(a)saraden.co.nz and abuse(a)saraden.co.nz who going by domainz records appear to be their webhost. At no time did I ever receive any response. Thanks to the wonders of "private" APNIC entries for NZGATE ranges where the address block that the sending mail server resides, its hard to find much more information ;-) (Hopefully that will change if APNIC goes ahead with making the private entries public again) Anybody heard of these guys ? Sent complaints to them before ? Regards, Simon Byrnand iGRIN Internet

1 0

Re: SPF and mail forwarding (was Re: [nznog] Sendmail Question)
by Ewen McNeill 01 Dec '04

01 Dec '04

In message <20041128083138.GB27487(a)walnut.gen.nz>, Richard Hector writes: >On Sat, Nov 27, 2004 at 12:20:03PM +1300, Ewen McNeill wrote: >> usera(a)ispa was one address so subscribed. Unfortunately usera(a)ispa >> actually forwards mail to userb(a)ispb, without rewriting the envelope >> from address -- [bounces because SPF check failed at ispb MX] > >Perhaps I'm a little confused, but if usera is rejecting mail from >servers that he has arranged to forward him mail, that's his own silly >fault? usera doesn't run the mail servers at ispb (or ispa for that matter). It is ispb's mail servers that are doing the SPF check, and rejecting the message, because it's been forwarded in a way that is not compliant with SPF. Other than complaining to ispb -- and they probably wouldn't even know to do so -- usera/userb can do little to influence the message being accepted or rejected at ispb. Viz: 1. spfprotecteddomain MX -> ispa MX: mail from: user(a)spfprotecteddomain rcpt to: usera(a)ispa Result: message accepted (passes SPF check if one is done) 2. ispa configuration for usera says "forward to userb(a)ispb" 3. ispa MX -> ispb MX: mail from: user(a)spfprotecteddomain rcpt to: userb(a)ispb Result: SPF check fails because ispa MX is not in the SPF from list, and message is rejected (and bounced by ispa MX back to user(a)spfprotecteddomain). SPF's answer to this is that mail servers should rewrite the from address -- complete with lots of magic about how it should be done (still being debated). Rewriting it to be "mail from: usera(a)isap" would work just about as well in practice in most situations (bounces go to the "wrong" place, but bounces are largely broken by all the abuse of them going on anyway). This is what procmail and some other things do. FWIW, this is not a theoritical situation. This is really happening right now. And I ended up relaxing some of my SPF statements as a "work around". As I said in the beginning I'd like to see more ISPs that offer "mail forwarding" services to their customers forward that mail in a way that won't cause SPF rejections further down the track. Like it or not SPF is being implemented, and trying to ignore it will not stop your customers mail being bounced. Ewen

3 2