- NZNOG - lists.nznog.org

Fwd: Estonian IPv6 deployment report
by Brian E Carpenter 23 Dec '14

23 Dec '14

An example from far away... -------- Original Message -------- Subject: Estonian IPv6 deployment report Date: Mon, 22 Dec 2014 17:27:23 +0200 From: Tarko Tikan <tarko(a)lanparty.ee> To: IPv6 Ops list <ipv6-ops(a)lists.cluenet.de> hey, Some time ago, many people noticed rapid IPv6 deployment growth in Estonia (from 0% to 5% in 4 weeks). We at 3249/Elion/Estonian Telecom were behind this, other operators don't have any serious IPv6 deployments at the moment. We rolled out v6 to everyone (both business and residential customers) with last-gen CPE, there was no hop-in our hop-out program - aim was to do it perfectly and without customers even noticing. I'm happy to say that we achieved this goal :) To satisfy general interest, I promised small (somehow it turned out longer than I expected) technical writeup how we enabled v6 for our subscribers. If you have any other questions, feel free to ask and I do my best to answer them. You can also skip the technical content and there are some statistics below. Our access network is mix of DSL/GPON/wimax/p2p-ETH and broadband service is deployed in shared service vlans. IPv6 traffic shares vlan with IPv4. Service vlans are transported over MPLS metro network using pseudowires and terminated in geo-clustered Alcatel 7750 BNG routers. Each subscriber is allocated up to 4 mixed v4 and v6 IP hosts. For v4 we are using the usual DHCP, for IPv6 we are using DHCPv6 with IA_PD only, no IA_NA is provided. Unfortunately DHCPv6 provides no way to signal IPv6 default-route thus we have to fall back to RA for default-route. RA does not include any on-link prefixes or DNS information. RAs are L2 unicasted to CPE MAC so no other CPE in service vlan picks up those RAs. To ensure rapid switchover between BNG routers, we are signalling virtual link-local address as default-route. We are using ALU internal DHCP/DHCPv6 servers to allocate leases but we also signal IP information from radius (in such case BNG "fakes" DHCP server) for static IP customers. Provided IPv6 prefix is always /56 and we keep the old lease for 24h even if the CPE is turned off (actual lease time is 30min). Unfortunately, IPv6 LDRA is not available on most of our access platforms so we have to rely on IPv4 session information for authentication. This linking is done in the radius server during subscriber authentication (excellent radiator + quite awful SQL queries :) - if subscriber has IPv4 session (that has been authenticated using DHCP opt82), same MAC address is allowed to have IPv6 session on exactly the same virtual BNG port. IPv4 and v6 session are both tied to same subscriber and share shapers, QOS etc. We were able to enable IPv6 only on our last-gen Inteno CPEs. They run modified OpenWrt and because it's linux - everything is possible :) In CPE, /56 is divided up to /64s, first one is currently reserved but we will configure it on loopback interface and use it for CPE management. Second /64 is configured on LAN and third is configured on public wifi SSID (if you choose to enable this option). In the LAN, IPv6 config is provided by RAs, we also support RDNSS and stateless DHCPv6 for DNS. There is also ingress IPv6 firewall in the CPE and configuration is modifiable by user. To make deployment as smooth as possible, we rolled out IPv6 capable CPE software first. Then, during the BNG platform refresh, we deployed L2 ACLs that dropped all IPv6 traffic based on 0x86dd ethertype. We then deployed IPv6 config to all BNGs and could verify everything before single v6 lease was handed out to the subscribers. Then, interface by interface, we replaced L2 ACL with one that only allowed 0x86dd for certain, supported, OUIs. This is the current situation and we are investigating ways to support 3rd party CPEs - main problem is unreliable IPv6 config in CPEs. Many don't enable DHCPv6 (or enable NA but no PD) but still pick up default-route from RA and happily signal it to LAN. Some others hammer our BNGs with NA request every 0.1 seconds etc. As statistics go, there are 30000+ active IPv6 subscribers (almost 15% of our customer base, based on our public numbers), 81% of them have have at least one IPv6 enabled device in the LAN, 70% have more than one. Most IPv6 traffic is generated by Google+Youtube, Facebook and Akamai. Not bad for a country with 1.3M people. Next up: mobile network :) -- tarko

2 1

Primary access method
by Brian E Carpenter 21 Dec '14

21 Dec '14

