wondering if anyone from TVNZ On Demand is on this list and wouldn't
mind contacting me offlist regarding problems streaming if a user has an
IPv6 address. The helpdesk doesn't appear to know what ipv6 is so
thought I'd try an alternative.
I hope everyone is having a good break !
If anyone out there has had any of their customers PBX's hacked recently
(in the last 2 - 3 weeks) and have experienced a large call flow to say
Somalia or some other dodgy destination id be keen to hear from you, I'm
after the destination numbers they are dialling.
replies off list would be great.
Registrations have been open for the conference for a while now and
I'm pleased to say that they are at an unprecedented level for this
time of year.
Given that we've only just released the program, thats an outstanding
achievement. With some great help from InternetNZ the conference is
shaping up to
be as awesome as usual.
First up I'd like to thank the sponsors who have signed on thus far:
Go Wireless - Gold
Network Hardware Resale - Gold
Vocus - Gold
CityLink - Gold
GKC - Silver
Brocade - Silver
Arbor Networks - Silver
APNIC - Silver
Extreme Networks - Silver
Kordia - Bandwidth Sponsor
We have more slots open for sponsorship as well as the much coveted
Platinum sponsor position. If you would like to ensure that your
organisation gets high visability at the event then contact
sponsorship(a)nznog.org for a sponsorship pack.
We know that the program is an important part of convincing your
organisations that you need to attend.
This year we've got a wide range of speakers lined up along with some
great Workshops and tutorials.
Tom Paseka (CloudFlare) - NZ Perspectives from a global CDN
Roland Dobbins (Arbor Networks) - TBA
Geoff Huston (APNIC) - Measuring DNSSEC
Jamie Baddeley (Citylink) - NZIX2/Citylink SDN
Sam Russell (REANNZ) - Building a better Skype with WebRTC, SIP, and ENUM
Barry Brailey (DNC) .nz DNSSEC programme
Jean-Sébastien Fontana (Extreme Networks) - Introduction to TRILL
Gerard Creamer (Netspace) - Experiences with dual A records vs anycasting
Beatty Lane-Davis (Cyan) - SDN & NFV
Michael Fincham (Unleash) - RPKI
Peter Gent (MBIE) - 5GHz Wireless Links
Jan Jorz (ISOC) - BCOP Project
Quintin Russ (SiteHost) - IPv6 deployment in the cloud
Network Infrastructure Security
OpenDNSSEC Installation and Configuration (1/2 day)
SDN/OpenFlow Installation (1/2 day)
Mikrotik Routing (full day)
APNIC Internet Resource Management (1/2 day)
We'd suggest you register now. At least this side of Xmas. Flights,
Accommodation etc will likely be easier and cheaper the sooner you do
it. Better than doing it in a panic in mid January.
For more information on how to register, head off to
See you all there.
I have a question which I'm hoping the NZNOG community can help me with.
Within NZ, what is the maximum number of hops from APE to any consumer's
interface device? (smarty-phone, ADSL modem, whatever)? Or more
pragmatically, let's say the 99th percentile, as in, fewer than 1% of
customers are more than X hops away from APE.
If this information is already available, I'd appreciate a pointer,
If you are an ISP could you give me an indicative number of hops from APE to
your customers' CPE. If you can include a prefix length reflecting the
number of affected customers that would help too. (Ideally the maximum
across all your customers, but if you have a few oddball customers with
longer paths, just the 99% will do.)
If you're an ISP customer and would like to tell me your hop-count to APE
(counting from your CPE, not from your computer) and your ISP's name, that
would also be appreciated.
Replies off-list and I will summarize back to the list.
Here's the background:
I'm investigating ways of limiting traffic so that it does not leave New
Zealand, that can be configured on an application-by-application basis.
Obviously if one has an upstream to "global" and a separate upstream to APE
or WIX, then it's simple to filter traffic at those egresses.
However for the average end-user, it's difficult to get multiple VLANs to
their provider, let alone multiple physical links.
In an ideal world, one would simply set some QoS bits and your upstream
would understand them and do the filtering based on *their* egress, but in
practice I haven't heard of any suppliers offering such a service.
So I'm looking at DIY options ...
In particular, I'm looking at setting the TTL on outgoing packets. We know
how many hops it is from "our" hosts to APE, and I guestimate no more than 2
hops from a consumers border device (modem, whatever) to their client
So far it looks like setting the TTL so that it's down to 5 at APE will mean
most of NZ is reachable, and most of the rest of the world isn't, assuming
the international provider is as many hops from me as APE.
But I'd really like to get a firmer idea of "how much of NZ will be
unreachable given an egress hop limit of X?"
(The idea is to find X where the list of exception prefixes is small enough
to manage manually, while still blocking the majority of foreign traffic.)
What I'd like to find out from the NZNOG community is the distribution of
customers at various hop-counts from APE.
FYI - the Auckland node of F.ROOT-SERVERS.NET has been offline for the
past couple of years due to HW failure, access issues @SkyTower, changes
with our hosts (contacts and access to said data center). I am happy to
report that the node is finally back online and advertising F's prefixes
to the APE fabric as I type...
So come and send your DNS root server queries locally instead of sending
them off-shore. We are AS23710 @APE, so if you don't peer with us
already, pop us a note at peering(a)isc.org.
Yes, Telecom NZ, I am looking at you. Yes, you... (a guy can dream, even
if it is hopeless) ;)
There are many folks to thank as ISC could not do it alone including:
- NZRS (Jay, Sebastian and Dave) for sponsoring the new server gear.
- APNIC for sponsoring the new routers. (sorry to see the old Juniper
kit go though)
- Sebastian and Mike Jager for dealing with my numerous remote hands
requests from the other side of the world.
- The Kiwi Internet Mafia (Joe Abley, AJ, Jonny) for their support and
access to their contacts to keep things moving.
- Vodafone NZ and FX Networks for (now redundant) transit over IPv4 and
- Our peers at APE that have put up with us for being down so long... :)
O.k., commercial over; back to serving packets again.
Best Wishes - Peter
[ plosher(a)isc.org | Senior Operations Architect | ISC | PGP E8048D08 ]
I'm curious to know which of the following methods is more widely
used/accepted today for publishing web servers to the Internet.
1) Dual-home the server - place one NIC on the internet and a second NIC on
an internal network for administration, or
2) DNAT/Port Forward my external IP to my internal IP
3) Both - Dual home the server onto two private subnets (external/internal)
and DNAT/Port Forward the public IP to the external subnet IP
In either case:
a) I will be hiding behind a dedicated firewall appliance and not relying
on the OS firewalls
b) the internal network will still be in its own subnet firewalled away
from the rest of the network
c) Only HTTP/HTTPS will be permitted from the internet, no RDP, SSH etc
d) I will be deploying IPv6 to this machine in the next 12 months which
makes option 1 more attractive
I personally like option 1 but I'm looking to see if theres any facepalm
reasons I shouldn't do it this way.
We have published the program for JANOG 33 and welcome you to join us in
Beppu City, Japan, from 23rd-24th Jan 2014.
Most sessions are in Japanese only but there are a few sessions in English.
You are also welcome to connect with us through facebook and twitter for
updates in English. The JANOG SNS accounts are open to everyone,
including those who are not able to attend the meeting.
See you in Beppu.
Shinichi Yamamoto, Chin Sze Yih, Izumi Okutani
JANOG Internationalization team for JANOG 33
JANOG 33 Program :
The Program is available in English at:
Translations of the program titles and abstracts were supported by
volunteers on the best efforts basis.
During the meeting, there will be no official interpretations in
English, except for the sessions marked as (English session).
You can register online at:
Deadline: 10th Jan 2014 JST 15:00
SNS Accounts :
Facebook : https://www.facebook.com/janogmeetingi18n
Twitter : https://twitter.com/janog_i18n
e + j: daniel(a)pch.net
c: +64 (21) 845158
A story along a similar line that reinforces this view:
I put a phone on public IP space a few weeks back, then got sidetracked while configuring it. Before I had even returned to enter a new admin password and the correct SIP details (only 1/2hr later!), the phone had already been attempting to dial out on it's own. Turns out a robot had found it on it's public IP with port 80 open and started issuing it dial commands before I even had a chance to go about locking it down.
It was unable to dial out as it hadn't had the correct SIP server or login details configured, but it just goes to show that the device really need to be locked down _before_ being put on any publicly accessible IP space, even if just for provisioning purposes!
On 8/12/2013, at 3:17 PM, "Dobbins, Roland" <rdobbins(a)arbor.net> wrote:
> On Dec 8, 2013, at 8:46 AM, Don Gould <don(a)bowenvale.co.nz> wrote:
>> Clearly you can't even put a quick and dirty box in place to just prove a concept without having to bolt it down.
> Correct - it simply isn't viable to expose an unpatched/unsecured box to the Internet at all, due to all the automated scanning/hacking activities taking place.
> +1 to the other folks who recommended more workable solutions - 'GeoIP' isn't exact at all, and not all bad nodes (of any nationality) are in China.
> Roland Dobbins