Subject: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-08.txt

From: [email-masked]
Date: Thu, 13 Nov 2014 15:47:28 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the IPv6 Operations Working Group of the IETF.

        Title           : Deprecating Anycast Prefix for 6to4 Relay Routers
        Authors         : Ole Troan
                          Brian Carpenter
	Filename        : draft-ietf-v6ops-6to4-to-historic-08.txt
	Pages           : 7
	Date            : 2014-11-13

Abstract:
   Experience with the "Connection of IPv6 Domains via IPv4 Clouds
   (6to4)" IPv6 transition mechanism defined in RFC 3056 has shown that
   the mechanism is unsuitable for widespread deployment and use in the
   Internet, especially in its anycast mode.  This document requests
   that RFC 3068, "An Anycast Prefix for 6to4 Relay Routers", be made
   obsolete and moved to historic status.  It also recommends that
   future products should not support 6to4 anycast and that existing
   deployments should be reviewed.  Thus it updates the guidelines in
   RFC 6343.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-v6ops-6to4-to-historic/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-v6ops-6to4-to-historic-08

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-6to4-to-historic-08

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 14 Nov 2014 12:52:47 +1300

OK, this is a quick update to include the changes I had in my edit
buffer - they reflect the last couple of days' comments on the text.

Two points:

1. I failed to consult Ole about this update, so he is entitled
to raise objections.

2. I didn't intentionally change the main recommendations in any way.
Of course, they are still open for debate when the WGLC starts
in a day or two.

    Brian

---

From: Nick Hilliard <[email-masked]>
Date: Fri, 14 Nov 2014 11:16:14 +0000

> buffer - they reflect the last couple of days' comments on the text.

Brian,

two issues:

1.

> Internet service
>    providers SHOULD filter out routes to 192.88.99.1.  However, networks
>    SHOULD NOT filter out packets whose source address is 192.88.99.1,
>    because this is normal 6to4 traffic from a 6to4 return relay
>    somewhere in the Internet.

this text is probably not a good idea and I'm inclined to think that it
would be better to leave it out entirely.  If connectivity service
providers filter out forward routes to 192.88.99.1, existing 6to4 tunnels
may break.

The current wording also doesn't make a whole pile of sense for operators
who deploy urpf.  I.e. no forward path means filter on src address.

The simplest thing would be to stick with deprecation without recommending
breakage.

2.

> IPv6-only service providers are
>    advised that their own customers need such a relay to be available in
>    case a residual 6to4 user served by a different service provider
>    attempts to communicate with them.

"IPv6-only service providers"?  Hmm.

If they exist, all they need is a route to a relay.  If they have a relay
then by definition they're not IPv6-only service providers, right?

Nick

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 15 Nov 2014 06:44:07 +1300

> providers filter out forward routes to 192.88.99.1, existing 6to4 tunnels

Yes. I gathered that was what people in the room wanted. Other opinions?

> who deploy urpf.  I.e. no forward path means filter on src address.

Good point, but for those who don't apply urpf it remains valid
I think; needs a few extra words.
> "IPv6-only service providers"?  Hmm.

Well, yes, they exist and there will be more.

> then by definition they're not IPv6-only service providers, right?

They need an IPv6 route to 2002::/16, and the relay is by definition
placed at the IPv6/IPv4 boundary. Yes, the words need a little tuning
for that.

Thanks

   Brian

> 
> Nick
> 
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: Nick Hilliard <[email-masked]>
Date: Sun, 16 Nov 2014 22:39:28 +0000

> Yes. I gathered that was what people in the room wanted. Other opinions?

The minutes say that it was a weak hum vs very weak hum.

There's a difference between deprecation and a recommendation to actively
cause breakage.  Deprecation is a statement that something shouldn't be
used because it's a bad idea.  Actively recommending breakage is a
different matter entirely.  If you want to change the semantics of the ID,
you should rename it to match.

Despite being a paid-up member of the burn-6to4-with-fire camp, I really
don't think that the IETF should recommend that operators actively block
their end-users from being able to do something, even if we all think it's
a rotten poor idea.  The protocol is dying quite nicely by itself without
operator intervention.

>>>    attempts to communicate with them.
[..]
> placed at the IPv6/IPv4 boundary. Yes, the words need a little tuning

