This graph shows IPv6 performance as measured to www.ripe.net. These measurements show performance of native IPv6 on average being very close to IPv4.
The data for this graph shows the difference between fetching an HTTP object over IPv4 and IPv6 to the same server by web-clients visiting www.ripe.net . I measured the time between receiving a DNS request and the corresponding HTTP request for both IPv4 and IPv6. The various types of IPv6 connectivity of web-clients show different performance characteristics. On average unicast IPv6 (native, green) is only 35 ms slower than IPv4, whereas brokered IPv6 (cyan) is 121 ms slower . The autotunnel technologies perform a bit worse with 6to4 (blue) having an average extra delay of 259 ms and Teredo IPv6 (purple) takes on average 744 ms more than an IPv4 request from the same web-client .
This performance data and other information for a couple of sites that we monitor is available at http://albatross.ripe.net/v6-clientresolver/ (updated daily).
So in the near-future, when IPv6 content starts to become more commonplace, it's way better to have native IPv6 access to IPv6-only content. If you depend on 6to4 or Teredo for End Users to access IPv6-only content, expect noticeable difference in network performance.
This is joint work with Geoff Huston and George Michaelson of APNIC R&D, also see their presentation at APNIC30.
 Brokered IPv6 is IPv6-tunneling through a tunnel-broker. We distinguish this from unicast/native IPv6 by labeling connections coming from IPv6 prefixes of well-known IPv6 tunnel-brokers as brokered . The large spike at the end of the graph is likely due to a problem at one of the IPv6 prefixes of one of the tunnel-brokers.
 We don't have Teredo or 6to4 relays in our network close to the measurement point. With local relays the extra delay for autotunneled IPv6 will probably be a bit less.