- NZNOG - lists.nznog.org

Fwd: RIPE NCC now allocating IPv4 address space from the last /8 netblock
by Skeeve Stevens 14 Sep '12

14 Sep '12

* * *Skeeve Stevens, CEO - *eintellego Pty Ltd skeeve(a)eintellego.net ; www.eintellego.net Phone: 1300 753 383; Cell +61 (0)414 753 383 ; skype://skeeve facebook.com/eintellego ; <http://twitter.com/networkceoau> linkedin.com/in/skeeve twitter.com/networkceoau ; blog: www.network-ceo.net The Experts Who The Experts Call Juniper - Cisco – IBM - Cloud ---------- Forwarded message ---------- From: Eugen Leitl <eugen(a)leitl.org> Date: Sat, Sep 15, 2012 at 2:12 AM Subject: RIPE NCC now allocating IPv4 address space from the last /8 netblock To: NANOG list <nanog(a)nanog.org>, tt(a)postbiota.org, forkit! <fork(a)xent.com> http://arstechnica.com/information-technology/2012/09/europe-officially-run… Europe officially runs out of IPv4 addresses RIPE NCC now allocating IPv4 address space from the last /8 netblock by Iljitsch van Beijnum - Sep 14, 2012 3:20 pm UTC Earlier today, the RIPE NCC (Réseaux IP Européens Network Coordination Centre) announced it is down to its last "/8" worth of IPv4 addresses. This means that it is no longer possible to obtain new IPv4 addresses in Europe, the former USSR, or the Middle East, with one small exception: every network operator that is a "RIPE member" or "local Internet registry" (LIR) can obtain one final block of 1024 IPv4 addresses. To fulfill these requests, the RIPE NCC is keeping that last /8, which contains 16.8 million addresses, in reserve. RIPE NCC None of this comes as a surprise given that the global pool of free IPv4 addresses was emptied in February 2011. APNIC, which distributes IP addresses in the Asia-Pacific region, ran out of IPv4 addresses in May 2011; it has been working under the "final /8" regime ever since. The remaining three Regional Internet Registries are AfriNIC (Africa), LACNIC (Latin America and the Caribbean), and ARIN (North America), which all have enough IPv4 addresses to last at least two more years. Since the depletion of IPv4 address space in the APNIC region, little information has surfaced about how network operators in the region have managed the situation. However, the lack of IPv4 addresses only impacts organizations and consumers who need additional addresses, or who need addresses for the first time. Existing IPv4 users remain unaffected, and so the immediate impact is limited. Also, large network operators get large address blocks from the RIRs and they typically have a pool of unused addresses of their own, so few will be experiencing immediate problems. However, every year for the past five years, some 200 million new IPv4 addresses have been put into use. Without a steady supply of fresh addresses, many Internet-related activities are going to become problematic in the years to come. Fortunately, 20 years ago the Internet Engineering Task Force (IETF) foresaw that the 3.7 billion addresses afforded by the 32-bit IPv4 address space would become a problem, and started working on a replacement: IPv6. But the IPv4 depletion didn't happen as fast as the IETF originally predicted, and IPv6 adoption has languished. But recently, IPv6 adoption got a big push in the form of World IPv6 Launch. Eventually, IPv6 will replace IPv4, but the transition won't be pretty. Reader comments 19 Iljitsch van Beijnum / Iljitsch is a contributing writer at Ars Technica, where he contributes articles about network protocols as well as Apple topics. He is currently finishing his Ph.D work at the telematics department at Universidad Carlos III de Madrid (UC3M) in Spain. @iljitsch

1 0

speedtest.net - Texas to Wellington vs. Texas to Christchurch
by Jeremy Lawson 10 Sep '12

10 Sep '12

I was having some issues transferring to/from one of my Rackspace VPSs, so I run a few tests on speedtest.net from the VPS to various parts of NZ. I expect SOME difference, but these are outrageous. Basically: What the hell is going on in Christchurch? Ping 41ms - Wellington (CityLink) 167ms - Christchurch (Snap) 182 - Culverdon (Amuri Net) Download (transfer to Texas from NZ) 152.79 Mb/s - From Wellington 2.35 Mb/s - From Christchurch 1.99 Mb/s - From Culverdon Upload (transfer to NZ From Texas) 69.28 Mb/s - To Wellington 18.97 Mb/s - To Christchurch 7.48 Mb/s - To Culverdon Source: (each of these are the last of several similar results) http://www.speedtest.net/result/2171916814.png http://www.speedtest.net/result/2171913440.png http://www.speedtest.net/result/2171915443.png ---------------------------------------------------------------------------- Jeremy Lawson