suggestion: "IPv6-only service providers are advised that their own
customers need a route to such a relay in case a residual 6to4 user..."

Nick

---

From: Lorenzo Colitti <[email-masked]>
Date: Sun, 16 Nov 2014 14:39:51 -1000

> providers filter out forward routes to 192.88.99.1, existing 6to4 tunnels

+1. What is dropping routes to 192.88.99.1 supposed to accomplish? It's not
going to stop implementations from attempting to send packets 192.88.99.1
for 6to4 relay service, it's only going to reduce the chance that said
packets make it to their destination.

What we need to do here is try to stop new implementations from using
192.88.99.1. But when someone tries to use it, the only thing that makes
sense is try to deliver the packets.

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 17 Nov 2014 13:57:32 +1300

> sense is try to deliver the packets.

Why is that doing the user a favour? We know the mechanism is
unreliable, with numerous black holes due to issues with the
return relay, so why isn't it better to ensure that it fails
predictably?

   Brian

---

From: Lorenzo Colitti <[email-masked]>
Date: Sun, 16 Nov 2014 15:02:00 -1000

> return relay, so why isn't it better to ensure that it fails

Making things fail predictably is useful if the failure will cause the
requesting party to try something else. In this case, the requesting party
(i.e., the node that sent the packet to 192.88.99.1) will a) almost
certainly not know that things failed, and b) will not know what else to do.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 17 Nov 2014 02:06:04 +0100 (CET)

On Mon, 17 Nov 2014, Brian E Carpenter wrote:

> unreliable, with numerous black holes due to issues with the return 
> relay, so why isn't it better to ensure that it fails predictably?

Do we know what implementations do when they can't reach the IPv4 based 
relay? Do they generally turn themselves off? RFC3068 doesn't specify 
client behaviour. I couldn't find anything in 3056 either...

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Lorenzo Colitti <[email-masked]>
Date: Sun, 16 Nov 2014 15:07:33 -1000

> client behaviour. I couldn't find anything in 3056 either...

How would they know that they "can't reach the IPv4 based relay"?

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 17 Nov 2014 14:27:35 +1300

> How would they know that they "can't reach the IPv4 based relay"?

*In theory* if they get ICMP "Destination unreachable" they
could disable 6to4. I suspect that is indeed only theory.

In reality Happy Eyeballs will simply observe success with IPv4
and timeout with IPv6, for one site at a time. Without HE, we
are back to the help desk advising "Turn off 1Pv6".

One could imagine adding a heuristic to HE, along the lines
off: if N successive IPv6 addresses all fail to connect,
then disable the IPv6 interface for time T.

Back on topic: I will try to log issues during the WGLC
so that we can summarize and review at the end.

    Brian

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 17 Nov 2014 02:32:17 +0100 (CET)

> How would they know that they "can't reach the IPv4 based relay"?

Pinging its own 6to4 IPv6 address before starting to use 6to4? Looking for 
ICMP unreachable messages? There are probably more ways...

---

From: Lorenzo Colitti <[email-masked]>
Date: Sun, 16 Nov 2014 15:34:13 -1000

> ICMP unreachable messages? There are probably more ways...

None of which are likely to be supported by existing implementations. And
new implementations will hopefully follow the advice in this document and
turn off 6to4, which means they won't have this problem.

---

From: James Woodyatt <[email-masked]>
Date: Mon, 17 Nov 2014 11:54:08 -0800

Unless I'm mistaken, what AirPort™ will do when operators turn off their
6to4 relays and drop their route to 192.88.99.1 is it will start blinking
its light and throwing an alert with a diagnostic message that their IPv6
tunnel isn't working anymore every time the unit starts up.

In this state, it will still try to use the relay, of course, but at least
the user gets a warning that it's believed not to work.  (It's especially
amusing when the check for the relay service fails to receive an ICMPv6
echo response, but the tunnel continues to work anyway. Add this to the
list of confusing things about 6to4 that make this particular service a
danger to itself and others.)

On Sun, Nov 16, 2014 at 5:06 PM, Mikael Abrahamsson <[email-masked]>
wrote:

>  Why is that doing the user a favour? We know the mechanism is unreliable,
>> with numerous black holes due to issues with the return relay, so why isn't
>> it better to ensure that it fails predictably?
>>
>

