frezik wrote:What kind of benefits would I expect on a hypothetical DSL modem that properly supported IPv6?
There are three benefits to being on native rather than tunneled IPv6, all of which improve your client experience.
Native has bigger MTU. Regular ethernet allows 1500 octet packets, IPv6 requires a minimum of 1280 octets, AFAIK IPv4 minimum was 568. Since in IPv6 routers don't do fragmentation, only end points, retrieving something large like a web page or video either has to limit itself to 1280 byte chunks, increasing overhead and decreasing throughput, or hope that "path MTU discovery" is working properly. Unfortunately PMTU depends on receiving ICMPv6 "too large" errors back, and congested ISP links tend to preferentially drop or rate limit ICMP, plus badly misconfigured overzealous firewalls may block necessary ICMP messages. So relying on PMTU to work reduces your reliability. The response by servers expecting tunneled clients (50% of clients currently, 100% of servers) is to reduce their MTU to 1280. Clients with native v6 can mostly not worry about it. Simple tunneling (6in4, 6to4) using IPv4 protocol 41 (slap a v4 header in front of the v6 payload) reduces MTU by a minimum of 20 octets. Teredo, where you have to put a v4 header, a UDP header, and a Teredo header in front of the v6 payload might knock it down by 50-70 octets. Then add in tunneling by your ISP, which might not be native v6 end-to-end yet, a VPN tunnel somewhere, etc. and possibly lose another 70+. If I'm trying to make a 30 octet DNS query, and I have to eat 200 extra octets of overhead along the way, my performance is going to suffer.
Native has lower latency and jitter. Predictable, small round trip times matter for applications like videoconferencing and gaming. Going through some remote 6in4 or 6to4 or Teredo relay can incur an extra 20 or 30 routing hops. Even for simple web pages this can double the page load time.
Native has higher reliability. If you are using a tunnel, you are depending on shared 3rd party resources, which may be overloaded, are more subject to denial of service attacks, and which increase your risks of packet loss due to congestion or routing blackholes. Measurements by APNIC's chief technologist, Geoff Huston, suggest that up to 15% of IPv6 tunneled 6to4 connections currently just fail entirely. Ditto for Teredo, which is only for masochists.
Best practice: for IPv6 R&D, use a point-to-point tunnel with a tunnel broker. For production IPV6 use, insist on native.
(To me, it seems like the fact that DSL/cable modems have to support it at all is a major breakage of OSI layering.)
No, it's actually a triumph of layering. If you are going to swap out the routing layer, where IPv4 and IPv6 live, every device doing routing is going to have to know. Which is a lot of gear, as detailed earlier in the thread. But we're keeping IEEE 802.whatever at physical layer 2: we run both IPv4 and IPv6 over the same ethernet, WIFI, bluetooth, WiMax, 3GPP, fiber, etc. We're keeping UDP and TCP and SCTP and ... session stuff at layer 4. We're keeping HTTP and DNS and FTP and SMTP and ... application stuff at layer 7, with only minor tweaks where the protocols embed IP addresses. We're keeping everything except layer 3, really, and if you are going to replace the entire infrastructure of the internet, you are going to have to expect to change something somewhere.