Hi, In answer to a ticket entitled "Not getting an IPv6 prefix today", here is what the help desk told me: > Currently XXX have IPv6 services turned off due to some ongoing investigations > with this service. > > Once this is turned back on you will be able to get an IPv6 address again. and in response to my follow-up bleat > As IPv6 is not the Primary access method we offer on our connections this does > not need to be updated on the network status page. > > IPv6 is not a fully released product therefore it is still going through testing > and this is why we are currently unable to apply static IPv6 address (I didn't ask about a static address and don't want one.) This morning, I still have no IPv6 service and the XXX status page still says "OK - No Known Network Problems". Now, since I've had stable IPv6 service for a long time and it often gives me better response times than IPv4, I was a bit annoyed by this. Isn't it time that people consider IPv6 to be the primary access method, and IPv4 to be a legacy solution? Grumble. I need to fire up SixXs again, then. Brian

9 14

Akamai at APE
by Scott Pettit 19 Dec '14

19 Dec '14

Hoping someone knows/can share more info about the Akamai APE peer. It's been there a couple of months now but I can't find any announcement or info in regards to what those caches are serving. I'm seeing a small amount of largely corporate-ish content coming off it (e.g. Cisco.com content seems to come from there) but wondered whether it also provides media content like iTunes movies? Does anyone have detail on how large it is and what it's there for? -Scott

2 1

Multicast traffic replication issue
by Ben Cornish 18 Dec '14

18 Dec '14

Hi All, Curious if anyone has seen this issue previously or could offer any advice on the issue: We have a VLL/EOMPLS with Pipe from Sydney to NZ which then utilises a City Link QinQ service across town in Auckland. We've had an issue ongoing for some time and it only relates to multicast traffic traversing the path. Essentially this issue started when we couldn't establish a OSPF session over the link - yet all other traffic flows as expected. When we broke this link down to basics (laptop either end) we send one multicast packet in the Sydney end - we then receive that same packet 97 times out the Auckland end. (Over the Pipe and City link path) We see this issue when we ping 224.0.0.5 over the link and get that same exact packet 97 times on the other end. We've seen this when doing WireShark captures on the port. The captures show the exact same packet 97 times (ie same payload/sequence number). Pipe seem to be running out of ideas to track the issue. Being a EoMPLS circuit I doubt the issue is on the Pipe side but more on the City Link side. When CityLink were engaged in the issue they did what they referred to as an RFC test - as I understand it, unicast testing only and never engaged further. This issue only seems to effect link local multicast traffic - ie 224.0.0.x/24 All other traffic appears to flow normally/as expected. Obviously we are chasing pipe to test each side individually to work out who is doing the packet replication - however I am curious if anyone has had issues forming OSPF sessions over a City link service ?? Or if anyone can offer advice or seen a similar issue ? My brain boggles thinking how this is even possible or what would cause it. Ben Cornish General Manager [Description: Description: cid:image001.png(a)01CCB4C2.B40A97F0] Over the Wire Pty Ltd - An Impirical Company Level 3, 24 Little Edward St, Spring Hill QLD 4000 t +61 7 3847 9292 m +61 417 617 204 e ben.cornish(a)overthewire.com.au<mailto:ben.cornish(a)overthewire.com.au> www.overthewire.com.au<http://www.overthewire.com.au/>

3 4

Call for Presentations - DNS-OARC Spring Workshop, May 2015
by Sebastian Castro 18 Dec '14

18 Dec '14

NOTE: Previous message contained the right information, but with the subject referring to the wrong year. Apologies for the noise. The next OARC Spring Workshop will take place in Amsterdam on May 9th and 10th, the weekend before RIPE70. OARC is requesting proposals for presentations, with a preference for DDoS attack reports and mitigation techniques. Reports and field stories can cover DNS-based DDoS attacks, attacks to DNS infrastructure or side effects suffered by cache resolver operators. This workshop intends to build from previous strong OARC workshops, where operational content and research is welcome. Presentations from DNS operators are particularly welcome, as well as from DNS researchers. All DNS-related subjects are accepted, introduction to new tools, visualizations, DNSSEC and novel uses of the DNS. If you are an OARC member, and have a sensitive topic you would like to present for members-only, we will accommodate those talks too. Adopting practice from other conferences, a timeslot for lighting talks will be available for short presentations (5 to 10 minutes). Workshop Milestones * 18 December 2014, Call for Presentations posted * 8 January 2015, Open for submissions * 5 March 2015, Deadline for submission * 26 March 2015, Final Program published * 7 May 2015, Final deadline for slideset submission Details for abstract submission will be published here: https://indico.dns-oarc.net//conferenceCFA.py?confId=21 The workshop will be organized on different tracks, depending on the topics and the timing of each presentation. If you are interested in a lightning talk, let us know at the time of submission. You can contact the Programme Committee: https://www.dns-oarc.net/oarc/programme via <submissions(a)dns-oarc.net> if you have questions or concerns. Sebastian Castro, for the OARC Programme Committee OARC is also seeking sponsorship for this workshop, please contact <sponsor(a)dns-oarc.net> if your organization is interested in becoming a sponsor. (Please note that OARC is run on a non-profit basis, and is not in a position to reimburse expenses or time for speakers at its meetings.) -- Sebastian Castro Technical Research Manager .nz Registry Services (New Zealand Domain Name Registry Limited) desk: +64 4 495 2337 mobile: +64 21 400535