-- 
james woodyatt <[email-masked]>
Nest Labs, Communications Engineering

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 17 Nov 2014 22:40:15 +0100

Le 17/11/2014 02:06, Mikael Abrahamsson a écrit :
> relay? Do they generally turn themselves off?

No they dont turn off, they keep sending packets in that direction.

> RFC3068 doesn't specify

Should be Router behaviour.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 17 Nov 2014 22:42:20 +0100

Le 17/11/2014 02:32, Mikael Abrahamsson a écrit :
> Pinging its own 6to4 IPv6 address before starting to use 6to4? Looking
> for ICMP unreachable messages? There are probably more ways...

I guess yes.

But it could be an IPv4 means - request an IPv4 echo from the 6to4 Relay.

Alex

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 18 Nov 2014 13:25:41 +1300

> But it could be an IPv4 means - request an IPv4 echo from the 6to4 Relay.

Many things are possible, but even when RFC 6343 was written, we
assumed that nobody would do any more enhancements of 6to4
client code. What is out there now is all there is ever going to be.

    Brian

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 18 Nov 2014 04:08:58 +0100 (CET)

> But it could be an IPv4 means - request an IPv4 echo from the 6to4 Relay.

That is meaningless because that gives no indication if the 6to4 relay 
actually functions as a 6to4 relay or not.

---

From: David Farmer <[email-masked]>
Date: Tue, 18 Nov 2014 14:29:19 -0600

On 11/16/14, 16:39 , Nick Hilliard wrote:
...
> a rotten poor idea.  The protocol is dying quite nicely by itself without

The goal is to not break active and successful users of 6to4.  However, 
we don't want to perpetuate zombiefied (half-broken) 6to4 relays either. 
  If it is Ok for relay server operators to turn-off relays, at some 
point it needs to be Ok for network operators to not carry the route as 
well.

How about;

     Internet service providers SHOULD announce a route to 192.88.99.1
     if and only if it leads to a correctly operating anycast relay as
     described in RFC 6343.  As traffic diminishes and there are no
     longer any correctly operating anycast relays topologically near,
     networks MAY filter out routes to 192.88.99.1 completely.  However,
     even if no route to 192.88.99.1 is available, networks SHOULD NOT
     filter out packets whose source address is 192.88.99.1, because
     this is normal 6to4 traffic from a 6to4 return relay somewhere in
     the Internet.

-- 
================================================
David Farmer               Email: [email-masked]
Office of Information Technology
University of Minnesota
2218 University Ave SE     Phone: 1-612-626-0815
Minneapolis, MN 55414-3029  Cell: 1-612-812-9952
================================================

---

From: [email-masked]
Date: Tue, 18 Nov 2014 22:30:12 +0100 (CET)

> point it needs to be Ok for network operators to not carry the route as 

We turned off our 6to4 relay at the end of 2012. We certainly have
no plans to turn it on again. 

However - I see no need to deliberately remove the 192.88.99.1 route.
It will disappear when the last 6to4 relay is turned off.

Steinar Haug, AS 2116

---

From: David Farmer <[email-masked]>
Date: Tue, 18 Nov 2014 17:01:19 -0600

> It will disappear when the last 6to4 relay is turned off.

- I don't want you to deliberately remove the route for any properly 
working relays.

- I want you to actively select only routes to working relays that are 
relatively close, NOT relays on the other side of an ocean.

- When there are NO working relays left, it is OK if you have no route 
for 192.88.99.1, you shouldn't feel obligated to have a relay route. 
The idea is to deprecate RFC3068.

-  You shouldn't deliberately go kill off routes for 192.88.99.1, but 
you should kill off non-working routes, and if the last one is +100ms 
RTT away then maybe you can kill it off too.

---

From: Mark Andrews <[email-masked]>
Date: Wed, 19 Nov 2014 10:32:49 +1100

> relatively close, NOT relays on the other side of an ocean.

Relays on the other side of the world work more than well enough
having used tunnels that cross the Pacific everyday for the last
decade for IPv6.  For me the only destinations that suffer a slight
delay are to Australia and even then they still work.

All American sites are OK (both North and South).  All European
sites are OK.  All African sites are ok.  And even Asian sites are
ok despite the triangular routing both ways.

