Toward more sensible whitelisting

[Brian E Carpenter]

Phil,

What are the causes of poor behaviour for IPv6-enabled users
in addition to 6to4 anycast brokenness?

We know how to tackle the 6to4 case*; we should figure out the
other cases. Then the whole whitelisting issue goes away.

*draft-ietf-v6ops-6to4-advisory, which includes specific suggestions
for content providers (which also apply to CDNs).

Regards
   Brian Carpenter




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