1 0

Call for Presentations - DNS-OARC Spring Workshop, May 2014
by Sebastian Castro 18 Dec '14

18 Dec '14

The next OARC Spring Workshop will take place in Amsterdam on May 9th and 10th, the weekend before RIPE70. OARC is requesting proposals for presentations, with a preference for DDoS attack reports and mitigation techniques. Reports and field stories can cover DNS-based DDoS attacks, attacks to DNS infrastructure or side effects suffered by cache resolver operators. This workshop intends to build from previous strong OARC workshops, where operational content and research is welcome. Presentations from DNS operators are particularly welcome, as well as from DNS researchers. All DNS-related subjects are accepted, introduction to new tools, visualizations, DNSSEC and novel uses of the DNS. If you are an OARC member, and have a sensitive topic you would like to present for members-only, we will accommodate those talks too. Adopting practice from other conferences, a timeslot for lighting talks will be available for short presentations (5 to 10 minutes). Workshop Milestones * 18 December 2014, Call for Presentations posted * 8 January 2015, Open for submissions * 5 March 2015, Deadline for submission * 26 March 2015, Final Program published * 7 May 2015, Final deadline for slideset submission Details for abstract submission will be published here: https://indico.dns-oarc.net//conferenceCFA.py?confId=21 The workshop will be organized on different tracks, depending on the topics and the timing of each presentation. If you are interested in a lightning talk, let us know at the time of submission. You can contact the Programme Committee: https://www.dns-oarc.net/oarc/programme via <submissions(a)dns-oarc.net> if you have questions or concerns. Sebastian Castro, for the OARC Programme Committee OARC is also seeking sponsorship for this workshop, please contact <sponsor(a)dns-oarc.net> if your organization is interested in becoming a sponsor. (Please note that OARC is run on a non-profit basis, and is not in a position to reimburse expenses or time for speakers at its meetings.) -- Sebastian Castro Technical Research Manager .nz Registry Services (New Zealand Domain Name Registry Limited) desk: +64 4 495 2337 mobile: +64 21 400535

1 0

Re: [nznog] New IXs in NZ - discussion
by Stu Fleming 17 Dec '14

17 Dec '14

Coming very late to the party on this, but I wanted to wait until announcements (both press and BGP) were out there: On 11 November 13:18, Tim Hoffman <tim(a)hoffman.net.nz> >We've had some interesting announcements of Megaport and IX Australia building internet >exchanges into NZ over the last week or so. I've been a bit surprised at how little chatter there >has been around this on the list. I've just completed standing up our (WICNZ AS38437) peering with APE and hope to complete megaport IX peering in the next couple of days. We're peering IPv4 and IPv6 on both. Our peering record is at http://www.peeringdb.com/view.php?asn=38437 NOC contact: Stu 021 993 125 stewart(a)wic.co.nz I've noted with interest the migration away from Sky Tower to 220 Queen St in particular and the healthy participation by a large number of operators on APE. See below for how you can help me :-) >It's interesting looking at the differences between the 3 IXs we're about to have. >Citylink, who have the critical mass of all the peers, are in the most locations, and are the most >expensive. They've also got a product set around metro ethernet, dark fibre, and have a CDN >running. And they're doing some interesting things around a "SDN driven IX". An announcement in the last few days which seems to have been overlooked on NOG is the relaunch of the Dunedin Peering Exchange: http://www.scoop.co.nz/stories/BU1412/S00637/citylink-tech-boost-for-dunedi… As you will probably all know (to varying degrees of snark), Dunedin won the Chorus Gigatown competition, providing gigabit speeds on UFB at the retail level. As such, we're expecting higher than normal traffic volumes and hopefully an associated increase in exchanges between providers. I would strongly encourage any operator with a presence in Dunedin to connect to the Dunedin Exchange when it becomes available. We're committed to peering there and hope to see others connecting! Regards, Stu

1 0

Re: [nznog] FW: Primary access method
by Scott Pettit 17 Dec '14

17 Dec '14