8 8

FW: Request to clear DNS record cache in the ISP Network
by John Gandy 10 Sep '12

10 Sep '12

ISPs may wish to action the attached request from Al-Jazeera received today. Regards J John Gandy Commerce Commission | Chief Adviser 44 The Terrace ‌| PO Box 2351 ‌| Wellington 6140 | New Zealand DDI +64 (0)4 924 3677 | john.gandy(a)comcom.govt.nz<mailto:Alfred.example(a)comcom.govt.nz> [cid:image001.png(a)01CD8FFF.FB2104D0]<https://twitter.com/#!/FutureBroadband> [cid:image002.jpg(a)01CD8FFF.FB2104D0]<http://www.linkedin.com/groups?gid=4036838&trk=hb_side_g> From: telco Sent: Tuesday, 11 September 2012 8:04 a.m. To: John Gandy; Simon Thomson Subject: FW: Request to clear DNS record cache in the ISP Network Importance: High Kind regards, Silvia From: Nabil Belkaid [mailto:BelkaidN(a)aljazeera.net] Sent: Monday, 10 September 2012 11:20 p.m. To: telco Subject: Request to clear DNS record cache in the ISP Network Importance: High Dear Sir/Madam, To whom it may concern We, the Al-Jazeera Network is one of the worlds leading media network, is requesting your cooperation in instructing ISP's within your jurisdiction to clear their DNS cache. Our DNS servers were compromised recently and hackers set a long TTL (Time To Live) timer for our DNS record. Even though we have recovered from the attack, many users within your jurisdiction are unable to reach our services because of the incorrect DNS record for our domain names in the providers network. We are requesting your assistance to reach the providers so that they can clear the caches for the following domains that belongs to AlJazeera Networks. aljazeera.net aljazeera.com aljazeerasport.net aljazeerasport.com ajsdealers.com ajtransparency.com aljazeerait.net aljazeerakiswahili.com aljazeerakiswahili.org aljazeeraportal.net beinsport.net beinsport.fr beinsports.net beinsports.tv thepalestinepapers.com ajnm.me ajb.me aje.me ajtu.me aljazeera-story.net aljazeera.co.uk Aljazeera.com.tr Aljazeera.com.qa Maila.aljazeera.net Mailb.aljazeera.net We kindly request that you instruct the providers within your jurisdiction to take this action immediately. Please note that this is affecting our brand negatively and our ability to deliver the news. Please kindly act immediately. With Regards [cid:aljazeera_logo1] Nabil Belkaid Senior Engineer Media Networks & Security Section IT & Digital Media Department | Technology Division [cid:al_tel1]+974 44897073 | [cid:al_mobile1] +974 33217191 [cid:al_env1] belkaidn(a)aljazeera.net<mailto:belkaidn(a)aljazeera.net> [cid:al_mouse1] www.aljazeera.net<http://www.aljazeera.net> ________________________________ Notice: This email is intended only for the use of the individual or entity named above and may contain information that is confidential and privileged. If you are not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this email is strictly prohibited. Opinions, conclusions and other information in this message that do not relate to the official business of our firm shall be understood as neither given nor endorsed by it. </PRE>############################################################### The information contained in this e-mail may be legally privileged and CONFIDENTIAL. If you are not the intended recipient you are hereby notified that any use, dissemination, distribution or reproduction of this message is prohibited. If you have received this message in error, please delete the message and notify the sender. Any views or opinions presented are solely those of the author and are not those of the Commerce Commission. ###############################################################

1 0

Vic Uni Mail Admin about? SPF rec issue...
by Don Gould 09 Sep '12

09 Sep '12