I often get *better* connectivity of over tunneled IPv6 than I do
with native IPv4 to all these parts of the world and HE takes care
of Australia.

I'm much more worried about 1800ms of buffer bloat delay than
150-300ms of additional RTT delay that happens sometimes due to
using a non topologically close tunnel end point.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Doug Barton <[email-masked]>
Date: Tue, 18 Nov 2014 19:36:35 -0800

> relatively close, NOT relays on the other side of an ocean.

the problem with your plan is that the eyeball networks have already 
spoken (by omission) that they will not do this work. The weakness of 
6to4 from day 1 is that it requires people who have no economic 
incentive to do a lot of extra work. We know now, quite conclusively, 
that this pig doesn't fly.

I remember the "good old days" of the Internet when people took time out 
of their day to do the right thing for no other reason, and/or went out 
of their way to help someone else's network. Some of that still exists 
of course, but not in anywhere near the quantities that are necessary to 
make 6to4 work.

Since we know it does not, and will not work, marking it historic and 
moving on seems to be a rational course.

Blocking routes to the relays also seems rational to me, since it will 
help those users on older systems whose 6to4 attempts will fail quickly 
and decisively, rather than slowly and painfully.

Users who truly want IPv6 connectivity will still have methods of 
achieving that.

Other than the lingering ennui around, "It was such a cool idea, I wish 
it would have worked better ..." why are we still having this 
conversation? :)

Doug

---

From: Tore Anderson <[email-masked]>
Date: Wed, 19 Nov 2014 07:23:50 +0100

* David Farmer

> > However - I see no need to deliberately remove the 192.88.99.1
> > route. It will disappear when the last 6to4 relay is turned off.
> 
> - I want you to actively select only routes to working relays that
> are relatively close, NOT relays on the other side of an ocean.
> 
> - When there are NO working relays left, it is OK if you have no
> route for 192.88.99.1, you shouldn't feel obligated to have a relay
> route. The idea is to deprecate RFC3068.
> 

IMHO, it's rather unrealistic to expect operators to actively monitor
third-party 192.88.99.1 for correct operation or not (how do you do
even do that, exactly?), and accepting/filtering the route as a result.
My routers have certainly no such functionality, and I'm certainly not
about to spend time on making some complicated provisioning system that
does something like this.

So, for me the situation could be summed up as follows:

- Do I have routes to 192.88.99.1 + 2002::/16? Yes. (I had to check.)
- Do they work? I haven't the foggiest.
- Do I care if they don't? Not even slightly.
- Do I want to filter them unconditionally? No. Doing so would require
  me to care about 6to4. I don't.

So if some 6to4 user can successfully communicate with my native IPv6
stuff, good for him. If it doesn't work, he's on his own. I'm not
spending any more energy on that stinking piece of dung.

Tore

---

From: [email-masked]
Date: Wed, 19 Nov 2014 08:03:43 +0100 (CET)

> does something like this.

Precisely. I see no reason to use any time on 6to4 when it could be
much more productively used on native IPv6.

> spending any more energy on that stinking piece of dung.

+1.

And the conclusion to this is: RFC text which try to make me care
about 6to4 is highly likely to be ignored.

Steinar Haug, AS 2116

---

From: Tim Chown <[email-masked]>
Date: Wed, 19 Nov 2014 07:35:58 +0000

> It will disappear when the last 6to4 relay is turned off.

I wonder what the first publicly announced IPv4 6to4 relay was. Perhaps SWITCH (via Simon Leinen) or FUNET (Pekka Savola)?  I remember the days of SWITCH’s relay being a world 6to4 magnet.

Would be poetic to let them be the last to switch off too, if they’re still running :)

Tim

---

From: Jeroen Massar <[email-masked]>
Date: Wed, 19 Nov 2014 08:56:49 +0100

BCC'ing [email-masked] thus a bit of background info:

draft-ietf-v6ops-6to4-to-historic-08.txt currently contains:

Section 4 "Deprecation"
8<------------------------
   Current operators of an anycast 6to4 relay with the IPv4 address
   192.88.99.1 SHOULD review the information in [RFC6343] and the
   present document, and then consider carefully when the anycast relay
   can be discontinued as traffic diminishes.  Internet service
   providers SHOULD filter out routes to 192.88.99.1.  However, networks

   SHOULD NOT filter out packets whose source address is 192.88.99.1,
   because this is normal 6to4 traffic from a 6to4 return relay
   somewhere in the Internet.