> On 17/12/14 11:20 pm, "Joel van Velden" <joel(a)tpnz.co.nz> wrote: >There is no NZ ISP that fully supports IPv6 on DSL/UFB that I am aware >of. We (vorco.net) do support IPv6 on all connections and it's on by default. All customers are assigned a static /56 via DHCPv6 PD, so all that's required is enabling it on the CPE and it is a "production" feature. We officially test and support it on Cisco 867VAE, all 880's, 890's and anything upwards of that and provide template config for these. We have also tested and know it works with Netcomm NF4V (on firmware RB017 and RB019) but don't provide support for those. We've gone to great lengths to pester anyone we connect to with broken IPv6 and as at right now are not aware of any outstanding issues. -Scott

1 0

Re: [nznog] Primary access method
by Pete Mundy 17 Dec '14

17 Dec '14

On 18/12/2014, at 12:20 PM, Joel van Velden <joel(a)tpnz.co.nz> wrote: > There is no NZ ISP that fully supports IPv6 on DSL/UFB that I am aware of. Let's change that awareness then! :) http://www.sinch.co.nz/support-centre.html Very first question on their list: "Can I get IPv6?" Answer: "I'm so glad you asked, yes all our plans are IPv6 enabled." That statement makes me think they seem pretty supportive. *disclaimer - I am not a customer of Sinch, nor have I ever used their products. I simply had their service pointed out to me recently, and I think I maybe I'll get a test circuit from them sometime next year. Pete

1 0

AKL-IX and domestic vs. international
by Dave Mill 11 Dec '14

11 Dec '14

Hi all (Note, I'm not trying to place blame at any party here. Just interested in people's thoughts on this situation) We, Inspire/AS17705, recently peered at AKL-IX. I was interested in using this peering exchange as much as possible so we have tended to prefer AKL-IX routes over any other peering exchange (though we still prefer bi-lats, private interconnects, etc, over AKL-IX). Simple stuff.. We learnt a lot of routes off AKL-IX. We started sending traffic out via. AKL-IX. Cue customer complaints. In general, we were sending all traffic to AS4826/Vocus out via AKL-IX. I believe if another ISP had Vocus as an international provider the traffic would ingress that ISP via their international pipe. This led to one customer having packet loss over a VPN (I'd assume the far end had congested international) and another customer getting billed for this traffic as international. We ceased learning Vocus routes from the AKL-IX. Problem solved... Except, this doesn't really sound ideal to me. If Vocus are announcing routes to AKL-IX (their choice) I would like to be free to use them. What should we be doing in a situation like this? What should Vocus be doing? Am I just making a mountain out of a molehill here and should I just shut-up and leave my current fix in place? Cheers Dave

6 12

Cloudflare on the APE
by Jamie Baddeley 07 Dec '14

07 Dec '14

With N4L joining the APE the fun keeps coming.. New CDN in town and it's a win for NZ. http://www.scoop.co.nz/stories/BU1412/S00034/ape-brings-the-world-closer-to… At an operational level I'm sure the CloudFlare guys will provide an update soon. regards jamie

19 31

Re: [nznog] Licence NZNOG video recordings
by Richard Naylor 02 Dec '14

02 Dec '14

At 01:48 p.m. 2/12/2014, Nick wrote: >A woefully inadequate search of the archives does not produce an >answer to this, so tempting all fate, I submit a possibly list >relevant query... > >What is the copyright licencing on the r2 recordings of NZNOG? Each >page clearly displays their copyright, which is fair and makes >sense, but there appears to be no distribution licence (eg Creative Commons?) The copyright is held by R2 (2011) Ltd and all rights are reserved. We use that statement whenever a client fails to advise what rights they would like to assert. This is to protect the client's interests despite their ignorance - if that makes sense. We have only 2 clients who (usually) advise what rights to assert and they are usually a form of CC. On the funny side - even Creative Commons NZ don't advise, even after 7 years of waiting, so we hold the rights on their launch in NZ ! http://www.r2.co.nz/20071027/

7 7

Megaport event in Auckland
by Denver Maddux 02 Dec '14

02 Dec '14

Hi all, Just a heads up that Megaport will be hosting a small get together next week in Auckland. Date: Tuesday, 9 December Time: 3:00 - 5:00pm Venue: Gallery 1, Pullman Hotel Auckland Cnr Princes St and Waterloo Quadrant, Auckland City 1010 Our event will highlight: - What is Megaport? - What is MegaDirect? - What is MegaIX? - How does it work? - Who is on it? - How can I connect? - Come and meet the team! Whilst most of you probably understand the Megaport model it would be great for at least me to just meet some of you. And I’m buying drinks just after the session. :) Along with me, Mitchell Warden, Michael Glynn, and Joshua Munro will be leading the session from Megaport. If anyone is interested in attending, shoot me a direct email and I’ll make sure your name is on the list. Thanks, Denver Maddux Megaport

