It seems facebook has started to publish AAAA on non-"whitelisted" DNS servers -

see considering it was "supposed" to re-occur only on June 6th.  Maybe they need some news to spur investment in their stock  

As far as I know this was part of an early roll out for third party developers to deal with issues before the World IPv6 Launch day.

I haven't seen it stream over IPv6 since Dave Temkin left for a short bit, and has now since returned. They moved to Amazon or something away from LLNW, which had no IPv6 access. Maybe now that he is back, they'll get that going again.

They moved away from running their DC and backend systems to using AWS. They had also moved away from using Akamai as a primary CDN to Level3 as well as their other existing CDN LLNW.

Please retest.

Wow. Peering with Leve3 before Cogent *draw drops* heh. I see there is now peering in San Jose/Chicago/New York. Are you guys going to attempt to turn up peering at other locations such as Los Angeles/Dallas/Atlanta or European cities like London/Amsterdam/Frankfurt?

Hello All:
I pasted the following in on my OpenBSD test box as root user:

ifconfig gif0 tunnel 192.168.0.242 216.66.38.58
ifconfig gif0 inet6 alias 2001:470:1c:661::2 2001:470:1c:661::1 prefixlen 128
route -n add -inet6 default 2001:470:1c:661::1

Also tried my external IP in place of the RFC1918 IP. 

You definitely would need the external IP for the source address for the gif(4)
tunnel.

Try putting this in your /etc/hostname.gif0..

Code:

up mtu 1480
tunnel [your external IP]
dest 216.66.38.58
inet6 2001:470:1c:661::2
inet6 [another IPv6 address]
inet6 [another IPv6 address]
!/sbin/route -qn add -inet6 default 2001:470:1c:661::1

You can add additional addresses from either the /64 or a /48 to the gif(4)
interface as well.

Turn up the interface once that has been put into the file.. sh /etc/netstart gif0.

If you are running PF ensure to allow protocol 41 traffic..

Code:

pass in on $ext_if inet proto ipv6 from $v6_tunnel_endpoint to $your_fw
pass out on $ext_if inet proto ipv6 from $your_fw to $v6_tunnel_endpoint

as well as in/out v6 traffic from your gif(4) interface at a minimum.

Did you assign an IPv6 address out of your routed /64 to eth0?

No such interface as eth0 on OpenBSD and there isn't a requirement for having an
address assigned to a physical interface.

Hi,

thanks for the reply but i think its more of the tunnel issue. I was not able to traceroute to even ipv6.google.com . I am the Singapore tunnel.

Then there is something wrong with your system setup. The issue with this IRC server is on the other end somewhere closer to the server or the network it is hosted on.

Well there is the issue: sjo-bb1-link.telia.net

A europian carrier.

Well Telia is a European carrier. TeliaSonera International Carrier, their wholesale division, has a number of
POPs in the U.S as well as Asian POPs. The POP you have mentioned above is in San Jose. One of the other traceroutes also shows a TeliaSonera POP in Ashburn. TeliaSonera is one of HE's transit providers as well as Global Crossing.

I don't actually expect them to divulge the package they're using. From my point of view, it'd be kind of a security risk, "hey, find a vulnerability for xxxx and take down HE!" kind of thing.

If anyone was going to do that they would find out on their own and not have to ask... and yes there are ways of find out what pretty much any DNS / HTTP / FTP / SMTP / POP3 / IMAP server, etc is no matter how you try to hide any versioning information or identification.

I take it orange dots are planned future sites? The map needs a key

That was what I had guessed for that colour.

I'm only using SCO to play with on an eval license. I wanted to experience the glory that was System V, albeit in a slightly modified form. I also hadn't seen that document. I haven't had a chance to read all the way through, but it looks like it may help.

Why not Solaris? Which isn't anywhere near as crufty as UnixWare or OpenServer.

although not in the looking glass yet I see also Las Vegas. nice.

Wow. Looking at the new network map you guys are expanding at a pretty quick pace. Good work.

although not in the looking glass yet I see also Las Vegas. nice.

Looks to me that both sixxs and us complain about too big packet, and they default to 1280 on their side (see their too big reply). Our side defaults to 1480. Also the same payload size wasn't used in one test as another (1400 vs 1450 != same test). Try the mtu change on the Cisco down to 1280 and see if it replicates what you see with sixxs, which would also be a packet too big error, but ping replies.

Hrmm. from reverse DNS on the tunnels I got the impression the tunnelbroker POPs were a *BSD box, which definitely do not default to 1480. Your default should be mentioned to users and router examples should take that into consideration because 1480 is not a universal default and as per spec the default is 1280.

I have switched back to the SixXS tunnel for now (so you'll see the SixXS behavior if you try it).  My sense is that the HE end of the tunnel is advertising the wrong path MTU.  Is that correct?

Check the MTU on the tunnel interface on your router. If I remember correctly Cisco uses the wrong MTU by default. Set it to 1280. If anything is wrong its on your end.

Ok. just asking. Good peering at those POPs would be good enough.