------------------------>8

Hence this BCC to poll what the operators of these current relays think
about this and what they think they will do.

Note that the discussion is really taking place on [email-masked] hence
to post you either have to be (temporarily) subscribed and/or post
anyway and wait for one of the listadmins to approve your messages.

Below the view that RIPEs RIS thinks are the current 6to4 anycast relays.

On 2014-11-19 08:35, Tim Chown wrote:
[..]
> I wonder what the first publicly announced IPv4 6to4 relay was.
> Perhaps SWITCH (via Simon Leinen) or FUNET (Pekka Savola)?
> I remember the days of SWITCH’s relay being a world 6to4 magnet.
>

Afaik the SWITCH one is gone for a long long time already.
FUNET is still up, but only limited in BGP, only RRC13 in Moscow sees
it, which is funny as for instance RRC07 in Stockholm does not.

The list:
https://stat.ripe.net/widget/looking-glass#w.resource=192.88.99.1

 8903 = ES BT Espana
 6939 = US Hurricane Electric*
 7575 = AU AARnet
16150 = SE Availo (Port80)*
12779 = IT ItGate*
 1103 = NL Surfnet*
 8954 = NL Intouch*
15598 = DE QSC AG
28917 = RU FIORD AS
21416 = RU TCINET
 1741 = FI FUNET*
 8359 = RU MTS
44581 = SE AllTele

Note that only 6939/7575/8903 are 'globally' visible, others seem to
have very limited announcement.

* = person who operates it is well known, all of which will be on
ipv6-ops@ hence, BCCd them that way to get them into the loop on this
discussion as they will be the folks disabling those boxes or not.

Greets,
 Jeroen

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 19 Nov 2014 12:35:20 +0000

On 18/11/2014 20:29, David Farmer wrote:
> If it is Ok for relay server operators to turn-off relays, at some point it
> needs to be Ok for network operators to not carry the route as well.

Yeah.  No.

It's entirely a local decision as to whether to turn off a relay server or
not, or to advertise 192.88.99.0/24 beyond one's own ASN.  Relay server
operators do not have a responsibility to anyone outside their ASN and if
they decide to pull a service, that's their own prerogative and no-one
else's.  If it happens that theirs was the last 6to4 relay visible in the
DFZ, then so be it - they have no responsibility whatsoever to carry third
party traffic on their routers.  If 6to4 dies globally one day due to
someone pulling the plug in Elbonia, I will continue clipping my toenails.

This is an completely different matter to making a conscious decision to
filter out 192.88.99.0/24, or having an IETF RFC recommending that this be
done.  As a network service operator, it's not my responsibility to
determine whether end users should be able to access this or not.

It would also set an alarming precedent if the IETF felt it has the
authority to demand that operators filter out specific traffic types. This
is a political, legal and technical minefield that the IETF should avoid by
a wide margin.

Nick

---

From: Jeroen Massar <[email-masked]>
Date: Wed, 19 Nov 2014 13:37:59 +0100

> is a political, legal and technical minefield that the IETF should avoid by

I am in full agreement with Nick here.

Greets,
 Jeroen

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 20 Nov 2014 08:06:31 +1300

With the same Bcc:

>    Internet service
>    providers SHOULD filter out routes to 192.88.99.1. 

It is pretty clear enough to me (as document editor) that there
is no consensus in the v6ops WG for this sentence, which was
added after some earlier discussion in the WG. The final
consensus has to be judged by the WG chairs, but my guess is
that we'll delete that sentence and leave the decision up to
individual operators.

(The argument is that this route helps people who are still
successfully using anycast 6to4, whether intentionally or by
default, and filtering it would hurt them without helping anyone
else.)

Regards
   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 20 Nov 2014 08:28:47 +1300

Regards
   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 20 Nov 2014 08:29:01 +1300

Regards
   Brian

---

From: Nick Hilliard <[email-masked]>
Date: Thu, 20 Nov 2014 21:49:35 +0000

naah, it's still there - just not announced over transit:

