I'm one of those people who'll use any excuse to play with the latest or most interesting technology. It should therefore come as no surprise that I'm keen to see IPv6 deployed both at home and at work. Sadly I've come to the conclusion that it's just going to upset my customers.
Home is the simplest problem to explain. While my ISP (Enta) are able to support native v6, I own a Draytek 2820 which lacks v6 support. Draytek inform me that they have no interest in implementing support. At $0rkplace our office Internet access provider lacks any interest in providing v6. These two problems mean that I have to resort to tunnelling to have any hope of testing any v6 services that I deploy. Not a huge problem, but at least a little irritating.
At $0rk we're, in theory, in a great situation. We have complete control over our shared web hosting environment, control over the load balancers and firewalls of our enterprise customers, and run DNS for almost all customers. This ought to allow us to make almost any customers' site/service available over v6 without them having to know or care. Unfortunately this isn't the case.
The big problem I have is providers with partial v6 tables and consumers with broken DSL modems. If I were to add an AAAA record for our main web site then hosts that support v6 will prefer that over the A record and attempt to make a v6 connection. If that host is on a network that doesn't have a route to our v6 prefix then they'll hang around for a timeout before attempting a v4 connection using the A record. This timeout is long enough to easily be noticeable, and quite unpleasant, to the user. Even if this problem is limited to a small number of end-users I'm still in trouble: how do I explain to a customer that their web site is "slow" for a user because I've made it available over IPv6? They'll just want me to disable this evil IPv6 thing.
Of course, this problem doesn't just impact the content provider. A v6 enabled user will find that a site that has AAAA records but that lacks v6 connectivity (due to either content or access provider taking only a partial table) to be horribly slow. This encourages the user either not to use the site, or makes them disable IPv6 support. Not ideal.
Providers who are experimenting with providing services over IPv6, but who lack a full table (or a working network), are making IPv6 deployment unpopular from an end-user perspective. A provider with a broken network encourages end users to blame IPv6 and disable support in their OS. Additionally it discourages content providers from making services dual stack. Until this problem goes away (which it won't) I cannot justify making our services (and our customers' services) dual stack. Yeah, sure, I can do a Google and have new names for my v6 services but who the hell's going to make use of them? Why would anyone make the effort to use http://ipv6.0rkplace/ rather than http://www.0rkplace/?
Home is the simplest problem to explain. While my ISP (Enta) are able to support native v6, I own a Draytek 2820 which lacks v6 support. Draytek inform me that they have no interest in implementing support. At $0rkplace our office Internet access provider lacks any interest in providing v6. These two problems mean that I have to resort to tunnelling to have any hope of testing any v6 services that I deploy. Not a huge problem, but at least a little irritating.
At $0rk we're, in theory, in a great situation. We have complete control over our shared web hosting environment, control over the load balancers and firewalls of our enterprise customers, and run DNS for almost all customers. This ought to allow us to make almost any customers' site/service available over v6 without them having to know or care. Unfortunately this isn't the case.
The big problem I have is providers with partial v6 tables and consumers with broken DSL modems. If I were to add an AAAA record for our main web site then hosts that support v6 will prefer that over the A record and attempt to make a v6 connection. If that host is on a network that doesn't have a route to our v6 prefix then they'll hang around for a timeout before attempting a v4 connection using the A record. This timeout is long enough to easily be noticeable, and quite unpleasant, to the user. Even if this problem is limited to a small number of end-users I'm still in trouble: how do I explain to a customer that their web site is "slow" for a user because I've made it available over IPv6? They'll just want me to disable this evil IPv6 thing.
Of course, this problem doesn't just impact the content provider. A v6 enabled user will find that a site that has AAAA records but that lacks v6 connectivity (due to either content or access provider taking only a partial table) to be horribly slow. This encourages the user either not to use the site, or makes them disable IPv6 support. Not ideal.
Providers who are experimenting with providing services over IPv6, but who lack a full table (or a working network), are making IPv6 deployment unpopular from an end-user perspective. A provider with a broken network encourages end users to blame IPv6 and disable support in their OS. Additionally it discourages content providers from making services dual stack. Until this problem goes away (which it won't) I cannot justify making our services (and our customers' services) dual stack. Yeah, sure, I can do a Google and have new names for my v6 services but who the hell's going to make use of them? Why would anyone make the effort to use http://ipv6.0rkplace/ rather than http://www.0rkplace/?
Leave a comment