2 2

Fwd: Operators and the IETF - Thank You and Next Steps
by Jamie Baddeley 02 Dec '14

02 Dec '14

of interest to folks? Brian - I saw your name mentioned in dispatches - would be keen to get your perspective as an active Kiwi IETF'er. cheers jamie ---------- Forwarded message ---------- *From: *Chris Grundemann <grundemann(a)isoc.org> *Subject: **Operators and the IETF - Thank You and Next Steps* *Date: *3 December 2014 11:14:58 am NZDT *To: *DL Deploy360 Team <deploy360(a)isoc.org> Hello! Thanks again for completing the Internet Society’s “Operators and the IETF <http://www.internetsociety.org/deploy360/projects/operators-and-the-ietf/>” survey! For those of you who are interested, this message provides some follow up information. I want to make sure that you’re all aware of what we’ve done with the data we collected, what we plan to do next, and how you can get (or stay) involved should you want to. We collected, analyzed, and synthesized all of the responses collected in the first 6 months of 2014. This is currently published in an IETF Internet-Draft <https://tools.ietf.org/html/draft-opsawg-operators-ietfaft-opsawg-operators…> . The results were further condensed into a presentation that was given during the OpsAWG meeting at IETF 91. You can view the video <http://recordings.conf.meetecho.com/Playout/watch.jsp?recording=IETF91_OPSA…> (the Operators and the IETF bit starts at about 01:07:00) and check out the slides <http://www.slideshare.net/Deploy360/operators-ietf-ietf91> if you like. For more information on what all happened in relation to this effort during the most recent IETF meeting, check out this blog post <http://www.internetsociety.org/deploy360/blog/2014/11/operators-and-the-iet…> . As for next steps, we have a couple things in mind. Several of us are going to try to start hosting an “IETF help desk” at the major NOG/NOF meetings around the world. First up to try are NANOG 63, APRICOT 2014, and RIPE 70. This desk will have an IETF banner on it and be manned by volunteers with IETF clue. The idea is to answer folks’ questions on the spot, providing easier access to the IETF process for everyone. The helpdesk and all other future efforts to bring these two communities closer together and help ensure that operational realities inform the development of key technologies will be (at least initially) discussed on a new mailing list: http://snozzages.com/cgi-bin/mailman/listinfo/synergy I highly encourage anyone receiving this message to sign up, if you’d like to be involved in this continuing discussion. Either way, thank you for your participation thus far! Cheers, ~Chris -- Chris Grundemann Director, Deployment & Operationalization Internet Society (ISOC)

2 1

IPv6 troubleshooting for Residential ISP Helpdesks - a document
by Dean Pemberton 02 Dec '14

02 Dec '14

Andy just poked this under my nose. Great looking resource! They are looking for feedback if you've got any. ---------- At IPv6 WG session in London, we discussed the most recent version of the "IPv6 Troubleshooting for Residential ISP Helpdesks" document. The proposed plan of action was to reach the consensus on the technical details of the document and then publish it (as combined IPv6 WG and BCOP TF effort). This email announces the working group last call for the "IPv6 Troubleshooting for Residential ISP Helpdesks" document. Please read the most recent version of it: https://www.ripe.net/ripe/groups/tf/bcop/ipv6-troubleshooting-for-residenti… and provide your comments to the list *until 23:59 Fri Dec 19th 2014*. ---------

1 0

Cooling Pads for Juniper SRX?
by Skeeve Stevens 01 Dec '14

01 Dec '14

Hi all, I have an issue with some Juniper SRX100's overheating. I've seen them get hot before, especially placed on something similar (i.e. another SRX100)... and given warnings of overheating, but never shut down.... but this situation is different. These SRX100's are shutting down as they are reaching a core temperature of 70c as they are located in racks that are outside in the sun and on particularly hot days - around 32c-36c they overheat and turn themselves off. Some might say this is understandable... and I sort of agree. Although their operating system says they are good to 40c, that doesn't really seem to be the case. The SRX110's are a little more tolerant given they are bigger units - but have the same operating environmentals (along with the EX2200-C). But at the moment I have the SRX100's and would prefer not to swap them out as it will cost significantly. Then one of my staff had (what I think) a good idea today... to use cooling pads... maybe like the ones you use for laptops or something. So I am wondering if anyone has been some solid - not $20 junk or such.. but something that runs off mains, and works well 24x7x365 - maybe even something that only kicks in once a certain temperature has been reached. I thought if anywhere, a couple of these mailing lists might have had some experience with these kinds of things - especially for those who have built regional pops and have had to cool some equipment. Thanks all! ...Skeeve *Skeeve Stevens - *eintellego Networks Pty Ltd skeeve(a)eintellegonetworks.co.nz ; www.eintellegonetworks.co.nz Phone: +612 8014 7398; Cell +61 (0)414 753 383 ; skype://skeeve facebook.com/eintellegonetworks ; <http://twitter.com/networkceoau> linkedin.com/in/skeeve twitter.com/theispguy ; blog: www.theispguy.com The Experts Who The Experts Call Juniper - Cisco - Cloud - Consulting - IPv4 Brokering

