Sorry for disappearing from this thread, but I was away. I want to draw attention to something in this discussion, however.
On Wed, Mar 31, 2010 at 03:25:35AM -0400, Igor Gashinsky wrote: > > I will completely agree with you that this is where the problem *should* > be solved. However, we are about 5 years (if not more) too late in solving > it that way if we wanted to deploy ipv6 right now -- that is what we are > trying to address. Hell, IE6 still makes up close to 18% of all users out > there despite everybody trying to deprecate that browser, and the > percentage of ipv6 capable users is roughly the same as the percentage of > windows 98 users out there (0.3%)... So, given that clearly users don't > update their software often enough, it is too late to fix the applications > that are already deployed on users PCs (and their broken home > gateways/firewalls/etc), so, what do we do *right now*, to get those > "broken users" through the next 3-5 years till they upgrade? What that really says is that we failed to do this properly 5 years ago, and instead shipped a lot of kludgey half-working stuff that was sort of broken. Having done that, in order to work around it, the right answer now is to add a _new_ half-working kludge that will be sort of broken, and to add it at central places in the network where it will live effectively forever and where it will actually impede perfectly legitimate users who are using dual stack. I think that's a bad trade-off. This is entirely a question of trading the positive effects of doing something against the short- and long-term costs of doing that thing. I completely agree that there's a serious problem here, and I don't buy for a second the argument that end users need to experience this breakage in order to get them to "upgrade" or "fix" or whatever their broken environments (we are past the beginning of the automotive age, where every driver had to be able to make emergency repairs at the side of the road). But authority DNS servers aren't in the right position in the network to figure out whether the end user is having trouble: they can't even tell whether a query that arrives at their door over v4 is due to an end host that is using v4, given the existence of NAT-PT and the NAT64/DNS64 follow-on currently proposed. The ISP _might_ be able to do something, and even has a customer-satisfaction incentive to try to find these broken implementations and help the customer out. The service itself might be able to detect some things about what the client is actually able to do. But the DNS authority servers from the service operator are just not in a position to draw any of those conclusions, and the proposal can easily do as much harm as good. Therefore, it shouldn't be pursued. Best regards, A -- Andrew Sullivan a...@shinkuro.com Shinkuro, Inc. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