> switch01.ring.nlnog.net:~$ traceroute 192.88.99.1
> traceroute to 192.88.99.1 (192.88.99.1), 30 hops max, 60 byte packets
>  1  swiCS3-V27.switch.ch (195.176.255.2)  0.443 ms  0.430 ms  0.524 ms
>  2  swiEZ2-10GE-5-2.switch.ch (130.59.36.18)  0.375 ms  0.396 ms  0.396 ms
>  3  swiEZ1-P2.switch.ch (130.59.36.25)  0.366 ms  0.366 ms  0.362 ms
>  4  swiBA2-10GE-1-4.switch.ch (130.59.37.106)  1.295 ms  1.353 ms  1.387 ms
>  5  swiBE2-10GE-1-3.switch.ch (130.59.37.109)  2.677 ms  2.803 ms  2.907 ms
>  6  swiBE1-V300.switch.ch (130.59.36.197)  2.518 ms  2.581 ms  2.695 ms
>  7  swiFR2-10GE-3-1.switch.ch (130.59.36.105)  2.948 ms * *
> switch01.ring.nlnog.net:~$

Nick

---

From: [email-masked]
Date: Fri, 21 Nov 2014 09:29:37 +0100

> I wonder what the first publicly announced IPv4 6to4 relay was. Perhaps SWITCH (via Simon Leinen) or FUNET (Pekka Savola)?  I remember the days of SWITCH’s relay being a world 6to4 magnet.

The first occurence of 192.88.99.0/24 in the iBGP of SWITCH was on
June 29 2001. I'm not sure when the first global announcement
happened.

> Would be poetic to let them be the last to switch off too, if they’re still running :)

The relay is still running but we stopped announcing the anycast
prefixes globally in September last year.

-- 
Alex

---

From: Mark ZZZ Smith <[email-masked]>
Date: Sun, 23 Nov 2014 06:28:31 +0000 (UTC)

----- Original Message -----
> From: Nick Hilliard <[email-masked]>
> To: [email-masked]
> Cc: 
> Sent: Friday, 21 November 2014, 8:49
> Subject: Re: [v6ops] Who is stilll running 6to4 relays (Was: I-D Action: draft-ietf-v6ops-6to4-to-historic-08.txt)
> 

I can still see one that is quite close to me.  

traceroute 192.88.99.1
traceroute to 192.88.99.1 (192.88.99.1), 30 hops max, 60 byte packets
1  OpenWrt.local (172.31.255.1)  0.243 ms  0.220 ms  0.256 ms
2  lo0.lns20.mel8.on.ii.net (150.101.32.54)  44.848 ms  44.866 ms  45.892 ms
3  xe-1-1-4.cr1.mel4.on.ii.net (150.101.34.159)  59.275 ms  61.682 ms  61.653 ms
4  ae1.cr1.adl2.on.ii.net (150.101.33.41)  63.567 ms  65.774 ms  65.445 ms
5  te3-4.cor1.adl6.on.ii.net (150.101.225.222)  66.633 ms  66.613 ms  68.878 ms
6  fa0-0.sixtofour.adl6.on.ii.net (150.101.1.165)  73.272 ms * *

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 24 Nov 2014 08:12:39 +1300

> 6  fa0-0.sixtofour.adl6.on.ii.net (150.101.1.165)  73.272 ms * *

And FX Networks have one in Wellington. But of course this tells us nothing
about the roundtrip including a return relay.

C:\windows\system32>tracert 192.88.99.1

Tracing route to 192.88.99.1 over a maximum of 30 hops

  1     5 ms     1 ms     3 ms  fritz.box [192.168.178.1]
  2    13 ms    18 ms    13 ms  16.17.69.111.static.snap.net.nz [111.69.17.16]
  3    14 ms    17 ms    17 ms  54.32.69.111.static.snap.net.nz [111.69.32.54]
  4    13 ms    12 ms    13 ms  TenGigabitEthernet0-2-0-917.aknnr-rt1.fx.net.nz [131.203.243.57]
  5    23 ms    22 ms    22 ms  TenGigabitEthernet0-3-0-501.akkin-rt2.fx.net.nz [202.53.187.34]
  6    24 ms    21 ms    21 ms  TenGigabitEthernet0-2-0-918.wnmur-rt1.fx.net.nz [202.53.187.69]
  7    22 ms    20 ms    23 ms  192.88.99.1

     Brian