Subject: [Tools-discuss] Tools wiki reachability over IPv6...

From: Ted Lemon <[email-masked]>
Date: Thu, 14 May 2009 16:33:38 -0700

I've been having an ongoing problem with the tools wiki ever since I  
started using it - for some reason it's not reachable over the IPv6  
transport, only over IPv4.   This would be okay, since I do have  
access to an IPv4 network (grin), but unfortunately it means that  
every time I click on a link that goes to the wiki, I have to wait for  
the connection to the IPv6 address to time out.

So I'm requesting that until such time as wiki.tools.ietf.org has a  
reliable IPv6 connection, the AAAA record for it be removed.   Well,  
actually, wiki.tools.ietf.org is a CNAME for zinfandel.tools.ietf.org,  
so I'm really requesting that the AAAA record for  
zinfandel.tools.ietf.org be removed.

Sorry to be a pain - I think that having IPv6 access for the tools  
site is important, and hope it happens soon, but since it's not  
present now, it shouldn't be being advertised.

Thanks!

---

From: Jeroen Massar <[email-masked]>
Date: Fri, 15 May 2009 09:58:11 +0200

Ted Lemon wrote:
[..]
> zinfandel.tools.ietf.org be removed.

I agree. For me it generally works, but it generally is way too flaky.
From here at the HPI in Potsdam at the 2nd German IPv6 Summit the IETF
can't be reached over IPv6. IPv4 fortunately works after some time.

This is most very likely a problem at AT&T's network which simply is not
ready enough yet for deployment (even though they make papers about it,
which actually show this clearly as they state they only have 11 peers)

If you have a problem with that tools server though, you most likely
also have a problem with other services hosted there, including:

{www|mail}.ietf.org and others @ 2001:1890:1112:1::20

Traceroutes (from noc.sixxs.net):

traceroute to zinfandel.tools.ietf.org
(2001:1890:1112:1:214:22ff:fe1f:1e54) from
2001:838:1:1:210:dcff:fe20:7c7c, 30 hops max, 16 byte packets
[..]
 9  ibr01-ve26.lndn01.occaid.net (2001:7f8:4::7577:1)  36.783 ms  36.933
ms  36.922 ms
10  bbr01-p1-0.nwrk01.occaid.net (2001:4830:fe:1010::2)  108.399 ms
107.434 ms  106.772 ms
11  r1.mdtnj.ipv6.att.net (2001:4830:e2:2a::2)  184.822 ms  183.671 ms
179.32 ms
12  2001:1890:61:9017::2 (2001:1890:61:9017::2)  256.564 ms  256.71 ms
257.363 ms
13  2001:1890:61:9017::2 (2001:1890:61:9017::2)  3257.22 ms !H  3255.15
ms !H  3281.79 ms !H

HUGE latency at the last hop, but that could be due to a timeout on the
router, but then a !H, thus clearly nothing home there.

for www.ietf.org:
[..]
 9  ibr01-ve26.lndn01.occaid.net (2001:7f8:4::7577:1)  37.165 ms  37.306
ms  46.407 ms
10  bbr01-p1-0.nwrk01.occaid.net (2001:4830:fe:1010::2)  120.865 ms
106.906 ms  107.255 ms
11  r1.mdtnj.ipv6.att.net (2001:4830:e2:2a::2)  182.676 ms  184.744 ms
179.842 ms
12  2001:1890:61:9017::2 (2001:1890:61:9017::2)  256.307 ms  269.928 ms
 257.271 ms
13  2001:1890:1112:1::20 (2001:1890:1112:1::20)  258.437 ms  280.844 ms
 257.209 ms

I also have a concern there, nearly 300ms to a site in the US, while the
 hop transatlantic is only 120ms out of this. As a comparison:

A traceroute to www.kame.net (from .nl to .jp) goes over NTT and only does:

14  ve45.foundry2.yagami.wide.ad.jp (2001:200:0:12::74)  274.978 ms
275.036 ms  274.829 ms
15  2001:200:0:8400::10:1 (2001:200:0:8400::10:1)  279.977 ms  279.551
ms  279.833 ms
16  orange.kame.net (2001:200:0:8002:203:47ff:fea5:3085)  279.139 ms
279.039 ms  279.362 ms

Which is almost the same latency, and REALLY on the other side of the
world (the route is amstnl02,asbnva01,snjsca04,osakjp01,tokyjp01 btw)

One also notices that the route goes over OCCAID who are actually
transporting the bits from London to the US. AT&T is claiming to be a
Tier1 IPv6 Transit provider, but really, using an non-profit
organization to transport your bits definitely disqualifies one from any
claim at being a Transit provider and far from the claim of being Tier1.

I really really really hope that AT&T finally deploys a global network
and start shifting bits through their own links.

Next to that, they should also finally fix their firewalls to not drop
ICMPv6, which is another cause of problems when one is not on a
1500-byte link.

Greets,
 Jeroen

  (and no, I am not just trying to be nasty to AT&T, but hey come on,
fix that network already, there are big eyeballs looking at the sites
being hosted and this is simply broken, that means that there are no
happy eyeballs and even worse: IETF is not properly eating their own
dogfood this way.... please fix!!!!)

---

From: Ted Lemon <[email-masked]>
Date: Fri, 15 May 2009 01:14:09 -0700

> {www|mail}.ietf.org and others @ 2001:1890:1112:1::20

No, the problem is specifically with the wiki.   I haven't been having  
trouble with other ietf sites - e.g., the main tools page comes up  
just fine, and so does the main IETF site and the RFC editor site.   I  
very consistently can't get through to the wiki - I've never  
(knowingly) gotten through to it on ipv6.

> hop transatlantic is only 120ms out of this. As a comparison:

I think we should all count our blessings that in this modern day a  
300ms rtt seems long.   This sort of thing isn't an operational  
problem, in any case - it's unreachability that's eating my lunch at  
the moment, not latency.

---

From: Henrik Levkowetz <[email-masked]>
Date: Fri, 15 May 2009 14:40:07 +0200

Hi Ted,

Sorry about this.  I've now (in this order):

  - taken out the IPv6 address for zinfandel from the zone file
  - gotten zinfandel to reply to its IPv6 address again
    (although I still don't know why it stopped responding)
  - tested IPv6 reachability
  - added zinfandel's IPv6 address to the zone file again.
  - tested web access over IPv6 to zinfandel.

I hope the service will be less painful now; please let me know
if this is not the case, or if things stop working again in the
future.

Best,

	Henrik

On 2009-05-15 01:33 Ted Lemon said the following:
> _______________________________________________
> Tools-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tools-discuss
>