Rubicon: From my understanding, Geekzone has an IPv6 tunnel provided by Hurricane Electric, served from a PoP located in Singapore. This would be HE's geographically closest PoP to NZ. I'm making this assumption based on the source address of the return IPv4 leg of a 6to4 connection (216.218.221.42, tserv1.sin1.he.net).
In my case (Wellington, ISP TelstraClear), an IPv6 connection to geekzone.co.nz takes the following route:
1.|-- 2002:xxxx:xxxx:1::1
2.|-- 2002:cb62:2af0::
3.|-- xe-0-0-0-916.xcore1.telstraclear.net
4.|-- ???
5.|-- i-0-0-4-1.tlot-core01.bx.telstraglobal.net
6.|-- lapeer-equinix.net.reach.com
7.|-- 10gigabitethernet1-3.core1.lax1.he.net
8.|-- 10gigabitethernet1-4.core1.hkg1.he.net
9.|-- 10gigabitethernet1-2.core1.sin1.he.net
10.|-- 2002:d8da:dd2a::1
11.|-- 2001:470:35:4d4::2
The fact that my packets cross the Pacific Ocean twice on their journey to Singapore is not the fault of Geekzone. It's most likely due to TelstraClear routing any traffic to Hurricane Electric via their Los Angeles PoP. This is probably as a default route through TelstraClear's upstream provider, Reach. A similar scenario would apply for others who see their traffic going via the west coast of the USA. Most ISPs should be able to implement a quicker (but not necessarily cheaper) route via Australia if they had reason to.
In general, if connections show strange or inefficient routing, your ISP would be the first port of call for fixing the problem.
For the record, I am in favour of Geekzone keeping the AAAA record for geekzone.co.nz active.
Alot of assumptions there, LAX is one of HE's biggest handover point's and is a natural selection given it's pretty much the handover point for southern cross, Getting L2 transit into SIN means SCC to SYD and then another link from AU to SIN from another cable over there, The same thing occurs(ed) with a couple of transit operators in NZ when getting to SIN for a while aswell - Went via LA
Tracing route to sea.battle.net [202.9.66.38]
over a maximum of 30 hops:
5 171 ms 160 ms 160 ms te4-4.mpd01.lax05.atlas.cogentco.com [38.104.84.29]
6 160 ms 160 ms 160 ms i-1-3-peer.eqla01.pr.reach.com [134.159.63.197]
7 130 ms 130 ms 129 ms i-0-0-0-0.tlot-core01.bi.reach.com [202.84.251.193]
8 292 ms 291 ms 291 ms i-3-3-2.tmh-core04.bx.reach.com [202.84.249.81]
9 398 ms 397 ms 411 ms i-6-1.6ntp-core01.bx.reach.com [202.84.143.165]
10 403 ms 401 ms 402 ms i-0-1-0-1.6ntp01.bi.reach.com [202.84.180.142]
11 390 ms 390 ms 397 ms unknown.net.reach.com [202.126.173.182]
12 421 ms 421 ms 422 ms 27.111.222.65
13 390 ms 400 ms 398 ms 27.111.222.82
14 * * * Request timed out.
15 * * ^C
It's changed for some recently with l2 pipe buys from pacnet but was just they way NZ got to SIN for a long time.
If GZ is to keep the quad a then atleast move the tunnel endpoint to LAX so we get stuck with 130-160ms rather than 500+ but at the end of the day why degrade the experience at all? Nag the DC for v6 and turn it off until they give it to you - Everyone's happy including the guys who will get the calls wanting to know why some sites are slow, Nobody coming here is v6 only yet