<p><br>
On Jun 13, 2011 6:54 PM, "Dan Wing" <<a href="mailto:dwing@cisco.com">dwing@cisco.com</a>> wrote:<br>
><br>
> > -----Original Message-----<br>
> > From: ipv6-ops-bounces+dwing=<a href="http://cisco.com">cisco.com</a>@<a href="http://lists.cluenet.de">lists.cluenet.de</a> [mailto:<a href="mailto:ipv6-">ipv6-</a><br>
> > ops-bounces+dwing=<a href="http://cisco.com">cisco.com</a>@<a href="http://lists.cluenet.de">lists.cluenet.de</a>] On Behalf Of Phil<br>
> > Benchoff<br>
> > Sent: Monday, June 13, 2011 4:36 PM<br>
> > To: <a href="mailto:ipv6-ops@lists.cluenet.de">ipv6-ops@lists.cluenet.de</a><br>
> > Subject: Toward more sensible whitelisting<br>
> ><br>
> > The really big content providers are pretty hesitant to add sites to<br>
> > their<br>
> > whitelist (if they even have one).  IPv6 testing primarily depends on<br>
> > users entering a special IPv6 URL which most people won't bother with<br>
> > and may not even know about.  I've been thinking there ought to be some<br>
> > ways to get users with working IPv6 to try the IPv6 version of a site<br>
> > without causing too much worry to the content providers.<br>
> ><br>
> > There are several JavaScript tests of IPv6 connectivity.  Why not use<br>
> > one<br>
> > of them to inform a user he has working IPv6 and offer an easy way to<br>
> > switch to the IPv6 version of the site?<br>
><br>
> Separate namespaces (e.g., "<a href="http://ipv6.example.com">ipv6.example.com</a>") are bad.  That user,<br>
> who is using the IPv6 namespace, will eventually share content<br>
> via email (cutting and pasting the URL) or on a social network via<br>
> a "share on <social_network>" button.<br>
><br>
> But that shared content won't work with the other 99.mumble% of the<br>
> Internet population, who are IPv4 only.  People will complain.  Users<br>
> will be unhappy, including the IPv6-friendly user that opted into the<br>
> IPv6 website in the first place.   And IPv6 will be blamed -- afterall,<br>
> "ipv6" name will be right there in the URL (or "ip6", or whatever<br>
> that website chose).<br>
></p>
<p>Agreed, not ideal. But, could a browser not abstract away this issue to best fit a host? DNS? Naptr? </p>
<p>I personally only use ipv6.blah in my bookmarks for CNN, Facebook, Google, Cisco ... but I am not a usual user that prefers to be af agnostic. Nonetheless, this is an evolving behavior.  If I ran a nat64 network, would it not behoove me to seed these book marks with ipv6 names on user device and my customer portal? </p>

<p>Cb<br></p>
<p>> -d<br>
><br>
> > Consider<br>
> > <a href="http://www.getipv6.info/index.php/Warning_broken_users_with_JavaScript">http://www.getipv6.info/index.php/Warning_broken_users_with_JavaScript</a>.<br>
> > If you change the way you evaluate the results, you could have a popup<br>
> > tell<br>
> > the user he has working IPv6 and let him click a button to be forwarded<br>
> > to<br>
> > the IPv6 web site.  If a user goes to <a href="http://www.example.com">www.example.com</a> and has working<br>
> > ipv6,<br>
> > he could be prompted to switch to <a href="http://www.ipv6.example.com">www.ipv6.example.com</a>.  The site<br>
> > operator<br>
> > could choose a popup, automatically forwarded the user, or present a<br>
> > dialog<br>
> > within the content of the site.  These all alter the user experience a<br>
> > bit, but they may be within the range of tolerable changes.<br>
> ><br>
> > Personally, I'm all for adding an AAAA record and fixing the problems<br>
> > that<br>
> > show up.  There don't seem to be that many and there is always the<br>
> > option<br>
> > of removing the AAAA record if necessary.  That being said, I think it<br>
> > is necessary to work with the big content providers and try to find<br>
> > ways<br>
> > to address the things they are worried about.  I suspect the engineers<br>
> > working on IPv6 at those big content companies spend more time<br>
> > convincing<br>
> > others that it is reasonably safe to try a few things than they do<br>
> > actually<br>
> > fixing IPv6 issues.  Everyone involved in trying to move IPv6 forward<br>
> > knows there are broken things in all of the selective IPv6 availability<br>
> > scenarios.  The questions are which are the least broken and what new<br>
> > ones<br>
> > can we invent to move on?<br>
> ><br>
> > The people on the content side of the equation need to understand that<br>
> > the average user isn't going to go out of his way to help them prove<br>
> > that<br>
> > IPv6 is viable.  The only users that will change their DNS resolver are<br>
> > the ones who already type the IPv6 URL.  Network operators with<br>
> > eyeballs<br>
> > are (probably) not going to bake you a cake or get an NIST<br>
> > certification<br>
> > that they really do IPv6.  You're going to have to pick the least sucky<br>
> > looking alternative and take some kind of leap.  If nothing else, start<br>
> > deploying some JavaScript to estimate how well things would work with<br>
> > IPv6<br>
> > and help the sites with unhappy eyeballs get things working.<br>
> ><br>
> > I'm really hoping that an analysis of the numbers and experiences from<br>
> > IPv6 day show that it's really not so bad.<br>
> ><br>
> > Phil<br>
><br>
</p>