I do SPF checking. # grep $user mail.log Sep 10 09:05:48 mx tumgreyspf[13335]: 'SPF Permanent Error: Too many DNS lookups': QUEUE_ID=""; identity=mailfrom; client-ip=216.32.181.183; helo=ch1outboundpool.messaging.microsoft.com; envelope-from=$User(a)vuw.ac.nz; receiver=$user(a)tauatapu.net.nz; vuw.ac.nz IN TXT v=spf1 ip4:130.195.81.0/24 ip4:130.195.86.0/24 ip4:202.36.141.0/24 ip4:216.235.196.0/22 ip4:216.235.200.0/21 include:mcs.vuw.ac.nz include:mailprimer.com include:_spf.learningsourceapp.com include:spf.messaging.microsoft.com ~all 1. Is anyone else having this issue with vuw? 2. Should I be doing something to change my config or do others feel that the vuw spf record is to wide? D -- Don Gould 31 Acheson Ave Mairehau Christchurch, New Zealand Ph: + 64 3 348 7235 Mobile: + 64 21 114 0699

5 6

Requesting guidance...
by Steve Holdoway 09 Sep '12

09 Sep '12

As you've been very helpful in the past, can I ask the best way forward in addressing this problem. In an attempt to reduce spam delivery to a local charity mail server, I added FEATURE(`require_rdns')dnl to the sendmail config. It did help. However, it also blocked some important clents as well... barnardos.org.nz - sends via 122-56-8-123.cid.global-gateway.net.nz logon.i.govt.nz - has no IP address ecan.govt.nz - sends via onyx.crc.govt.nz which has no IP address probably being the most important. How do you address this problem. I'm certain they all must have been repeatedly contacted? TIA for all ideas, Steve -- Steve Holdoway BSc(Hons) MIITP http://www.greengecko.co.nz MSN: steve(a)greengecko.co.nz Skype: sholdowa

8 8

Re: [nznog] Vic Uni Mail Admin about? SPF rec issue...
by Don Gould 09 Sep '12

09 Sep '12

Ok, cool. thanks Tim, that answers where to point the finger now. Tim do you mind sharing how you tested that? What tool did you use? Is there a vwu admin on list who would like to comment? Can you fix your spf record so it doesn't cause more than 10 recursive look ups or should I just not bother with spf? D On 10/09/2012 1:07 p.m., Tim Price wrote: > > The recursive lookups in that SFP record come to 14 according to my > checking. > > vuw.ac.nz IN TXT v=spf1 ip4:130.195.81.0/24 > ip4:130.195.86.0/24 ip4:202.36.141.0/24 ip4:216.235.196.0/22 > ip4:216.235.200.0/21 include:mcs.vuw.ac.nz include:mailprimer.com > include:_spf.learningsourceapp.com include:spf.messaging.microsoft.com > ~all > > ·include:mcs.vuw.ac.nz > > omx > > ·include:mailprimer.com > > oinclude:mailprimer.net.nz > > §include:mailprimer.co.nz > > §include:mailprimer.com > > ·include:mailprimer.net.nz (loop?) > > ·include:_spf.learningsourceapp.com > > oinclude:sendgrid.net > > §include:sendgrid.biz > > ·include:spf.messaging.microsoft.com > > oinclude:spfa.frontbridge.com > > oinclude:spfb.frontbridge.com > > oinclude:spfc.frontbridge.com > > *From:*nznog-bounces(a)list.waikato.ac.nz > [mailto:nznog-bounces(a)list.waikato.ac.nz] *On Behalf Of *Scott Howard > *Sent:* Monday, September 10, 2012 12:52 PM > *To:* Don Gould > *Cc:* nznog > *Subject:* Re: [nznog] Vic Uni Mail Admin about? SPF rec issue... > > On Sun, Sep 9, 2012 at 5:44 PM, Don Gould <don(a)bowenvale.co.nz > <mailto:don(a)bowenvale.co.nz>> wrote: > > 2. Should I be doing something to change my config or do others > feel that the vuw spf record is to wide? > > > From http://tools.ietf.org/html/rfc4408#section-10.1 : > > / SPF implementations MUST limit the number of mechanisms and modifiers > that do DNS lookups to at most 10 per SPF check, including any > lookups caused by the use of the "include" mechanism or the > "redirect" modifier. If this number is exceeded during a check, a > PermError MUST be returned. The "include", "a", "mx", "ptr", and > "exists" mechanisms as well as the "redirect" modifier do count > against this limit. The "all", "ip4", and "ip6" mechanisms do not > require DNS lookups and therefore do not count against this limit. > The "exp" modifier does not count against this limit because the DNS > lookup to fetch the explanation string occurs after the SPF record > has been evaluated. > / > > Scott > -- Don Gould 31 Acheson Ave Mairehau Christchurch, New Zealand Ph: + 64 3 348 7235 Mobile: + 64 21 114 0699