1 0

Licence NZNOG video recordings
by Nick 01 Dec '14

01 Dec '14

A woefully inadequate search of the archives does not produce an answer to this, so tempting all fate, I submit a possibly list relevant query... What is the copyright licencing on the r2 recordings of NZNOG? Each page clearly displays their copyright, which is fair and makes sense, but there appears to be no distribution licence (eg Creative Commons?) Cheers, Nick -- Nick 'Zaf' Clifford

1 0

Spots available on NZITF DDoS training next week in Wellington
by Dean Pemberton 30 Nov '14

30 Nov '14

Hi All, Wellington is going to be the centre of all things Security next week, with Kiwicon happening on the 11th and 12th. In advance of that NZITF have Krassi Tzvetanov (currently at A10 Networks previously at Cisco) visiting that week and running some training while he is here on the 10th December. We don't normally open training up to non-NZITF members, but as this is on DDoS Mitigation and some NZNOG'ers are liable to be in town anyway for Kiwicon, I thought I'd pass the info on. This training will cover different types of DoS attacks that are currently popular and will explain in detail how they work and how in some cases the underlying technology is exploited to produce the desired effect by the attacker. More details available here. http://nzitf.org.nz/pdf/141228-DDoS-Mitigation.pdf Regards, Dean

1 0

Re: [nznog] Letter to Network Operators 24 Nov 2014
by Ray Taylor 30 Nov '14

30 Nov '14

Dean that's a brilliant idea They should definitely be *required* to make a presentation in rotorua and have a q&a session. Ray Taylor Taylor Communications ray(a)ruralkiwi.com Ph 021-483-280 Network status 06-929-9082 Description: header_logo

1 0

FW: Letter to Network Operators 24 Nov 2014
by Ray Taylor 29 Nov '14

29 Nov '14

I am assuming this refers to notifications about equipment changes, vendor suppliers etc? It may come as a surprise to these people but most network operators create standards and stick to them! Ray Taylor Taylor Communications <mailto:ray(a)ruralkiwi.com> ray(a)ruralkiwi.com Ph 021-483-280 Network status 06-929-9082 Description: header_logo From: TICSA [mailto:TICSA(a)ncsc.govt.nz] Sent: Monday, 24 November 2014 3:21 p.m. To: TICSA Subject: Letter to Network Operators 24 Nov 2014 Dear Network Operator Please find attached a letter to all network operators. This letter shares our surprise at the low number of notifications received from registered network operators to date. We want to reinforce that we are here to support you in meeting your obligations under the TICSA. We thank those network operators who have actively engaged with us under the TICSA since May. Kind regards >From the TICSA Team _____ This electronic message, together with any attachments, contains information that is provided in confidence and may be subject to legal privilege. Any classification markings must be adhered to. If you are not the intended recipient, you must not peruse, disclose, disseminate, copy or use the message in any way. If you have received this message in error, please notify us immediately by return email and then destroy the original message. The Government Communications Security Bureau (GCSB) accepts no responsibility for changes to this e-mail, or to any attachments, after its transmission from GCSB. Thank you. _____ This email has been filtered by SMX. For more information visit smxemail.com <http://smxemail.com/>

8 8

Re: [nznog] Network for Learning APE Peering
by Peter Lambrechtsen 28 Nov '14

28 Nov '14

Let's not forget that N4L is run by Spark Digital aka Gen-I and is completely separate infrastructure from the Retail broadband stack. For all intensive purposes they are separate companies. > -------- Original message -------- > From: Tony Wicks <tony(a)wicks.co.nz> > Date: 29/11/2014 8:59 AM (GMT+12:00) > To: "'nznog(a)list.waikato.ac.nz'" <NZNOG(a)list.waikato.ac.nz> > Subject: Re: [nznog] Network for Learning APE Peering > > > Yes, and it also goes to highlight that there is no reason whatsoever why the rest could not be peered ! > > > >Subject: Re: [nznog] Network for Learning APE Peering > > > > > > >That'll be a royal truck-load of daytime traffic moving from domestic transit links to peering links! > > > > >I think much kudos should go to the N4L team for bringing some 5000+(*) addresses of Spark's IP space into being openly peered at APE. This is a fantastic move! > > > > >Well done guys :)

