On Wed, 31 Mar 2010, Nicholas Weaver wrote: :: :: On Mar 31, 2010, at 12:28 AM, Igor Gashinsky wrote: :: > :: > You are absolutely right -- it's not a DNS problem, it *is* a host :: > behavior problem. The issue is that it takes *years* to fix a host :: > behavior problem, and we need to engineer and deploy a fix much sooner :: > then that (hopefully about a year before the v4 exhaustion date). Given :: > that, is there something other then DNS that can address it better/faster? :: :: Except that, since it IS a host problem, why not focus on improved detection and debugging.... :: :: EG, yahoo is one of the big pushes behind it. THey could easily add auto-debugging to their homepgae would would detect this condition and NOTIFY the users that this will be a problem, same for google.
Yes, we can identify the users (this is how you get the stats in the first place), but afterwards, the problem then still becomes 2-fold. There is a *very large* subset of users who will ignore any warnings (see attempts to deprecate IE6), and there is another subset of users who will do just about anything that the the websites asks them to do (those who get phished all the time), and then there are a ton of people in-between. So, assuming the user doesn't ignore the warning, and is prompted to action, what do we tell the user to do? We don't know what's breaking v6 on their system/network, and while we can put together an FAQ that the more technically inclined may follow, the majority of users won't know what it's talking about, so, do we tell them to call their ISPs, or contact GeekSquad or somebody and pay them to fix it? >From an ISP perspective, that may not be what they would want to do (support calls cost a lot of money), and from a user perspective, they are going to go "what is this ipv6 thing that's breaking, why do i care, and why should I waste money trying to fix it", or worse, "why the hell is $content_site probing my pc, I'm going to contact the FEDS!" (you'd be surprised how often that happens).. This is why we are proposing this hack -- it will allow an ISP to turn on ipv6 on their network without worrying about breaking existing IPv4 users (with the caveat that it will prevent some v6-capable users for using the ipv6 internet until they can v6-transport DNS queries, and the negative impact on DNSSEC). And, it is going to be that operator's choice if they want to enable this feature or not.. It has also been pointed out to me by somebody who wishes to remain anonymous that I have not adequately described the benefits for deployment of this feature to ISP's, so quoting his message: "Let's say that wireless Service Provider A has done their home work and implemented Ipv6. Let's say that Wireless Service Provider B is happy with IPv4 and have no plans to implement IPv6. There are all sorts of devices, operating systems and versions in the network (Symbian, Android, Linux, Windows, MacOS, PalmOS, embedded devices, aircards, etc). Most of them are not field upgradable (or very hard to upgrade). A user will not be able to tell why it takes 5 seconds longer to get to Facebook on Service Provider A's network compared to Legacy Network B. The user will blame the Network and probably switch to Legacy Network B. A solution like the one you are proposing will allow a service provider to roll out Ipv6 without fearing increased customer churn." Fundamentally, what we are proposing is a way to ease the transitional pain, and making it an optional feature that the operator may enable, if they so chose (and see that the benefits outweigh the drawbacks). Is there a better way to address the problem? Thanks, -igor _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