3 3

Some Traffic stats
by Simon Lyall 06 Sep '12

06 Sep '12

I just put up some stats on where the NZ eyeballs appear to be, based on some website data and sort by Origin ASN. People here might find it interesting since it might be a rough proxy for market share. http://blog.darkmere.gen.nz/2012/09/where-the-nz-eyeballs-are/ -- Simon Lyall | Very Busy | Web: http://www.darkmere.gen.nz/ "To stay awake all night adds a day to your life" - Stilgar | eMT.

1 0

Re: [nznog] NZNOG conference
by Mark Foster 03 Sep '12

03 Sep '12

Thanks for posting the actual dates. I didn't think that one would have to go to third party resources for the answer and I'm also aware of "differing opinions" as regards the nature of the overlaps of audience. Sorry for the network purists but some people either wear many hats or have to roster those who do. ..! ("Them and us" approach doesn't do anyone any favours IMHO) Cheers. Simon Lyall <simon(a)darkmere.gen.nz> wrote: > >Colour me confused but when I look online[1] NZNOG 2013 is listed as 21-25 >Jan 2013 which is the week before LCA. > >I'd check the NZNOG website for details but... > >[1] Here: > >http://ws.edu.isoc.org/calendar/index.php?event=DES >http://www.ripe.net/ripe/meetings/calendar/nznog-2 >http://www.apnic.net/events/calendar/2013/nznog-2013 > > >-- >Simon Lyall | Very Busy | Web: http://www.darkmere.gen.nz/ >"To stay awake all night adds a day to your life" - Stilgar | eMT. > >_______________________________________________ >NZNOG mailing list >NZNOG(a)list.waikato.ac.nz >http://list.waikato.ac.nz/mailman/listinfo/nznog

4 3

NZNOG conference
by Daniel Griggs 31 Aug '12

31 Aug '12

I was just trying to find some details for the next NZNOG conference, but the NZNOG site appears to be down, downforeveryoneorjustme.com agrees that it's not just me. I think it was announced to be in Wellington but I haven't heard anything further, like dates or any calls for papers. Does anyone else have any details? (organising committee?) -- Daniel Griggs Network Operations e: daniel(a)fx.net.nz d: +64 4 4989567

11 11

Questions from APNIC34 in Cambodia - Returned IPv4 Addresses
by Dean Pemberton 30 Aug '12

30 Aug '12

One of the topics to come up at the APNIC 34 meeting in Cambodia is what happens to any IPv4 addresses which are returned or recovered by APNIC. At present APNIC operates in a mode where it is implementing austerity measures and will only allocate 1024 addresses from their last /8 (103/8) to members on a one off basis. This means that existing and new APNIC members are only able to get a single 1024 address allocation from now on. There are organisations with large IP address allocations (in most cases legacy addressing) who are considering handing them back. JPNIC has already accepted back more than a /11 worth of space. The questions being asked by some members now is what happens to those addresses and how might they be reallocated to other members. In evaluating how recovered addresses may impact its members the Japan Network Information Centre has asked them the following questions and I'd like to give New Zealand organisations a chance to answer them as well. 1. If it were possible to receive an IPv4 allocation of returned addresses from outside of the APNIC final /8 (103/8) block, would you apply for an allocation? 2. Would you use the IPv4 addresses any differently than an allocation from the final /8? (eg, Sign up new customers vs IPv6 transition technologies) 3. Would there be an effect on your IPv6 deployment if further IPv4 addresses could be allocated. 4. What would be the minimum size which would make such an allocation useful 5. There are opinions that rather than focusing on changing IPv4 policy, we should put all efforts towards IPv6 deployment. Taking such opinion into consideration, do you still feel there is a need to re-consider the APNIC final /8 policy (APNIC prop-88)? 6. Any additional comments. Answers/Comments to me or the list, I'm calm either way. Regards, Dean

1 0