1 0

Network for Learning APE Peering
by Clayton Hubbard 28 Nov '14

28 Nov '14

Hi Noggers.. Network for Learning has just completed peering with APE. If you provide services to schools in NZ and have any suboptimal routing, please contact me off-list to investigate. Thanks, *Clayton Hubbard* Senior Engineer, The Network for Learning Ltd D: 09 972 2906 | M: 022 043 0155 | W: http://www.n4l.co.nz A: Suite 306, Geyser Building, 100 Parnell Road, Parnell, Auckland 1052 P: PO Box 37118, Parnell, Auckland 1151 <http://www.n4l.co.nz> <https://twitter.com/@N4LNZ/> <https://www.facebook.com/NetworkForLearning> <https://plus.google.com/104649004276520409744/about> <http://www.linkedin.com/company/the-network-for-learning-ltd-n4l->

3 2

Re: [nznog] FW: Letter to Network Operators 24 Nov 2014
by Revel N 25 Nov '14

25 Nov '14

Completely agree. My interpretation of the guidance is the same (i.e. "continuing to use the exact same systems as were decided on and deployed prior to 11 May would not require a notice and replacing dead hardware with the same thing doesn't require this notice either"). As such, I'd be surprised if there had been a large number of submissions from every operator within 6 months. On 26 November 2014 at 12:00, <nznog-request(a)list.waikato.ac.nz> wrote: > Send NZNOG mailing list submissions to > nznog(a)list.waikato.ac.nz > > To subscribe or unsubscribe via the World Wide Web, visit > http://list.waikato.ac.nz/mailman/listinfo/nznog > or, via email, send a message with subject or body 'help' to > nznog-request(a)list.waikato.ac.nz > > You can reach the person managing the list at > nznog-owner(a)list.waikato.ac.nz > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of NZNOG digest..." > > > Today's Topics: > > 1. Re: FW: Letter to Network Operators 24 Nov 2014 > (Alexander Neilson) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 25 Nov 2014 12:12:41 +1300 > From: Alexander Neilson <alexander(a)neilson.net.nz> > To: Dave Mill <dave(a)mill.net.nz> > Cc: "nznog(a)list.waikato.ac.nz" <nznog(a)list.waikato.ac.nz> > Subject: Re: [nznog] FW: Letter to Network Operators 24 Nov 2014 > Message-ID: <3B4DF5F6-1C93-4023-AE3E-D5D483D7CC0A(a)neilson.net.nz> > Content-Type: text/plain; charset="utf-8" > > What I think is missing here is where providers have a standard system > they have used with the same hardware before May 11th. > > These were decisions made beforehand, no change to deployment, or not > covered by an area of specified security interest. > > How many people on this list would have changed the manufacturer / type of > equipment used in the NOC / core network that meets the threshold in 6 > months? > > IANAL > > However from my lay reading of the guidance and exemptions continuing to > use the exact same systems as were decided on and deployed prior to 11 May > would not require a notice and replacing dead hardware with the same thing > doesn?t require this notice either. > > So I am not sure that a low number of notifications is an odd thing unless > people had major changes to their core and a short run time to make these > changes. > > Others may want to chime in with their experiences. > > Regards > Alexander > > Alexander Neilson > Neilson Productions Limited > > alexander(a)neilson.net.nz > 021 329 681 > 022 456 2326 > > > On 25/11/2014, at 11:51 am, Dave Mill <dave(a)mill.net.nz> wrote: > > > > I'm actually surprised that our GCSB overlords haven't done something > like this sooner. To me it seems pretty obvious that not all network > providers are using/following the new guidelines. And much better an email > like this one than a proper slap by the NCSC/GCSB. > > > > To explain my logic without giving too much away. > > > > We are a small ISP. We have submitted proposals under this new law. Lets > call our number of proposals X. > > > > At a technical conference recently the GCSB were able to share with us > their rough total number of proposals. That number was also reasonably > obvious from the proposal numbering system the NCSC use. Lets call this > number Y. > > > > Y wasn't that much bigger than X. I'm talking 5 or 6 times bigger from > memory. > > > > We have spent a lot of time and effort in following this new > legislation. I think its only fair that others do also (lets not debate > whether we needed the legislation here). And with the numbers talked about > so far I think its pretty clear that some organisations out there aren't > following this new legislation. > > > > At the very least (based on Ray's comments) most network operators > should be submitting at least 5 - 10 standard builds each IMHO. > > > > Cheers > > Dave > > > > > > On Mon, Nov 24, 2014 at 8:30 PM, Ray Taylor <ray(a)ruralkiwi.com <mailto: > ray(a)ruralkiwi.com>> wrote: > > I am assuming this refers to notifications about equipment changes, > vendor suppliers etc? > > > > It may come as a surprise to these people but most network operators > create standards and stick to them! > > > > > > > > > > > > > > > > Ray Taylor > > > > Taylor Communications > > > > ray(a)ruralkiwi.com <mailto:ray(a)ruralkiwi.com> > > > > > > Ph 021-483-280 > > > > Network status 06-929-9082 > > > > > > > > <image001.png> > > > > > > > > From: TICSA [mailto:TICSA(a)ncsc.govt.nz <mailto:TICSA(a)ncsc.govt.nz>] > > Sent: Monday, 24 November 2014 3:21 p.m. > > To: TICSA > > Subject: Letter to Network Operators 24 Nov 2014 > > > > > > > > Dear Network Operator > > > > > > > > Please find attached a letter to all network operators. This letter > shares our surprise at the low number of notifications received from > registered network operators to date. We want to reinforce that we are here > to support you in meeting your obligations under the TICSA. > > > > > > > > We thank those network operators who have actively engaged with us under > the TICSA since May. > > > > > > > > > > > > Kind regards > > > > From the TICSA Team > > > > > > > > > > > > This electronic message, together with any attachments, contains > information that is provided in confidence and may be subject to legal > privilege. Any classification markings must be adhered to. If you are not > the intended recipient, you must not peruse, disclose, disseminate, copy or > use the message in any way. If you have received this message in error, > please notify us immediately by return email and then destroy the original > message. > > The Government Communications Security Bureau (GCSB) accepts no > responsibility for changes to this e-mail, or to any attachments, after its > transmission from GCSB. Thank you. > > > > This email has been filtered by SMX. For more information visit > smxemail.com <http://smxemail.com/> > > _______________________________________________ > > NZNOG mailing list > > NZNOG(a)list.waikato.ac.nz <mailto:NZNOG(a)list.waikato.ac.nz> > > http://list.waikato.ac.nz/mailman/listinfo/nznog < > http://list.waikato.ac.nz/mailman/listinfo/nznog> > > > > > > _______________________________________________ > > NZNOG mailing list > > NZNOG(a)list.waikato.ac.nz > > http://list.waikato.ac.nz/mailman/listinfo/nznog > >

1 0

ntp.net.nz Update
by Josh Simpson 24 Nov '14

24 Nov '14

Hi NZNOG, Time for an update with regards to ntp.net.nz servers. On the morning of Saturday Nov 22, ntp3.ntp.net.nz failed with a similar issue to that of ntp2.ntp.net.nz, this happened just a few weeks short of the new ntp2 go live. Due to this event we have pushed the new ntp2 appliance into service as well as reconfiguring another new appliance that was to be ntp4 as a ntp3 replacement. Both of these went live on Nov 22 at 18:06 hours, along with reverting the DNS ntp2 -> ntp3 redirection changes that were made in the July 14th email. As part of this the IP addresses for ntp2 and ntp3 have changed to the following ntp2.ntp.net.nz: 202.46.178.18 ntp3.ntp.net.nz: 202.46.179.18 ntp2 was unavailable via IPv6 prior to the failure, we have plans to resolve this in the near future. ntp3 is now unavailable via IPv6 due to the short time span of the work on Saturday, we hope to have this resolved in the coming weeks. We will update the list when IPv6 is back up and running. If you had previously used the IP addresses in your configs be sure to update them. We do recommend using the DNS names specified at https://ntp.net.nz to avoid this issue in the future. If you need any further information, please contact us at support(a)nzrs.net.nz Cheers Josh -- Josh Simpson Systems Administrator .nz Registry Services M: +64 21 783 399 P: +64 4 555 0124 GPG: 6516 B4EA 413B CAED 57B5 0956 124C 8AC3 A362 8080 www.nzrs.net.nz

2 1

Network Monitoring VPS in exchange for VPS from us in return.
by daniel＠glovine.com.au 23 Nov '14

23 Nov '14

Hi Noggers, I was wondering if a couple of providers whom wouldn't mind swapping a small VPS for a small VPS from us, in order for us to run a couple of external network monitoring tools from, Looking for providers whom are on MegaPort Sydney IX Looking for providers whom are on NSW IX Looking for providers whom are not on Vocus transit These requirements above are not all necessary to meet, a mix would be handy and dandy :D, Would even consider providers in QLD, Perth, Melbourne Pritty much Australia wide even NZ is a consideration If you wouldn't mind and you are interested please shoot me an off-list reply for further details and discussions TIA Daniel

1 0